詹金斯.io发布了新一代云计算引擎整合的博客。我很高兴看到这种情况发生，让我解释一下为什么。在2011年，当我加入CloudBees时，我开始实现一个作业编排插件，我觉得需要用它来替换我见过的由各种插件实现的大量"触发另一个作业"用例。我的构建流插件依赖于一个普通的Java线程来执行Groovy脚本，而不会对内部Jenkins API滥用设置任何安全障碍。作为我的第一个Jenkins插件，它的实现非常糟糕，并且显示了可怕的安全影响和设计缺陷，所以今天这个插件被放弃/弃用了（如果你喜欢考古学，想发现我的英语在这个时候有多糟糕，请看这段Jenkins用户活动巴黎2012的视频。无论何时在技术上处于死胡同，它都展示了一条通向DSL的可行路线来协调Jenkins构建，并得到了广泛的采用。但是构建流一直是一个有用的灵感，并且在设计Jenkins 2.x管道引擎时证明了用户的兴趣，这需要对Jenkins进行大量投资-核心管道执行引擎，与构建流普通Groovy executor相比，使用细粒度的沙盒来加强安全性，使用"连续传递式"运行器来解析Groovy语法，并将每个命令作为可恢复的操作执行，由足够的Jenkins插件实现。因此，没有实际的Groovy线程运行您的管道，一个主线程可以运行数千个。构建流和管道之间没有一行代码共享，但我仍然感到自豪的是，我丑陋的代码被用作概念证明，可以更好地、成功地执行管道引擎。这个并没有使管道成为构建编排的最终答案。Pipeline依赖于脚本语言，当你给开发人员一种编程语言时，他们会编写代码……结果，他们中的一些人设计了一个由数千行Groovy脚本组成的难以管理的野兽。共享库被认为是将其重构为更简单的脚本的一种方法，但与此同时，andrewbayer和他的团队带来了一个新的项目：声明式的编写了脚本的管道pipeline使Jenkins可以在管道中执行任何操作，而声明性管道被设计成只关注于更简单的用法-这涵盖了大约90%的需求。对于这些，声明性管道既提供了简化的语法，也提供了另一种编排定义方法，这种方法不是基于命令式脚本，而是对构建步骤和相关资源的声明性定义。除了使事情变得简单，这也给管道.声明性管道不使用不同的执行引擎。它使用与脚本化管道完全相同的沙盒和"CPS"Groovy执行。但是由于它的声明性语法，它允许一个更简单和同质的语法以及合理的默认特性，使用户的生活更简单。让现在我们来看看在Kubernetes生态系统中发生了什么，以满足同样的需求……KNative是一个项目（由Google和Pivotal发起），旨在提供无服务器功能在Kubernetes星团的顶部。作为一个临时任务，在一个临时任务中负责建立一个临时任务。这个范围非常局限于最简单的构建来检查代码、构建、测试和创建Docker映像。但这仍然满足了我们大多数人的需求：）有趣的事实：除了关注Kubernetes之外，Knative构建似乎可以与我自己的docker管道相媲美。不幸的是，这件事从未引起人们的注意，它只是一个证据概念。那么Google开始与其他贡献公司合作，在Knative（代号Tekton-τέκτων）中提出管道支持的更大构想：carpenter的希腊语名词：造你船的家伙！""Build Pipeline"可能是一个更明显的名称，但你知道，命名是我们行业中比较困难的问题之一：PTekton管道确实运行在Kubernetes上，依赖容器作为构建块来执行命令，并提供构建资源的抽象，比如在哪里获得代码库（git）和构建输出（docker images）。作为一个本地Kubernetes项目，它依赖于自定义资源定义（CRD）进行配置和状态。因此，使用Tekton定义构建需要一组重要的yaml:Definitions for individual Tasks（要执行的容器和命令序列）PipelineResources:git repository to checkout，Docker image来构建管道，将它们连接在一起PipelineRun来管理管道的执行和状态要深入到兔子洞，我们需要更好地了解Jenkins X是如何运行管道的，尤其是Jenkins X的无服务器Jenkins味道。在这种模式下，Jenkins X不是全职运行Jenkins master来等待工作安排的。它对GitHub事件作出反应，使用Jenkinsfile Runner创建一个临时的"一次性"主节点，在独立的环境中执行管道脚本上下文.JenkinsfileRunner是Jenkins的一个定制打包，用于在引导序列之后立即运行单个管道，应用一个本地Jenkinsfile脚本。在内部，它使用与经典Jenkins完全相同的管道执行引擎。在这个文件中，一个运行器和一个安全屏障已经不再是一个相关的安全问题了简化。In平行的，声明性Pipeline演示了减少管道语法的范围，这使得脚本的编写和实现更加简单灵活。这里"下一代管道"effortNG Pipeline（或为此使用的最终名称）希望为管道定义定义一个抽象语法，完全描述性，因此我们可以灵活地采用适当的实现并在需要。下一个生成管道定义了一个简单的yaml语法来定义抽象管道，而不公开实现详细信息：pipelineConfig:管道：发布：管道：代理人：图片：nodejs阶段：-名称：Build步骤：-命令：echo参数：-你好，世界注意：这是编写时建议语法的早期预览。这是一个正在进行的工作，可能会有变化，您已经收到警告！Serverless Jenkins是第一个受益于此项工作的公民，但NG管道在稳定后也可以用于其他环境。在无服务器的詹金斯，天然气管道将拥抱泰克顿。后者可以用来运行您的Jenkins X管道，而不需要为此运行隐藏的Jenkins主程序。下一代管道将读取这个jenkins-x.yml管道定义，为Tekton创建一组CRD。你真的不需要担心这个管道步骤，记住詹金斯X会帮你处理的透明的CloudBees团队正与Google和Kubernetes社区就Tekton项目进行合作，以确保所需的特性将得到支持，从而提供与Jenkins声明性相当的功能管道。一次这个支持Jenkins管道的yaml语法在我们将致力于自动将基于groovy的声明性Jenkins文件迁移到这种新格式。因此，从最终用户的角度来看，对詹金斯的投资仍然是完全相关的，他们将从非常活跃的库伯内茨的最新投资中获益生态系统整合Tekton是Jenkins声明式管道灵活性的一个很好的证明。多亏了一种声明性的方法，我们可以透明地替换底层的执行引擎，并在Kubernetes上采用最前沿的解决方案。我非常高兴看到Tekton得到Jenkins X的支持，这是Jenkins构建编排已经很长的故事的下一章。这为Jenkins用户提供了一条平滑的迁移路径。到目前为止，Jenkins X展示了一种积极但非常有效的方法来实现Jenkins的"现代化"，用Kubernetes社区的替代项目替换核心组件，而不破坏Jenkins的主要使用场景：运行您的管道！其他资源阅读Jenkins X DevPod博客文章了解一个用户如何迁移到Jenkins XCheck，看看您的集群是否为Jenkins X做好了准备