摘要：21世纪如何借助云的力量更加便捷地实现持续集成和持续交付？运维工程师如何正确使用阿里云容器镜像服务提供的持续交付和持续部署功能？本文将带领大家从一个资深运维人员的角度去探讨云时代自动化的CD（持续集成和持续部署）流程如何让运维工程师“失业”。

本次直播视频精彩回顾，戳这里！

演讲嘉宾简介:

谢于宁（花名：予栖），阿里云容器服务团队资深研发工程师，多年互联网摸爬滚打经验，早期从事全栈开发，后专注于 DevOps 工程化。在容器服务团队主要负责推进从研发、测试，到生产的流程自动化。 

以下内容根据演讲嘉宾视频分享以及PPT整理而成。

本次的分享主要围绕以下几个方面进行：

一、 CI/CD（持续集成和持续交付）的发展历程

二、 什么是Docker Image（镜像）？

三、 简易CD流程演示

四、 接下来应该怎么办？

一、 CI/CD（持续集成和持续交付）的发展历程

提到CI/CD，可能会有一些人不甚了解。但提到Docker，相信大部分人听说或者用过。阿里云容器服务在全球超过14个地域提供免费容器集群托管服务，在阿里云的平台上，使用者可以在几分钟甚至几秒钟之内一键搭建出一个集群，然后把自己的应用部署上线。

所谓“借助云的力量来实现持续交付”则是借助阿里云的产品进行持续集成、持续交付、持续部署，即CI/CD。从开发者的角度来看，其开发的代码想要合并到主干分支，需要经过代码分析，例如语法检查，之后甚至还要经过单元测试来检查每一个函数和API返回是否符合开发者的预期，这便是持续集成。将此代码合并到主干分支之后，阿里云提供的服务会将其推送到一个特定的环境中，这个环境可以是测试人员的一个集成测试的环境，也可以是交付到一个客户手中让其自行部署，这边是持续交付。而持续部署则是在持续交付的基础上更进一步，它能够帮助开发者将其开发的软件发布到生产环境当中。

从本质上来看，CI/CD并不是用于帮助开发者移除其开发的代码中出现的Bug，而是用于让开发者在开发流程中更快地发现Bug。传统的CI/CD可以总结为四个字“基本靠吼”，也就是项目管理人员在部署上线时通知开发人员进行统一的分支合并、问题校对和项目发布。

而进阶的CI/CD从某种角度来说还是“基本靠吼”。现在的运维同学们例如阿里的运维已经学会了开发和写代码，能够使用例如Ansible/Chef/Puppet/Shells等这些东西来做一些解放人力的操作。比如在我们团队的日常的工作中使用Ansible来解决一些机器的维护和预置（Provisioning），也会使用阿里巴巴自己的 StarAgent 来完成机器的批量初始化。购买到阿里云的ECS服务器之后，使用者需要在服务器上安装一些配置文件，这些本来需要运维人员人工进行输入的一些很枯燥的Provision操作，现在可以通过使用Ansible来完成，这便是我们所谓的进阶的CI/CD。但即使是这样的CI/CD也并不是我们最想要的，因为这样的CI/CD只能使得运维人员进行更加快捷的部署上线，却并不能实现生产环境无运维。怎么样才能做到生产环境无运维呢？首先我来介绍一下21世纪的CI/CD 的基础——容器。

二、 什么是Docker Image？ 

相信大家都听说过容器，可能部分人只是听说却没有使用过，其实可以把容器类比为虚拟机。在部分开发者看来，容器是一个轻量级的虚拟化环境，进程在其内运行，只是所需要的内存要求更低，其实不然，容器真正关键的点在于它的镜像，也就是接下来要提到的Docker Image。

那么，Docker镜像是什么呢？从本质上来看，它是一系列的存储文件，是软件定义交付。举个例子来说，假设我想通过虚拟机打包一个软件，首先我需要安装操作系统，通常来说系统的规模通常达到GB级别。但是在相同的情况下，如果将其做成Docker镜像，分成两层，一层是操作系统层，另一层是其上的软件，完成相同目的的这两层加起来所需总的占用硬盘空间最多也就几百兆，前后对比相差好几倍甚至几十倍，优劣显而易见。谈到这里，可能有人会问，这个分层的好处是什么呢？分层核心是易于扩展，比如另外一个开发者拿到了上述的镜像，他就可以在原有的基础上做任何修改，而这种修改只需要在原有层面上继续添加层即可。分层的另一个好处是比如当我们交付产品给客户时，同时也把产品运行的环境交付给了客户，而客户所需做的只是运行产品，这就为客户提供了许多便利。

组建Docker Image的过程如下图所示：

其中的“FROM”是使该镜像基于某一个基础镜像的意思，中间的“ADD”和“RUN”则是装载一些依赖包的过程，最后的“ADD”则是将当前目录的“APP”文件夹拷贝到镜像中的“APP”文件夹。然后通过使用“docker bulid”命令就可以创建一个镜像，产生的镜像所需的空间大小却只有30几兆。生成的镜像Docker Image的分层结构正如上图右侧所示，分为四层，最底层是系统层，有一个非常轻量级的系统alphine，在系统层之上安装有Python、Flask两个应用，在这之上则装有一些第三方的库，而最顶层则存储阿里开发的应用代码。当如上所述的镜像交付给客户之后，客户就可以在其系统上添加依赖之后运行我们开发的程序，这便是Docker Image提供的软件定义交付的功能。在此基础上，我们又是如何把Docker Image变成一个进程呢？很简单，只需一句“Docker RUN”然后在“-D”之后加上它的镜像地址。而这个镜像可以托管在共有云的基础服务之上，开发人员在本地将镜像建立好之后可以将其上传到云服务器上，然后再拉取运行即可。

容器内运行的应用实质上并不复杂，它只不过是一个在独立的命名空间中运行的进程，容器服务为其提供了很好的隔离性，每个应用共享系统的内核，这就使它形成了一种非常轻量级且能保证用户之间相互隔离的包装形式。

三、 简易CD流程演示

结束上文的科普，下面就进入正文环节。下面是演示所用的阿里云代码项目：

首先，在Docker File 中定义一个镜像并安装一些依赖，以一个简单的Python的Flask应用作为样例，将其放入镜像之中。之后此应用去链接我们的Redis，此时该应用会渲染一个模板并从Redis之中取出一个值添加到HTML代码中。接下来使用者要做的便是创建一个容器镜像——Docker Image，开发者可以使用阿里云容器镜像服务，这也是阿里云上目前免费提供的服务，它可以做到容器镜像的在线构建。在此之后我们创建一个镜像仓库——CD Demo，镜像服务支持多种代码源，并不需要担心网络问题无法访问，它可以关联在其他平台的代码仓库。当开发者对某个分支的代码作出变更之后，就会通过Webhook机制触发容器镜像的构建。构建容器镜像时，阿里云容器服务会提供一个非常具有特色的功能——海外节点构建，即开发者的Dockerfile如果依赖于一些国外互联网的资源时，可以使用此功能，这样开发者就可以下载到所需要的国外节点资源，然后再将其推送到国内节点。

当开发者创建好了源代码构建的镜像之后，开发者就可以使用阿里云的容器服务来辅助进行部署。使用编排模板创建应用，就可以体验Docker Compose模板。使用阿里云容器服务，开发者点击创建并部署之后只需等待几秒钟就可以把应用部署完毕。回顾下刚刚发生的场景，当开发者对代码进行修改之后，自动触发了镜像的构建，之后则是容器服务中的应用更新，这就完成了一整个CD的流程。

流程演示到这里，是否有人发现整个流程中少了一些内容呢？是的，开发者还会需要一些反馈的内容来时刻监督开发的进度。那么这个反馈内容在哪里呢？阿里云提供了一个名为Code Pipeline的产品，该产品有点类似于Jenkins，它是阿里云上公测的一个服务，该服务在Jenkins的基础上做了非常多的改进，它打通了阿里云多种产品，并且在部署失败的时候能够及时给开发者信息反馈，以便于开发者进行修改，这种反馈支持邮件和钉钉等多种通知方式，为开发者提供了诸多便利。

四、接下来怎么办？ 

最关键的是传统测试转型自动化测试。如果整个CD流程依赖过多人工介入的话，那就需要比较多的人力来完成，这对于创业公司来说是一笔非常高的成本开销。 如果一个Bug到了发布上线之后才发现的话会造成很大的损失，但是如果开发人员能够在本地测试环境中发现问题，那么这个Bug所造成的损失就可以降到最低。所以我们应该培养出整个团队规范化合并的代码的习惯，哪怕一个功能上线也要保证单元测试覆盖。