Tekton 与Jenkins：谁更适合用作红帽 OpenShift 上的 CI/CD 管道？

Tekton 脱胎于 Knative 项目，随后得到了红帽的鼎力支持，被视为 红帽 OpenShift 中万物管道的未来发展方向。早在 2018 年，当我初次听闻 Tekton 时，我的第一反应便是：“我们要尝试解决什么问题？”。毕竟，我对 Jenkins 颇为熟悉，也很是喜爱。既然现有的工具已经足够好用，我又何必去面对新技术的学习曲线？

红帽被评为 2023 年 Gartner® 魔力象限™ 领导者

在 2023 年 Gartner 魔力象限容器管理评选中，红帽被评为最具执行能力和最具远见的品牌。

阅读报告

每当我询问“为什么 Tekton 要优于 Jenkins？”时，最常听到的回答便是“Tekton 是云原生的”。然而，这之后往往是沉默不语或是迅速转换话题。于是，我开始探寻“云原生”的明确定义，期待能够获得顿悟的契机。 

2018 年，云原生计算基金会（CNCF）发布了这样的定义：“云原生技术使企业能够在现代、动态环境（例如公共云、私有云和混合云）中构建和运行可扩展应用。”

因此，那里是找不到明显启示的。另外，对于那些多年来在我工具箱中运作得游刃有余的工具，我形成了一种难以言喻的依恋。为了让我能够向忠实老友 Jenkins 摊牌，我深知自己需要更加坚信山外有山。若我决意告别 Jenkins，Tekton 必须展现出远超我现有工具的独特价值。 

最终，我得出的结论是，在 OpenShift/k8s 领域，Tekton 在集成方面的表现更为出色，并蕴含着 Jenkins 可能不具备的全新机遇。

本文的其余部分将进一步探讨这一主题。如果您也抱有同样的疑问，我希望您能从中找到一些答案。

我的 Jenkins 体验

实话实说，Jenkins 虽然是优秀的老牌工具，但如今已显得有些过时。它于 2005 年前后首次亮相，自那之后变化不大。其最大的亮点在于有大量插件可供选择，让您能够轻松地与几乎任何平台无缝对接。但这也是一个弱点，因为这些插件的软件生命周期难以确定。如果插件出现问题，那么您通常需要解决这些问题。 

Jenkins 是基于 Java 的；众所周知，它会占用大量内存和处理器资源（持续运行）。考虑到计算资源的总体成本，这一点可能会逐渐被视作一个问题。

在容器化技术问世之前，我们常常见到所谓的“大型”Jenkins，即整个开发部门共用一个 Jenkins 服务器，而这往往会导致性能瓶颈。由于它难以有效应对如此庞大的负载，因此您可能会经常听到 Jenkins 陷入严重性能问题、需要重启的消息。言归正传。 

后来，容器技术出现了，现在每个团队都可以拥有自己的 Jenkins 服务器，并根据自己的偏好进行配置。但这引发了另一个问题，即“Jenkins 无序扩张”。所有这些 Jenkins 服务器大部分时间都在低效运转，消耗了大量资源。更不用说每个团队传播的管道代码类型数量众多，五花八门。

因此，理想的解决方案是占用空间极小，可以分散至每个团队，同时还强烈主张所有管道保持相似。先保留这些想法，因为我们稍后会再次探讨这个话题。

关于进程排序模型

在软件系统中，我们需要采用一种有效的方法来组织服务调用/进程阶段的顺序，以达成预期的结果。此操作存在两种广泛认可的方法。

第一种模式是“编排”（Orchestration）类型，它的典型代表是进程管理器模式。

来源（此文件依据 Creative Commons Attribution-Share Alike 4.0 International 许可证获得了许可。）

进程管理器实际上扮演着管弦乐队中指挥的角色，因此它被形象地命名为“Orchestration”（源自“Orchestra（管弦乐队）”一词）。

Jenkins 就是这种模式的一个例子。它的行为类似于进程管理器，如同管弦乐队中的指挥。您可使用 JenkinsFile 编写进程代码，在此过程中，您将定义这个进程。Jenkins 通过其众多基于插件的接口交付的所有内容都会以完成状态返回给进程管理器，从而允许进程进入下一个阶段。在大多数情形中，这似乎是一种同步行为。 

在 Refactoring to Patterns（Kerievsky 2004）中，进程管理器模式被描述为“在本质上很脆弱”。这是因为，一旦有人决定重启进程管理器，当时正在运行的任何内容都将会受到遭到破坏。因此，这种设计被广泛认为不太适合用于需要长时间运行的进程。 

现在来看看第二种排序模式。在下面这张照片中，一群人正在体育场上演墨西哥人浪。

来源。（此文件依据 Creative Commons Attribution-Share Alike 2.0 Generic 许可证获得了许可。）

在人群中，每个成员都清楚自己何时应该站起来并举手，无需任何人指挥。在庞大的足球场中，发生的事情复杂多样，远远超出了编排的应对能力范围。这是下一个排序模式类型的示例，其称为编舞（Choreography）。

编排（Orchestration）是大多数开发人员首先考虑的明显设计选择，然而，不那么明显的编舞（Choreography）往往是大幅改进的重写/设计，与事件结合使用时效果非常好。

这一点在微服务世界中显得尤为重要，因为需要排序的服务可能达数百个。但同样，在可能发生长时间运行的站立、测试和拆解型管道活动的情况下，编舞（Choreography）样式是一种更加可靠和实用的模型。

Tekton 管道从单独的容器构建而成，这些容器通过 K8 API 服务器上的内部 Kubernetes 事件进行排序。它们是事件驱动编舞（Choreography）排序类型的一个示例。没有单个进程管理器会出现锁定、重启、占用资源或其他形式的故障。 Tekton 将允许每个容器集在需要时实例化，以便执行它负责的管道进程的任何阶段。完成后，它将关闭，并释放其使用的资源以便用于其他活动。

通过重用实现松散耦合和节奏的理想状态

Tekton 还展示了软件架构中所谓的松散耦合，就像下面的儿童玩具火车照片：

“木轨道玩具火车”，来自 Ultra-lab，依据 CC BY-SA 2.0 获得了许可。 

火车机车与车厢之间是通过磁力连接的，因此孩子可以单独使用机车，也可以将它与各个车厢连接起来，当然还有介于两者之间的各种选项。 

孩子还可以改变车厢的顺序；例如，如果他们愿意，可以将浅绿色和黄色颠倒过来。如果他们有第二列类似的玩具火车，那么一列中的所有车厢都可以添加到另一列中，从而组成一列“超级火车”。

这解释了为什么“松散耦合”是软件设计的最佳架构。它在本质上促进了重用，而这正是 Tekton 背后理念的重要组成部分。在构建之后，组件可以非常轻松地在项目之间共享。

在谈到耦合时，我们应该探索松散耦合的反面，即紧密耦合。现在让我们用另一个儿童玩具作比喻：

“09506_Pull-Along Caterpillar”，来自 PINTOY^®，依据 CC BY-SA 2.0 获得了许可。 

毛毛虫也包含多个体节，但它们是固定的；即，其顺序无法更改。您无法减少体节的数量，同样，也无法通过增加体节将其变成超级毛毛虫。如果孩子只希望他的毛毛虫有三个体节，那么他们必须说服父母购买另一条毛毛虫。

在这个例子中，我们可以看到，紧耦合不会促进重用，而实际上会强制复制。

没错，我赞同 Jenkins 管道可以松散耦合，并且代码可以在不同项目间共享。但这并非固定不变，它在很大程度上取决于管道的设计方式。 

此外，也可以选择将一个 Jenkins 管道用于所有项目。然而，这种做法具有局限性，并且很快您就会发现，某个项目的特定需求与这种“一刀切”的方法并不契合。即，单一管道设计的完整性遭到了破坏。 

Tekton 本质上是声明式的，其管道设计与木火车玩具的构造有着异曲同工之妙。从直观角度来看，我们可以将 Tekton 的高级别对象——“管道”视作火车的机车。而管道包含的一系列任务则如同一节节车厢。不同的管道可以包含相同的任务，只需进行参数调整与重用即可。因此，松散耦合的可参数化任务串联在一起，形成了管道。Tekton 极大促进了松散耦合，因此直接带来了重用的机会。换言之，一个项目的工作成果可以轻松地在其他项目中被提取、整合和使用。

此外，Tekton 也只是额外的 Kubernetes 对象定义，这意味着它们可以轻松地与“一切即代码”方法和 GitOps 搭配使用。管道代码可以与其他集群/命名空间配置一起，轻松地应用到集群。 

为什么这一切很重要？

其之所以重要，是因为正式的开发、测试和 UAT 型环境的概念在很大程度上属于旧时代的遗留物。追溯到这些固定环境的时代，人们不得不购买物理服务器，并明确指定其各自的用途。 

过去的做法正是如此。在 OpenShift 和“一切即代码”、“宠物式”与“牲畜式”等概念的现代世界中，我们完全有理由利用管道和测试来动态地实例化这些环境，并运行它们。一旦任务完成，这些环境可以被彻底销毁，从而为其他测试或用途腾出空间。 

对于大多数公司而言，现状显然并非如此。其中一个可能的原因便是我们迄今为止所掌握的工具尚不能充分满足需求。

结论

OpenShift 等技术为我们解锁了诸多过去难以企及的机遇，而全世界仍在奋力追赶这股技术浪潮。 

鉴于这些计算资源至少在夜间的大部分时间都处于闲置状态，通过自动化测试来提升软件交付质量的潜力几乎是无限的。长久以来，我虽时常琢磨这类创新思路，却未曾将 Jenkins 视为适合此类工作的理想工具。然而，当我以开放的心态首次邂逅 Tekton 时，我迅速意识到它正是那个完美之选。 

Tekton 自诞生之初便考虑了与 Kubernetes API 和安全模型集成，并强烈倡导松散耦合/重用的理念。它是事件驱动的，遵循编舞（Choreography）模型，因此非常适合控制长时间运行的测试类进程。管道工件只是额外的 Kubernetes 资源（容器集定义、服务帐户、机密等），能够轻松地融入“一切即代码”的世界，与 k8 型生态系统的其余部分保持一致。

每个应用团队都可以拥有自己的管道代码，这些代码在不执行时几乎不占用资源，从而实现了“分布式 Jenkins”的优势，避免出现闲置负载。Apache Maven 之所以迅速成功，是因为它彻底改变了游戏规则，通过引入一种严格的 Java 项目组织方式，使得开发人员能够轻松地明确不同项目的构建配置。Tekton 对管道也进行了这样的革新，让任务的重用流程变得简单明了。

21 世纪初，Cruise Control 作为首个 CI 工具问世，但从个人经验来看，其使用难度较高。当时的 Jenkins 则显得是对先前产品的显著改进。而在 OpenShift/k8s 的生态系统中，Tekton 很像是管道技术发展的下一个飞跃。

了解更多

• 红帽 OpenShift 上的云原生 CI/CD