Jenkins X将自动化管道引入Kubernetes

Jenkins持续集成服务器一直是DevOps浪潮中的重要组成部分。作为持续集成与持续部署环境中自动化任务的中央协调服务器，全球的开发和运营团队已经积极接纳Jenkins，并为之构建了多种扩展及构建包。 然而，从设计初衷角度来看，Jenkins并没有考虑到面向容器环境的迁移需求。

Cloudbees公司高级架构师James Strachen身为Jenkins X[1]项目负责人，他一直在思考这种迁移对Jenkins用户的意义及影响。

他表示，将CI/CD管道迁移到配备容器及容器编排工具（如Kubernetes）的基于容器云托管环境时，用户需要在构建、测试和部署过程中建立更高的自动化水平。Strachen说：“ 为了实现这一点，Jenkins X必须具备远超常规Jenkins的易学习性及易用性。”

“我们要做的，是打破少数人对相关知识的‘垄断’。这部分人往往对Jenkins非常了解，但是团队里的每个人都有权也有意愿参与其中。我们需要开发人员能够随时根据需求启动新的项目——这也正是微服务时代的最大差异优势所在。我们希望Jenkins自助服务能够像云一样全面覆盖。”

“Jenkins X的目标是将Jenkins转化为一种自助服务设备，允许任何开发人员启动新项目，而与之相关的全部管道及匹配元素都能够顺利到位。 当然，这并不是说团队成员完全不需要了解Jenkins，但更重要的是我们希望让CI/CD拥有与云服务类似的低准入门槛，”他解释称。

Strachen在3月中旬发表的一篇博文[2]中详细介绍了Jenkins X的技术细节，当时该项目才刚刚面向公众正式公布。在文章中，他解释称Jenkins X可用于设置Jenkins管道，自动生成Jenkinsfile和Dockerfile以定义应用程序的管道与打包步骤。

由于Docker和Kubernetes的运行活动同Jenkins设计环境存在一些差别，因此Strachen表示Jenkins X还需要将安全保障机制引入到复杂的容器镜像构建过程中。Strachen指出，用户可以利用自己的Dockerfiles或pop在管道中使用其最熟悉的容器构建工具。Strachen同时提到，Skaffold[3]是一种用于构建和标记Docker镜像的工具——尽管听起来很简单，但其意义却非常重大。

“[Skaffold]负责管理Docker和安全模型的复杂性事务。 如果您使用Google Cloud，则可能需要使用谷歌提供的容器构建器。 您可能需要在自己的Kubernetes集群中使用SaaS CI或本地Docker套接字。 这种方法会带来安全隐患，因为这意味着使用者将掌握设备的root权限。因此，绝对不可让他人访问生产集群中的Docker套接字。举例来说，在默认情况下，Jenkins S会假设用户处于开发集群当中，并有权访问Docker套接字。但很明显，这样的假设并不靠谱，”Strachen强调称。

Strachen认为这是未来Docker镜像构建层面的一大主要问题。“我们需要利用Skaffold以及其它同类工具将用户与高权限隔离开来。我希望这一目标能够尽快实现。”他曾听到未经证实的消息称，Skaffold可能会在未来几个月内获得上述能力。

“在开发群集上，我们允许用户使用Docker来构建镜像。 大家往往坚定地相信团队中的开发者不会利用这些硬件挖掘比特币。 而在生产群集上，我们不需要构建镜像，而只是使用已经构建完成的现成镜像。 这是一个简单的方法，易于实现，而且能够有效消除风险。我认为从长远角度来看，为了确保在不使用Docker守护进程、root或其它特殊权限的前提下构建Docker镜像，最好是能够将Docker构建流程彻底移出Kubernetes集群之外，”Strachen表示。

稳定性和兼容性

未来，Strachen表示Jenkins X团队在稳定性和兼容性方面还拥有多项开发目标。 “最重要的是检查一切组成元素。 在同一时间内支持多种云环境可谓极具挑战性。 因此，我们的第一项重点在于构建起坚如磐石的集群系统。 此外，我们还需要支持更多的Git供应程序以及问题跟踪器。 我们正在添加Jira支持能力，此外社区中也有部分贡献者正在进一步扩展Git供应程序的支持范围，例如GitLab和BitBucket[4]，”Strachen表示。

“着眼于更长期的目标，我们将着力改进反馈与整合等机制。 我们拥有一份宏观路线图，主要关注增加构建包的数量，此外还需要实现更广泛的语言支持能力，”Strachen说。

核心开发团队当前的另一项研究目标是与Anchore CI/CD安全扫描软件进行集成。 Anchore[5]负责根据漏洞数据库分析代码与Docker镜像。

在实现上述复杂目标的过程当中，有一段代码已经为Jenkins X团队节省了大量时间，这就是UpdateBot。 这款小工具运行在其他项目更新库的依赖关系库中，能够自动提交请求以使用新的依赖项。

“有时候，我们需要使用上游库，”Strachen说，“而其他团队正在使用下游类库。通常情况下，如果不存在信息交换，这些库很少需要进行更新。但在实际更新过程中，我们需要采取持续部署的处理方法。UpdateBot[6]要做的在执行过程中严格遵循持续部署原则。这些库不会被部署为Docker镜像，而是作为版本更改、经过更新的XML文件或基础Docker镜像文件存在。”

Strachen表示，这种在更新过程中持续面向下游消费者推送请求的作法，能够有效防止错误因未被及时发现而在更新周期之后集中爆发。

“我个人最欣赏的一点在于，如果上游开发者犯了错误，他们会立刻发现问题。这是因为在持续发布的版本中，所有相关请求都会遭遇故障。如此一来，将不致出现某一团队的失误导致另一团队的工作成果付之东流，并有效避免由此引发的团队间摩擦与挫败感。必须承认，犯下错误的团队往往对此毫不知情，因此在传统变更流程当中，当人们意识到存在严重问题时，其间往往已经进行过无数次变更——也就是说根本无法判断问题到底源自哪里。而持续部署原则将彻底攻克这一难题，”Strachen总结称。