根据ActiveState的CI/CD 2020状态调查结果，Jenkins是市场上最常用的CI/CD工具。作为市场上最早的工作运行者之一，它有足够的时间来获得普及，并且是推进构建和交付软件的DevOps方法的一个重要组成部分。
由于有1800多个插件，Jenkins非常容易扩展--有了正确的插件集，你几乎可以做任何事情。插件库允许每个Jenkins用户最终获得个性化的体验，这在很大程度上取决于他们安装的插件。
插件可能是Jenkins的核心，但它们也很快成为使用Jenkins的团队的负担。为成长中的团队和公司管理Jenkins平台很快就会成为一个瓶颈，拖慢你的速度而不是提高你的敏捷性。
在本指南中，你将进一步了解Jenkins的一些缺点，以及了解一些替代方案。
什么是Jenkins插件？
插件是使用Jenkins的核心，它们在安装过程中首次出现，在那里你被要求选择一个插件来开始使用。默认安装有大约20个插件，加上你在安装时选择的任何插件。这些插件负责将你的CI/CD与外部工具（如GitHub或Bitbucket的版本控制）集成。插件还扩展了Jenkins的能力和工作方式。甚至协调构建的管道系统也是一个插件，可以使用其他插件进行修改。
你可以通过市场向Jenkins添加新的插件。市场上的所有插件都是基于社区的，并且是开源的，这意味着任何人都可以创建一个符合他们需求的自定义插件，并将其列在市场上。通常，在选择一个插件时，有三件重要的事情需要关注。
插件的受欢迎程度可以通过安装的数量来评估
它的维护情况如何，这可以通过查看最近一次更新的时间来估计
需要的依赖性，例如你需要安装的其他插件
为什么Jenkins的插件可能是坏的
虽然大量的插件曾经被看作是平台的优势，但现在它经常被看作是一个缺点，或者至少是一个挫折的来源，这助长了许多人对Jenkins的爱恨情仇。
当它第一次发布时，Jenkins感觉像是一个美妙的自助服务环境，一个可靠的开发者或团队可以通过Jenkins管道和正确的插件集做几乎任何事情。然而，今天，你需要真正的Jenkins专业知识来维护Jenkins服务器，这是一个缺点，特别是与市场上较新的SaaS CI/CD选项相比。
有许多与Jenkins插件生态系统相关的反复出现的问题。第一个是无休止的升级和依赖性的循环。一个简单的项目可能需要超过25个不同的插件，因为你安装的每一个插件都可以安装其他插件，而这些插件是第一个插件工作所需要的。这就导致了这样一种情况：你可以安装两个插件，每个都需要相同的第三个插件来工作，而每个都依赖于第三个插件的不同版本，导致安装问题或错误。
当你发现一个插件有安全漏洞时，更大的问题就出现了。如果你发现一个插件不安全或有漏洞，你可以在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插件。像这样的平台还可以与你现有的工具连接，使你的团队更加敏捷，反应更加迅速，让你专注于创造伟大的软件，而不是管理你的管道。
今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
Original: https://www.cnblogs.com/wintersun/p/16390169.html
Author: PetterLiu
Title: 为什么你应该停止依赖Jenkins的插件？