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

  • Daniel Bryant
  • 张卫滨

2018 年 4 月 8 日

话题:持续集成DevOps持续交付语言 & 开发Kubernetes

看新闻很累?看技术新闻更累?试试下载 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

持续集成DevOps持续交付语言 & 开发Kubernetes