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

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

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