使用无服务器式的 Jenkins X：探索Prow，Jenkins X Pipeline Operator和Tekton

会员服务 ·

使用无服务器式的 Jenkins X：探索Prow，Jenkins X Pipeline Operator和Tekton

2019 年 4 月 25 日 DevOps时代

校对 | 卢迪

翻译 | 致Great

Jenkins X的无服务器风格，或者有人称之为Jenkins X Next Generation，试图重新定义我们如何在Kubernetes集群中进行持续交付和GitOps。

它通过将相当多的工具组合成一个易于使用的捆绑包来实现这一点。绝大多数使用者，无需理解相关组件独立运行的复杂性，也无需理解它们是如何集成的。只需将版本迭代推向Git，其余工作都会由系统自动完成。

为了一窥究竟，接下来就让我们一同探索，无服务器Jenkins X平台中涉及的流程和组件。通过理解一项任务从Git webhook起始的流动，将会帮助我们对其工作原理有更加深入的理解。同时，也会在我们接下来深入介绍各个全新组件时，提供帮助。

以下的描述，并非对所有使用者都是必需的。如果你选择跳过，并选择在不清楚其内部工作原理的情况下使用无服务器的Jenkins X，我们也认为很好。毕竟，Jenkins X的主要目标就是抽象细节，让人们练习持续交付，而不用花费数月时间来学习诸如Kubernetes和Jenkins X等复杂系统。

就像静态Jenkins一样，一切都起始于向Git库的一次push操作。随后，一个webhook请求被发送至集群中。不同的是，并没有用来接收这些请求的Jenkins。相反，我们有Prow。它会做很多事情，但在webhook这个场景下，它的工作是接收请求并决定下一步该做什么。这些请求不仅限于push操作，还包含了我们可以通过pull request评论指定的斜杠命令（例如/approve）。

Prow由几个不同的组件组成（例如，Deck，Hook，Crier，Tide等等）。然而，我们并不会深入介绍各个组件的职责。此刻，最需要留意的重要事项是Prow是群集的入口。它接收所有的Git请求，包含产生于Git动作的（例如push）与产生于评论中斜杠命令的。

Prow在收到请求后可能会做很多事情。如果它来自Git注释中的命令，它可能会重新运行测试，合并拉取请求，分配人员或许多其他Git相关操作之一。如果webhook通知它已经进行了新的推送，它将向Jenkins X Pipeline Operator发送一个请求，该请求将确保运行与定义的管道相对应的构建。最后，Prow还向Git报告了构建的状态。

这些特征并不是Prow可能执行的唯一动作类型，但是现在，你可能得到了一般的Gist。Prow负责Git与集群内部流程之间的通信。

当Prow Hook收到来自Git webhook的请求时，它会将其转发给Jenkins X Pipeline Operator。Operator的职责是从库中取回用于初始化流程的jenkins-x.yml文件，并将其转换为Tekton Tasks和Pipelines。反过来，它们定义了将变更push到Git后，应该被执行的完整流水线。

Pipeline Operator存在的原因是为了简化我们持续交付流程的定义。Tekton完成了繁重的工作，但这是一个非常低级的解决方案。它不应该直接使用。编写Tekton定义可能非常痛苦和复杂。Pipeline Operator通过易于学习和使用YAML格式来定义管道简化了这一过程。

Tekton为每次推送创建一个PipelineRun，每次推送都发送到一个相关的分支（例如，master分支，PR等），同时执行验证推送所需的所有步骤。Tekton运行测试，在注册表中存储二进制文件（例如，Docker Registry，Nexus和ChartMuseum），并将发布部署到临时（PR）或永久（临时或生产）环境。

完整的流程如下图所示：