专访 Rancher CEO 梁胜博士：企业应该如何理解云原生 CI/CD？

前言

云计算技术的普及全面变革了 IT 基础设施，技术团队组织架构、研发流程也随之变化，越来越多的组织和团队开始接受 DevOps 理念。在 DevOps 的趋势下，持续集成（CI）和持续交付（CD）具有支柱性地位，使用新一代面向云计算的工具和技术搭建 CI/CD 流水线可以实现应用程序的自动构建、自动测试和自动部署，提高发布频率，利于构建可高效迭代的云原生应用。

近期以 Jenkins 带头发起的持续交付基金会（CDF）的成立，也说明了 CI/CD 理念及工具得到了越来越多的认可和应用，在研发和软件交付过程中有很大的价值。此次 InfoQ 采访了 Rancher Labs CEO 梁胜博士，谈谈如何理解云原生环境下的 CI/CD，以及 CDF 成立的意义。

上云 VS 云原生

在梁胜博士看来，上云≠云原生。

云原生（Cloud Native）的字面意思是开发应用的时候要遵循云端的原生技术。现在我们说的云原生，主要包含以下的含义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行弹性可扩展的应用。通过构建容错性好、易于管理和便于观察的松耦合系统，结合可靠的自动化手段，云原生技术可以使工程师能够轻松地对系统作出频繁和可预测的重大变更（CNCF 对云原生的定义）。

具体的云原生技术包括：

• 微服务

• 容器

• Serverless

• Service Mesh

• 不可变基础设施

• 声明式 API

• ……

这些技术在传统的应用架构或基础设施里是不存在的。

云原生架构最关键的特性是动态扩展以支持大量用户及大型分布式开发和运营团队。因此，一些需要解决的典型问题如下：

1. 动态扩缩容能力；

2. 自动处理破坏应用程序可用性的跨层故障；

3. 通过确保组件本身提供松耦合来适应大型开发团队的能力；

4. 能够使用几乎任何类型的基础设施（计算、存储和网络）。

如果仅仅只是把传统应用打包一下搬到公有云或者私有云上，而没有利用云原生相关技术，应用不能做到弹性可扩展、高可用、按需交付等，这就不算云原生。

CI/CD 给企业带来的价值

CI/CD 的存在已经有十几年的时间了，其主要作用就是可以使企业在提升开发和发布的迭代速度的同时，还保证应用程序的质量。虽然一般 CI/CD 连着说，但是 CI 跟 CD 的概念不一样。

• CI （Continuous Integration）代表持续集成，意味着研发人员对代码做了改变之后，可以直接来编译和构建二进制代码，用二进制代码来运行一些测试。

• CD 代表持续交付（continuous delivery）和持续部署（continuous deployment），持续部署要比连续集成要复杂很多，部署时要考虑很多方面：应用需要部署到哪些环境、其依赖包的版本怎么使用、如何做环境配置管理等都需要考虑在其中。

所以很多企业和团队能做到连续集成的层面，但其实并没有达到持续部署的状态。

云原生的环境本质上很适合应用部署。传统的应用在做部署的时候，常常有一些手动的步骤，会比较困难。而云原生技术本身就强调自动化，相对而言更适应 CI/CD 框架。一般来说云原生应用的用户在开发过程中，集成、部署和测试等流程上的自动化程度已经比较高了，所以云原生 CI/CD 实施起来会更容易。

云原生场景下的 CI/CD 当然也会有一些挑战。云原生的应用模块较多，可以有多个微服务，相对来说结构很复杂。所以在云原生环境下，部署、集成、构建和测试等步骤都比较多，做好每个步骤之间的连续性也相对复杂。

云原生部署策略

在应用部署的时候，我们当然可以把整个现有的应用完全切换过来，但是万一中途出问题了怎么办？为了应对这种情况，在云原生环境下 Kubernetes、Istio 等工具都能支持持续部署，可以进行蓝绿部署和金丝雀部署。

蓝绿部署：蓝绿部署能自动防御故障的流程。在这个方法中，两个相同的生产环境并行工作。一个是当前运行的生产环境，接收所有的用户流量（称之为蓝）。另一个是它的副本，但是闲置（称之为绿）。两者使用相同的数据库后端和应用配置：

应用的新版本部署在绿色版本环境中，进行功能和性能测试。一旦测试通过，应用的流量从蓝色版本路由到绿色版本。然后绿色版本变成新的生产环境。

如果绿色版本激活后发现了问题，则将流量路由回到蓝色版本中。

金丝雀部署：金丝雀部署和蓝绿有点像，但是它更加规避风险。你可以阶段性的进行，而不用一次性从蓝色版本切换到绿色版本。

采用金丝雀部署，你可以在生产环境的基础设施中小范围的部署新的应用代码。一旦应用签署发布，只有少数用户被路由到它。最大限度的降低影响。

如果没有错误发生，新版本可以逐渐推广到整个基础设施。

现在的 CI/CD 基本上都是用这两种方法来降低软件的部署风险，Kubernetes 和 Istio 也支持这两种部署方式。所以云原生环境下的 CI/CD 也是依赖于 kubernetes 或 Istio 平台里的高级发布功能来保障软件交付的稳定性，让一小部分用户先使用新版本，等这一小部分成功以后再让更多的用户使用，中间如果出问题随时可以回滚到原来的版本。

CI/CD 管道构建

下图展示了一个软件在其最终交付给客户或者投入上线之前，它在其生命周期内各个阶段中的移动过程，也就是一套 CI/CD 管道的流程，整个周期包括：

构建-测试-部署-自动测试-部署到生产环境-度量和验证。

传统意义上，管道中使用的各个硬件系统都有配套的软件（操作系统、应用程序、开发工具等）。在极端情况下，每个系统都是手工设置来定制的。这意味着当系统出现问题或需要更新时，这通常也是一项自定义任务。这种方法违背了持续交付的基本理念，即具有易于重现和可跟踪的环境。

梁胜博士介绍，在云原生环境下容器技术被大量采用，但是实际上 CI/CD 并不需要容器，直接用基础设施云的 API 就可以实现。不过用容器有一些好处：

• 可以加快应用的迭代速度更快；

• 出错的可能性更小；

• 便携性很高，可以将应用轻松部署在多个不同的基础设施云上，可以实现混合云。

基于容器设置 CI/CD 的管道会比用传统的方法设置 CI/CD 的管道容易一点。容器的好处在于执行环境一致性，只要调通了，应用在管道里、管道外和物理机上运行没有差别。

CI/CD 管道设置上本身的挑战在于自动化程度。在设置了管道之后，要根据中间每一个步骤的结果要来判断各种状态，这一步成功还是不成功，再来决定下一步应该做什么。所以一旦设置了管道，对自动化、监控和运维等方面的要求会高很多。

当应用在管道里运行的时候，我们实际上是看不到管道里的运行情况的。而在传统的 CI/CD 中，如果全是手动操作，每做一件事情出错了我们就可以看到，可以随时去调错。设置了管道之后，整个管道就完全自动化了，但事实上复杂的管道在设置一段时间之后才会趋于稳定。后续还要不断调试和排错，有时出了问题并不是程序上的问题，而是管道本身的问题。所以设置管道也必须经过这不断尝试的过程。

不过磨刀不误砍柴工，一旦管道设置好了之后，就能达到自动化的效果，软件交付的效率能明显提升。

Rancher pipeline

作为基于 Kubernetes 的开源企业级容器管理平台，Rancher 对于 CI/CD 管道解决方案也有自身的考量。对于用户而言，大部分企业用户或者互联网用户已经设好了 CI/CD 的管道，甚至有很大的 CI/CD 的平台。这也就意味着 Rancher 无需提供内置的 CI/CD 解决方案，而用户在使用 Rancher 的过程中，可以直接调用 Kubernetes API 接口和自己的 CI/CD 管道或平台进行对接。

随着 Rancher 的使用不断普及，针对还没有构建自己的企业级 CI/CD 平台的用户，Rancher 构建了一个简单易用的 CI/CD 管道：Rancher pipeline。这套解决方案的最大特点是简单易用，使用户无需从头开始使用其他工具设置 CI/CD 流水线。Rancher pipeline 在灵活性和功能上来说略为简单，但它可以使很多用户，特别是现在还没有 CI/CD 平台的用户，很快地享受到 CI/CD 的好处。

Rancher pipeline 由 Rancher server 中的 pipeline controller 和用户集群中包括 Jenkins、Minio 的组件组成。Rancher server 接收到代码提交事件后，会按照源码仓库中文件形式定义的流水线，分发构建任务到用户集群的 Jenkins 中，并动态创建 Kubernetes Pod 作为构建环境执行 CI/CD 任务。它将 Jenkins 作为底层执行引擎，用户不需要对 Jenkins 及构建环境作配置和管理。

企业如何构建云原生 CI/CD 管道

企业在构建云原生 CI/CD 管道的时候，除了要做好自动化的前提，梁胜博士认为还有两个方面需要做好。

• CI/CD 平台。不管是用 Jenkins 还是自己搭建，首先必须得有一个 CI/CD 平台；

• 云原生部署平台。CI/CD 平台实际上是把应用部署到云原生部署平台上去的，像 Rancher、Kubernetes 等就是云原生部署平台，它们可以实现一些高级的部署策略。

这两者一旦结合起来了之后，企业就可以利用云原生 CI/CD 提升效率了。

在 CI/CD 管道工具的选型上，梁胜博士认为，现在确实工具很多，但主要还是要看自己的技术能力。如果技术能力比较强，可以花时间了解市面上的各种开源工具，进而直接使用这些开源工具，这是最好的。

但是并不是所有的企业都有这样的能力和人才，所以现在越来越多的公有云或者其他平台厂商也开始支持云原生 CI/CD，用户如果愿意使用厂商提供的工具，也可以方便地实现云原生 CI/CD。但是这其中会面临用户锁定的问题，尤其是云厂商的锁定。

CDF 的成立意味着什么

今年 3 月份，Linux 基金会宣布成立了新的子基金会：持续交付基金会(Continuous Delivery Foundation, CDF)，Rancher 也是 CDF 的创始成员之一。梁胜博士认为，CDF 可以让 CI/CD 的众多平台更加标准化。纵观技术发展历程，是一个从闭源走向开放的过程。早期的很多闭源技术平台存在用户被锁定的问题，不仅昂贵而且不利于创新。后来开源技术流行起来，到了现在仅有开源还不够，很多用户认为开源的技术不应该被一家商业公司控制，而应该交由基金会或者社区管理。现在 CI/CD 正在越来越多地融入技术团队的开发流程中，这个领域也已经有了很多开源工具。有了 CDF，这些开源工具可以更加中立地为技术人所使用，这也是开源的精神所在。

嘉宾简介

梁胜，Rancher Labs 联合创始人及 CEO，是 Java 语言 J2SE 平台核心组件 JNI（Java Native Interface）的作者，领导设计和开发了 Java 语言最为核心的 JVM。2014 年 9 月，梁胜创立 Rancher Labs 并担任 CEO，为全球企业客户提供容器企业级落地的解决方案。截止目前，Rancher Labs 已获得两轮累计超过 2 亿元人民币的融资，在全球拥有超过 20000 家企业用户。

2019 年 6 月 20 日，由 Rancher Labs 举办的 2019 企业容器创新大会（ECIC），将聚焦容器技术的企业级落地经验，邀各行业著名企业的 IT 负责人分享容器项目的成功经验。领取免费门票！