2024年该抛弃Jenkins持续部署(CD)！

在DevOps流行的今天，Jenkins管道作为一个占有量很大的可用于持续部署(CD)工具，在许多企业内部都被作为广泛应用。不管其部署量大，私有脚本化也许多，当然问题也许多、也很不安全。虽然Jenkins在持续集成(CI) 场景中表现出色，但将其用于CI/CD被证明是一个不太理想的工作流程：繁琐、低效、不安全！

概述

Jenkins 作为一款开源自动化服务器脱颖而出，配备了用于简化构建、部署和自动化项目的插件。它依旧是DevOps领域备受青睐的工具，下载量超过1500万次。

Jenkins广受推崇的缘由是其成熟度和经过验证的弹性。Jenkins 的设计思考到了灵活性，提供了广泛的软件开发工具包(SDK)，几乎涵盖了所有可以想象的方面。无论是想监管AWS环境还是与GitHub集成，都有一个专为该特定目的量身定制的插件。虽然这种适应性有其缺点，但它是Jenkins受欢迎并在众多组织中取得成功的主要因素。

缺点

坦率地说，Jenkins作为软件已经开始显现出它的时代性了。它最初开发于2004 年，并不是为云原生而设计的。尽管开发人员和DevOps团队已经找到了使其发挥作用的方法，但其植根于主节点和多个构建代理的架构反映了数据中心和静态服务器时代的过时模型。

虽然这种方法不必定是坏事，但对插件的依赖会带来额外的配置，一般很复杂很繁琐还很不安全。例如，使用Jenkins Kubernetes插件配置容器涉及Groovy文件中使用YAML，从而增加了错误风险。插件语法的多样性使事情变得更加复杂。

管理Jenkins被认为具有挑战性，与更现代的工具相比，它对Groovy脚本的要求增加了复杂性。尽管Jenkins的SDK很有用，但一些插件是有限的并且仅具有基本功能。而且大多数插件一般没有很好的文档记录，并且需要通过大多数用例编写脚本。最重大的是，大多数用户抱怨有缺陷的插件，从依赖的角度来看，管理起来很麻烦。由于相互依赖性，某些插件无法修复安全漏洞，而且由于许多时候需要安装许多第三方的功能插件，这些插件良莠不齐，质量根本无法保证，甚至有可能是含有恶意脚本的插件。

由于其提供了图形界面，且需要在该界面执行远程脚本，所以业务服务器对其开放端口和SSH证书访问，所以是一个巨大的安全隐患所在，许多用户由于Jenkins被攻克，从而导致整个业务服务器都被攻陷。

用户界面明显过时，需要大量人力资源来操作。 尽管尝试减少脚本依赖，Jenkins 依旧以脚本为中心。这导致DevOps团队承担着维护基础设施、更新插件和故障排除的重担。

一般一个小厂来说维持Jenkins也都需要2到5名工程师的日常努力。虽然在各种任务中都很有价值且精通，但随着运营的扩展，仅依赖Jenkins的局限性变得明显，导致维护、运营挑战和潜在中断的增加。

去掉Jenkins CD流程

软件交付和部署应该与CI 提供商分开，CI提供商一般是专门为运行单元测试和编译构建工件而构建的。这种分离有一些主要动机，其中包括：

部署一般是比标准代码更改更长的运行过程，包括跨多个环境的分阶段发布和多轮集成测试。

单独的CD系统允许对微服务依赖项进行串联测试并独立回滚，从而轻松管理微服务依赖项中的偏差。

分离CD不需要Jenkins等构建服务或Circle-CI等云服务中的主证书，从而增强整体平台安全状况。

中央CD服务可以极大地简化多态基础设施提供商的管理，由于基于拉动的架构自然可以扩展到多云或本地交付模型。

Jenkins充当CI服务器，严重依赖脚本。Jenkins管道功能由一套插件组成，有助于在Jenkins中实现和集成CD管道。这种情况对建立平稳、全面的CI/CD管道提出了挑战。

Jenkins管道功能不包含任何开箱即用的功能。相反，必须编写自定义脚本来管理或执行上述所有任务。Jenkins管道只是将解决方案与脚本硬编码在一起的另一种方式。

团队每一个成员的时间都很宝贵，不能花在维护部署管道上。现实情况是，将管道编写在一起会带来更多复杂性，从而增加管道失败的可能性。

当然，如果愿意，可以通过大量编辑一些Jenkins文件来手动编写Canary部署到Kubernetes集群的脚本，但这并不容易，而且最终会很痛苦。

Gitlab Runner

随着应用程序和服务的发展，团队不应该编写和维护CD流程。CD的功能需要基于可扩展、安全、基于代理的拉式架构的思考，该Cd无需直接访问其部署到的任何集群而能对集群进行管理，这样就可以管理任何云、本地、边缘甚至运行KIND的本地电脑中的工作负载。

可能许多企业都在内部托管GitLab作为代码管理平台，而又会使用Jenkins进行CI/CD，将GitLab和CI/CD交互，与其这样周折，不如直接使用GitLab自带的CI/CD客户端GitLab Runner。

GitLab Runner作为CI/CD 配合GitLab使用以在管道中运行作业的应用程序。GitLab Runner由Golang语言开发轻量而高效，本身只提供客户端任务执行，不提供任何图形界面，其管理界面可以只在GitLab界面集成（可过滤了大量危险脚本操作），从而极大保障了业务平台的安全性。

GitLab Runner的配置也及其简单，配置好和GitLab服务器的连接好后，就无需其参与，只需在GitLab界面配置和提交.gitlab-ci.yml就可以实现CD任务的发布，后续可以查看、监控和统计执行的情况。

总结

本文分析了，当前形势下为Jenkins存在的各种问题和隐患，以及为啥要去掉Jenkins CD流程进行持续发布的缘由，最后推荐了更适合的GitLab Runner的缘由，当然GitLab Runner对GitLab只是很小的一环，其还提供了整个Auto DevOpt栈和DevSecOpt整体解决方案，值得大家抛弃Jenkins更换的更好、更安全的一栈是解决方案。