使用无服务器式的 Jenkins X：探索Prow，Jenkins X Pipeline Oper
作者：互联网
翻译 | 致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）或永久（临时或生产）环境。
完整的流程如下图所示：
正如上面已经提到的，并非每个人都需要了解事件的流程，也不需要深入了解流程中涉及的所有组件。对于大多数用户来说，唯一需要理解的是，将更改推送到Git将导致执行jenkins-x.yml管道中定义的构建。这就是Jenkins X的美丽。它通过简化复杂的过程简化了我们的生活。
本文节选自《DevOps 2.6工具包：Jenkins X》一书。
标签：Oper,Pipeline,Git,请求,Prow,webhook,Operator,Jenkins 来源： https://blog.51cto.com/15127503/2657493