为什么你应该停止依赖 Jenkins 插件

为不断壮大的团队和公司管理 Jenkins 平台可能很快成为一个瓶颈，降低而不是增加您的敏捷性

根据 ActiveState 的 CI/CD 2020状态调查结果，Jenkins 是市场上使用最多的 CI/CD 工具。作为市场上的第一批工作运行者之一，它有足够的时间来赢得人气，并且已经成为推进 DevOps 构建和交付软件方法的关键组成部分。

由于有1800多个插件，Jenkins 非常容易扩展ーー只要有一组正确的插件，您几乎可以做任何事情。插件库允许每个 Jenkins 用户最终获得个性化体验，这种体验很大程度上取决于他们所安装的插件。

插件可能是 Jenkins 的核心，但它们也很快成为使用 Jenkins 的团队的负担。为不断壮大的团队和公司管理 Jenkins 平台可能很快成为一个瓶颈，降低而不是增加您的敏捷性。

在本指南中，您将更多地了解詹金斯的一些缺点，以及了解一些替代方案。

什么是Jenkins插件？

插件对于使用 Jenkins 非常重要，以至于它们在安装过程中首次出现，要求您选择一个插件作为开始。默认安装包含大约20个插件，以及在安装过程中选择的任何插件。这些插件负责将 CI/CD 与用于版本控制的 GitHub 或 Bitbucket 等外部工具集成。插件还扩展了 Jenkins 的功能及其工作方式。甚至编排构建的管道系统也是一个插件，可以使用其他插件进行修改。

(Jenkins installation)

您可以通过市场向 Jenkins 添加新的插件。市场上的所有插件都是基于社区和开源的，这意味着任何人都可以创建一个符合自己需求的自定义插件，并将其列入市场。通常，在选择插件时要注意以下三点:

Jenkins plug-in marketplace

为什么Jenkins插件会很糟糕

虽然大量可用的插件曾经被视为平台的优势，但现在它经常被视为一个缺点，或者至少是一个挫折的来源，这种挫折加剧了许多人与 Jenkins 之间的爱恨关系。

当它第一次发布时，Jenkins 感觉像是一个非常棒的自助服务环境，在这里，一个可靠的开发人员或团队可以使用 Jenkins 管道和正确的插件集做几乎任何事情。然而，今天，您需要真正的 Jenkins 专业知识来维护 Jenkins 服务器，这是一个缺点，特别是与市场上较新的 SaaS CI/CD 选项相比。

有许多与 Jenkins 插件生态系统相关的经常性问题。第一个是无休止的升级和依赖周期。一个简单的项目可能需要超过25个不同的插件，因为您安装的每个插件都可以安装第一个插件工作所需的其他插件。这导致了这样一种情况: 您可以安装两个插件，每个插件都需要相同的第三个插件才能工作，并且每个插件都依赖于第三个插件的不同版本，从而导致安装问题或 bug。

当您发现插件存在安全缺陷时，会出现更大的问题。如果您发现某个插件不安全或存在 bug，那么您将在 GitHub 上打开一个问题并等待该插件被修补，但是如果修补程序永远不会出现怎么办？您可以忍受一个安全缺陷，找到一个替换插件并修改所有管道以适应新插件，或者分叉插件并对其进行修补，然后成为该插件的新维护人员。考虑到每天都会发现新的数字证书认证机构，并且需要频繁地对插件进行补丁，这可能很快就会成为一项繁重的工作。

它还会导致 Jenkins 插件的另一个问题。即使是非常流行的插件也经常被原始维护人员维护得很糟糕或者完全放弃。从维护人员的角度来看，这是完全可以理解的。创建插件是为了解决问题，而大多数维护人员并不打算在他们的工作之上成为专业的插件维护人员。但是，在用户方面，这导致插件支持不足，因为维护人员是社区成员，没有义务无限期地维护插件。

Jenkins 插件的最后一个问题是缺乏透明度。如果不仔细检查代码，就无法知道插件的作用域，并且限制插件在服务器上的访问和操作的能力有限。因此，在选择插件时，信任因素非常重要，您需要小心减少潜在的攻击面。

Jenkins 插件如何影响您的组织

当您考虑在一个团队中使用 Jenkins 时，这些问题可能看起来不是一个大问题。他们可以使用自己喜欢的插件集构建管道基础，并且假设没有安全问题，那么一切都很好。

但是，当公司发展壮大，更多的开发人员加入进来，新的团队被创建，并且有多种应用程序和服务，Jenkins 插件不能很好地扩展。如果让每个人都使用他们想要的任何插件，那么很快就会遇到依赖性和升级问题。另一方面，如果您限制了开发人员可以使用的插件，那么您最终将得到一个沮丧的团队和开发人员，他们感觉您正在阻止他们自动化工作流程的繁琐方面。

Jenkins斯只允许使用一个主节点，因此在设计时就没有考虑到高可用性。作为这些设计选择的结果，必须重新启动服务器来更改配置或安装新插件会导致停机，并打断组织中所有依赖 Jenkins 的人的工作。这个困境没有简单的解决办法。为每个团队创建一个 Jenkins 服务器将是极其低成本的，并且会在团队之间建立筒仓。拥有独立 Jenkins 服务器的团队将基于不同的插件集构建不兼容的管道，从而使您的团队无法彼此共享自动化工作。

您不能允许 Jenkins 成为一个真正的自助服务平台，因为这将是操作复杂的，并且会减少团队之间的合作。但是反对 Jenkins 插件的最大论点是插件是一种安全隐患。正如前面提到的，几乎所有插件都是社区创建和支持的。您需要相信维护人员使用安全性最佳实践，并保持插件针对新发现的漏洞进行补丁，如果正确完成，这可能是每周一次的工作。CI/CD 平台通常可以访问许多系统，并具有修改基础设施和与生产环境交互所需的凭据。这使得任何 CI/CD 平台都成为基础设施中非常敏感的一部分，安全性应该是这些工具的首要任务。

如何停止依赖 Jenkins 插件？

到目前为止，您已经很好地理解了 Jenkins 插件的一些问题。如果您正在考虑远离它们，转向更安全的基础设施，那么可以采取以下步骤。

仔细管理插件

创建一个精心挑选的插件的短名单，并坚持使用这些插件。此列表应同时考虑安全性和可维护性问题。一般来说，最好坚持使用提供与 GitHub 或 Amazon Web Services 等云供应商集成的插件，因为它们通常会得到这些云供应商的社区和开发人员的大力支持。例如，GitHub 插件是可以依赖的维护良好的插件。在主服务器上运行新插件和升级之前，请在辅助 Jenkins 服务器上测试新插件和升级。

避免使用改变 Jenkins 管道工作方式的插件，因为如果这些插件中断、不再维护或者出现安全漏洞，就需要重新修改整个管道。

通过检查插件的 GitHub 存储库来主动关注插件的健康状况，看看它们是否得到了积极的维护; 如果没有，那么您应该寻找一个替代品。这可以防止将来升级 Jenkins 服务器时停机，或者发现安全漏洞时停机。插件是具有潜在可利用漏洞的独立软件，攻击者可以利用这些漏洞来访问构建系统，以及 Jenkins 出于必要获得读/写访问权限的系统其他所有部分，比如代码库、云供应商和网络连接。正如 SolarWinds 通过构建管道事件注入恶意软件所表明的那样，CI/CD 管道是构建过程中受信任的一部分，所需要的只是一小段恶意代码，它不仅会让你的公司变得脆弱，还会让你的所有客户都变得脆弱。这个领域的极端敏感性使得插件监控和管理绝对至关重要。

依赖基于容器的步骤

容器技术使您能够将环境与它们的所有依赖性打包。多亏了 Docker 插件，您可以在 Docker 容器中运行 Jenkins 构建。Docker 容器可以使用为任务创建的映像并充当 Jenkins 代理，完成构建所需的所有依赖项，从而消除在服务器上安装插件的需要。

使用更少的插件

对于 Jenkins 插件问题，最简单的解决方案之一就是使用更少的插件。使用的插件越少，遇到的问题就越少。为了实现这一点，您可以选择脚本而不是插件。例如，发送 Slack 通知与向 API 发送 HTTP 请求一样简单，并且允许您避免依赖第三方插件。脚本可能比插件更可靠，因为您可以在本地使用它们来执行相同的操作。虽然这可能看起来比使用插件工作更多，但是您可以在整个公司共享您的自动化脚本，并在任何管道中使用它们，而不会影响 Jenkins 服务器。

第二种方法是尽可能多地使用 Jenkins 模板。模板允许您定义可重用的管道(作业) ，并添加一个抽象层，使开发人员更容易配置和使用 Jenkins。使用模板为您提供了一种识别所需插件的简单方法，因为您需要的插件就是模板中引用的插件。这为您提供了一个协作构建管道并减少在整个组织中使用的插件数量的场所。

结论

Jenkins 及其插件生态系统对于为其项目寻找 CI/CD 解决方案的人来说非常有吸引力。然而，维护不善的插件、多种不同的依赖关系和安全风险使许多人对该工具感到厌恶。

Jenkins 插件管理将影响您的组织，而管理不当的插件可能使您的组织处于危险之中。实现缓解策略很重要，比如通过定义标准作业或管道来最小化插件的数量，仔细管理插件，在单独的实例上测试插件和升级，以及使用基于容器的作业来减少对 Jenkins 插件的依赖。

如果您厌倦了管理 CI/CD 生态系统，包括您的 Jenkins 服务器，那么您可能会对一个无代码 DevOps 平台感兴趣，该平台提供集成以替换许多 Jenkins 插件。这样的平台还可以连接现有的工具，使您的团队更加敏捷和响应迅速，并允许您专注于创建优秀的软件，而不是管理您的管道。

来源：科技狠活与软件技术