CloudBees发布“Jenkins X”：面向部署到Kubernetes中的现代云应用的CI/CD解决方案

by

• Daniel Bryant

摘要：

James Strachan和CloudBees团队发布了开源的“Jenkins X”平台，它是针对部署到Kubernetes上的现代云应用所提供的持续集成和持续交付（CI/CD）解决方案。Strachan正在赞助JEP 400，它是一个正式的提议，用作“占位”。该提议申请Jenkins X成为Jenkins基金会的子项目。

James Strachan和CloudBees团队发布了开源的“Jenkins X”平台，它是针对部署到Kubernetes上的现代云应用所提供的持续集成和持续交付（CI/CD）解决方案。Strachan正在赞助JEP 400，它是一个正式的提议，用作“占位（stake on the ground）”。该提议申请Jenkins X成为Jenkins基金会的子项目。

Jenkins X使用分发版本的Jenkins作为核心的CI/CD引擎，并倡导一个特殊的Git分支和存储库模型。在分发版本中，还构建了一些额外的工具和服务用来适应该模型。在Jenkins最近的一篇博客文章中，CloudBees的高级架构师Strachan认为Jenkins X开发模型代表了“开发Kubernetes应用的最佳实践”。这是基于他和他的团队开发Fabric8的经验得出的结论，Fabric8项目是具有类似使命的项目，它试图根据DevOps报告的现状提供工具和支撑进程的具体实现。

如果开发人员遵循建议的最佳实践，那么Jenkins X会组合所需的各个组成部分，比如Jenkins、Kubernetes、Git、CI/CD等，这样的话，它们就能“马上具备生产能力”。Strachan认为这类似于Maven所带来的优于Ant构建工具的特性，Maven鼓励开发人员使用标准的生命周期模型（DRY），以便于实现更高的生产效率。

与之相关联的Jenkins增强提议（Jenkins Enhancement Proposal，JEP）为JEP 400，它提供了一些推荐最佳实践的样例，这些样例都是通过CI/CD将云原生应用部署到Kubernetes中：

• 主分支应该始终是整洁的并且可以随时发布。不允许使用长时间的特性分支，以便于“保持精简”；
• Pull request（PR）用于处理新的变更，然后它会提交到主分支上。当PR变更的时候，会触发CI测试。只有当所有的CI检查都通过并且所需的代码审查都满足的时候，PR才能合并到主分支上。
• 释放版本是基于主分支生成的，它会生成不可变的制件（JAR、二进制、Docker镜像、Helm charts等）。释放版本的生成可以是手动触发的，也可以是新PR合并后自动生成的，甚至还可以基于一定的间隔频率生成。
• 哪个版本的服务运行在哪个环境之中是在一个单独的环境Git存储库中以声明式的方式进行管理的。将变更push到环境Git存储库中就会引发部署，该存储库会进而触发环境管道。这种方式通常又被称为“GitOps”（其灵感来源于Weaveworks的Alexis Richardson），它类似于人们利用Git开发Chef recipes和Ansible playbooks的方式。

Web应用开发人员在实践CD的过程中，所带来的“环境”的概念是一个非常棒的实践，例如，“dev”、“staging”和“production-1”。Strachan指出，这种方式允许“开发人员的变更能够通过测试和staging以有序的工作流程进入到生产环境中”，但是他认为传统的Jenkins模型并没有将环境的概念作为第一等的公民。Jenkins X通过引入“环境（environment）”的理念弥补了这一空白，环境是构建在更通用的Kubernetes概念之上的，这些通用的概念包括命名空间(namespace)和标签（label）。然后，开发实践可以建模为按照级联的方式从一个环境提升到另一个环境。

为了让通用的任务更加容易，Jenkins X定义了一个命令行工具jx，它封装了一些高层级的操作。Jenkins X CLI不仅能够允许开发人员在本地开发机器上使用，还能在Jenkins管道的执行中使用，这是一种声明式指定和实现CI/CD构建管道的机制。

Jenkins X CLI是Jenkins X的主控制工具，它能够实现如下的功能：

• 在任意Kubernetes集群中安装Jenkins X；
• 在公有云上从头开始创建新的Kubernetes集群；
• 为每个团队创建环境；
• 导入已有的项目，或创建新的Spring Boot应用。除此之外，该工具还能：
  
  • 自动创建CI / CD管道和webhooks；
  • 当一个分支合并到主分支时，创建新的发布版本并将其提升到各个环境中；
  • 当出现PR时，支持基于此构建“预览环境（preview environment）”。

Jenkins博客建议“Helm charts是在Kubernetes上安装和更新应用的标准打包机制”（但是，值得一提的是最近发布的Google Kubernetes开发工具“Skaffold”并没有基于Helm进行构建）。与之对应的是，Jenkins X提供了一个Helm chart，它允许在任何Kubernetes集群上安装Jenkins X。在项目的构建和部署过程中，Jenkins X重用了来自Azure的Draft。这允许语言和框架特定的“构建包（build packs）”能够很好地得以维护，在构建包中会包含构建、测试、发布和部署不同类型的应用所需的默认Dockerfile、Jenkinsfile和Helm Chart文件。

开发人员和团队不需要花精力研究如何将软件打包为docker镜像、为了在kubernetes上运行应用而创建Kubernetes YAML文件、创建预览环境，甚至不需要学习如何使用声明式的pipeline-as-code Jenkinsfiles文件实现CI/CD管道。它全是开箱即用的自动化过程！所以，你只需要专注于如何交付应用本身的价值就可以了！

Jenkins X并不是通用的Jenkins，无法对它进行修改做任何想做的事情。它是专门针对Kubernetes和云原生使用场景的，因此在JEP 400提案中，Jenkins X定义为“Kubernetes的原生Jenkins”。

随着时间的推移，我们看到能够基于在Jenkins X上学到的知识，改善Jenkins的核心，所以Jenkins本身可以用到更多的云原生配置中。这不仅有利于Jenkins X，还有利于Jenkins的其他使用场景。这些变更将会形成单独的JEP提案。

关于Jenkins X的其他信息可以在项目的站点上获取，“Getting Started”指南提供了安装平台的详细信息，其中既包括本地安装也包括在已有的Kubernetes集群中安装。

查看英文原文：CloudBees Release "Jenkins X", a CI/CD Solution for Modern Cloud Applications Deployed to Kubernetes