多云 devops 实践

毕宏飞

作者简介

邱见
IBM,现任资深架构师

前言

我来自于IBM，我们的工作是在多云环境下做一些 Kubernetes ，然后在 Kubernetes 之上做 DevOps 一些的东西。今天我的分享主要有以下四个部分：

1、什么是多云?
2、多云环境下的IBM Cloud Private
3、我们遇到的挑战
4、ICP devops 实践

一、什么是多云?

首先是什么是多云，以前我们经常去谈混合云，混合云其实就是说你有自己的一个私有云，在公有云上有一些服务，在之间做一些DR切换，把一些服务托管到公有云上面。

从现在实际情况来看，越来越多的公司使用多个不同的公有云，他们也会有自己的私有云。IBM做过调查，我们的客户有80%的准备使用多个公有云，有70%实际上正在使用三个或者三个以上的公有云服务，他们可能来自于aws、阿里，腾讯各种各样的公有云服务。

为什么使用多云环境呢？有几个很重要的考虑因素，比如说：

• 把应用部署在最适合的公有云平台上
• 避免传统应用改造的痛点来适应新的平台
• 避免被公有云厂商绑定

IBM自己也使用，可以说是公有云的提供商也是多云的消费者。IBM有很多的服务也跑在aws或者跑在其他云平台上，IBM自己也在使用多云，也是为了使用更好的这种公有云上的服务。

二、多云环境下的IBM Cloud Private

在之前很长的时间，多云这件事情在 DevOps 上面很难做，对于公有云以前提供 IAAS 服务，他们的API不是统一的，用不同的公有云服务，你要使用不同的API。但是由于 Container 还有 Kubernetes 的出现，我能有一套统一的API去使用公有云。从 Kubernetes 或者从 docker 角度来讲，其实不太关心你后面的是什么，可以是任何的公有云服务，但是你可以从部署在 Kubernetes 的角度来做这个事情。对于我们团队来说我们是做多云上面的 Kubernetes 平台，这个平台上面会有一些运维服务，又有一些IBM自己的其他应用服务，这些服务包含数据分析、AI、还有一些其他的长期运行的服务。我们团队主要做运维服务和 Kubernetes 这两层的开发跟运维工作。这个平台会在IBM内部运行，也会在其他的公有云平台上运行，也会根据用户使用，决定运行在其他的公有云或者是用户自己的内部环境。

那么在这个平台的开发中，我们使用了挺多的 DevOps 工具，这些工具大多数都是 SAAS ，比如说 Github Enterprise 、 Artifactory 、Slack 这些东西。这些 SAAS 服务之间其实已经做了很多的整合，所以你可以很好地去做一个 CI/CD 的 Pipeline 把他们整合在一起。

三、我们遇到的挑战

我来说说在这个过程当中，遇到什么挑战？最开始开发这个平台，我们主要负责的是以 kubernetes 上面的一些运维服务为主的一些开发。

一开始的时候，我们想法非常简单，我提一个PR，这个PR去做 unittest ，完了以后提交到 master 上面，之后你就会有一个 latest image ，其他人就可以使用这个镜像去部署这个东西。

这里有三个问题：

组件众多，开发团队众多

多云环境下平台测试异常复杂耗时

对这个平台上来说，既是消费者，又是生产者。

• 第一个组件众多的问题，随着平台的发展，不止是 Kubernetes 本身，还包含上面的一些服务。比如说我们有自己 UI service 、监控的 service ，有非常多的 service ，而每一个 service 都有不同的小组，每个小组之间的开发计划、开发进度又不是完全一致。所以你想说我有一个大的去覆盖所有事情是不太可能的。我们每一个组件，它其实都是有几部分组成的，我们把它抽象成都是 pod 、images 、Kubernetes 的 helm chart 。部署的方法就是 helm chart 去部署一堆的镜像。由于开发进度不一样，组件之间有互相的依赖，比如说api的依赖，就会导致一个新的镜像构建出来之后，其他的镜像没有办法被使用。
  

• 第二个测试复杂耗时的问题。我们这个平台需要在多云环境下进行测试，由于IBM自己，不光只要支持X86，还要支持自己内部的 Power 和 Z 这种架构。实际上这个平台每次需要去做很多的测试，在每一个平台，不同的云环境，不同的CPU架构上做测试。那我们什么时候做这个测试？在之前这种 DevOps Pipeline ，我们提交一个PR，所有的测试都会做一编，到提交到 master 的时候再做一遍，然后构建出 latest images，这里面会有一个问题，这个时间非常长，很容易出错，出错了以后，直接导致 code 没有办法进行，影响整个开发。你需要在各种环境里面做测试，就会导致多个团队同时开发，PR不断rebase不断测试。
  

• 第三个问题我们既是消费者，又是生产者，对这个平台来说，使用很多开源软件，实际上我们要在开源软件上做一些修改，对于 Kubernetes 来说，我们自己内部也要做一些改进，加一些业务进去，这部分必须涵盖在 DevOps Pipeline 里。它又是一个生产者，它生产出这个平台，IBM其他的数据服务，数据分析要使用这个平台。所以这里就有一个问题，我生产出这个平台以后怎么保证它的版本，因为别人也要不断地去做开发，我们要保证生成出来的平台一定是稳定的平台。
  

四、ICP devops 实践

我们看一下我们后面的一个改进。我们后来发现，其实没有办法完全按照开源的方法去做，因为组件实在是太多了。最终的决定就是把整个 CI/CD Pipeline 拉长，于是我们就重新做了一个 DevOps 的架构，这个架构首先有 SAAS 的部分，比如说 Github Enterprise 、Slack ，还有我们使用了 Artifactory ，主要去做 images 的存储。

对于 IAAS 层来讲，有不同的 IAAS 平台，有 CI/CD 去拆发一些专门的脚本，他们有自己 ICP system environment 的去做整个系统监控，报告安全的问题，因为我们每一个 docker 镜像构建出来，都要去扫描它的安全问题，他们也会构建一些 Terraform 、 ansible 的脚本去做这些部署。每一个自己的 Squad 也要负责一部分，负责自己 images 的构建还要负责自己的 helm chart，这样就把责任分得比较清楚，对于本身的 component 的部署和 images 是由某一个特定的 squad ，就是谁开发谁的负责这部分东西。对于 CI/CD 的 squad 主要做一些基础环境，比如使用 Terraform 调不同的公有云，把基础环境做起来。

在这之后我们有了一个延长以后的 Pipeline ，这个 Pipeline 分了左右两部分，左边是持续的部分，右边是 scheduled 好的。

左边的部分只需要开发者去关心的，像以前我们有一个 scratch 、 integration 这两个不同images 的 repository，一个PR被 build 以后，它首先去做一些 unittest ，然后会进到 scratch bulid 里，这个其实可以去定制，别人就可以把 scratch 里的东西拿出来测试。接下来如果被提交到 master 以后，它会进入到 master build，在这之后就是 CI/CD 团队去做，会产生不同版本的 build 为不同的目的服务。

首先看到是的 scratch build，那么scratch build 就是说我PR提交了以后我就有一个scratch build，这些可以用来做一些 unittest。之后如果这个PR提交到 master以后，会产生 integration 的 build，其实它就是一个不同的 image 。对于开发者来说，他只对这两个 build 有权限。

在这之后就成了 CI/CD 团队做的事情，他们需要做 daily build ，daily build 是说每日从 integration 拿一个 daily 的 image 出来。

我们预期他们是会失败的，当然这里头有很多的原因，比如集成的问题，比如说API兼容性的问题。这个 daily build 会要执行跨平台，跨云，跨操作系统的测试，以前对跨云、跨操作系统的测试，不再放在一个开发者的 PR build 里，而是放在 daily build 里 ，这个时候把这些事情跟开发者分开来了，相对来说可以更快速的开发，把这些事交给 CI/CD 团队去做，他们会发现其中的一些的BUG并且反馈回来，然后再反馈到开发团队。

Development stage 、Stable stage 、Release stage 这几个是对于外部来说是比较稳定的一些 build ，这些可以被其他人使用。他们也有不同的状态，比如说 Development build 可能它的api变化还是相对会大一些，Stable 会保证api相互的兼容性，他们 build 的周期也不太一样。从 Development build 开始可以提供给其他的一些服务去使用，到 Stable build 以后会部署到多云的预生产的环境里面，在这之上让其他的应用去使用。

另外一些问题，生产者和消费者怎么解决？实际我们是很多开源软件的消费者，包括 Kubernetes 、 docker ，还有很多其他的一些开源的组件。另一方面，我们又需要去修改它的一些东西，来保证它可以满足我们的要求。

比如 Kubernetes 这种 build 我们也会跟随一样的流程，也会到 scratch 、 integration 再通过做一系列的测试变成一个 stable ，也是通过 Pipeline 这种方式去 build 其他的开源组件。

其次是生产者的做法。像我刚才讲的，我们会有三个不同的 build ，根据 build 稳定性分成不同的阶段，从 development 到 release 。 Content Team 这里指的就是使用它，他们有一些服务要跑在这个平台上面，他们就可以从 Development build 试用它，如果觉得可以就把服务迁移到 Stable build里。

接下来，一个问题是多云。实际上刚才讲的是 DevOps Pipeline，走到 Stable 的时候，实际上就是多云环境，在这种情况下，我们怎么样去管理多云，如何做一些不同云环境下的应用配置。比如说我有一个运维服务，它实际上由 helm chart 和 docker images 组成的。你需要部署到多个云环境中，虽然说 Kubernetes 可以很大程度上保证你的东西不管放在哪里都可以部署，但是有一定的区别，需要有一些区别的配置，那么就需要在多云环境的配置管理，需要做一些多云环境上系统的监控、合规等等这些东西。

这个时候我们就开发了一个系统叫 Multi-cloud Manager ，它管理多个不同的云环境 Kubernetes 集群，可以通过它做更好的监控、应用的迁移、不同应用配置下的部署。

在做多云 DevOps 的是怎么做的。我们会有多个不同的 Kubernetes Cluster ，包括 Integration cluster 、 Daily cluster 、 Stable cluster 。

Stable cluster 可能会部署在多个不同公有云或者私有云环境中，这些东西都被 MCM 去管理起来，比如说我去测试某一个应用的时候，可以通过 MCM 把这个应用发布到某一个集群里面，通过 MCM 把这个应用从一个集群发布到另外一个集群。