Docker学习总结（14）——从代码到上线， 云端Docker化持续交付实践

2016云栖大会·北京峰会于8月9号在国家会议中心拉开帷幕，在云栖社区开发者技术专场中，来自阿里云技术专家罗晶（瑶靖）为在场的听众带来《从代码到上线，云端Docker化持续交付实践》精彩分享。

关于分享者：

罗晶，花名瑶靖。在加入阿里云之前，先后在支付宝平台数据技术事业群、百度基础架构部任职。现主要负责阿里云容器服务产品的集群管理系统的研发，从事容器的持续交付、持续集成的方案设计与实现。

演讲内容架构

• 大话持续交付

• 持续交付的前世

• 容器化DevOps

• 持续交付的今生

演讲主要内容

持续集成指的是，频繁地（一天多次）将代码集成到主干。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续集成和持续交付保证了软件的持续运行和有效反馈。

不同环境，不同交付运维方式。即便按照流程去做持续交付，系统地搭建出来整个持续集成的系统环境，一样会遇到七七八八这样的问题。就算是同一种语言，每一个开发者所依赖语言环境、依赖的包不一样，就会导致有非常多的编译环境，维护起来就很困难。

传统持续交付问题的根源在于：

• 开发者交付的只有代码以及代码的依赖；

• 运维者需要除了代码之外的运行环境，以及运行环境之间的依赖。

交付方式的变革

Docker的出现改变软件交付的方式。经济学家说过：没有集装箱，不可能有全球化。Docker就像把一堆零散的代码和我要的所有东西装在集装箱里，真正去交付给运维时，相当于把这个集装箱运行起来。它包含所有的环境依赖，所以在任何地方运行集装箱所达到的结果都是一样的。因为达到了环境一致性。

Docker之所以这么火，是由于它的敏捷、可移植、可控的特性决定的。敏捷意味着Docker可以秒级应用启动、轻量级隔离、细粒度资源控制、低性能损耗；可移植代表着Docker的环境无关的交付、部署方式、可用于软件生命周期中不同运行环境；可控表示容器级别的资源隔离和流控。

Docker Compose是Docker推出来的一个对多容器的编排技术，简单好用，便于开发。使用Docker Compose，可以一键构建本地开发环境，在团队中可以共享一份配置文件。它的优点是：

• 简单好用，便于开发

• 本地环境沙箱

• UT环境

• 编排容器、存储和网络

当然，它也存在不足：面向开发和部署，不支持自动化运维。

Docker Swarm把一组Docker引擎抽象成一个Docker引擎，以前所有在单机上对一个Docker引擎的工作，都可以透明的变成对一组Docker集群上的节点的操作。Docker Swarm它的优点是：

• 支持标准的 Docker API；

• 灵活、可扩展、可插拔的容器调度。

当然，它也存在不足：面向容器、缺少服务生命周期支持。

容器服务上有三个层面的概念：

• 资源层面——集群，节点。

• 内容层面——Compose模板，镜像。

• 应用层面——应用，服务，容器。

容器化DevOps，可以实现：

• 开发环境到生产环境的一致

• 可编程基础设施

• Infrastructure as Code

• 不可变基础架构

• Immutable infrastructure

• 全流程工具化、自动化、持续交付

• 降低试错成本，鼓励快速迭代

简单的容器化持续交付流程如下图所示：

复杂的容器化持续交付流程：开发人员在除了代码 、Config、Test脚本还要写Dockerfile。把这些代码传（Push）到代码仓库，有一个CI service通过代码仓库hook告诉你代码仓库有一个新的提交。把代码拉下来复制，进行两件事情 : Build和UT。在build的过程中，会从Docker
Registry上面去拉下来( Pull )依赖的image，当build通过了之后会push image到这个Docker Registry单位里面去。然后CI 会有一个hook去通知CD，deploy Service根据Docker和image描述以及compose描述，把image部署到预发、测试或者生产环境。

持续交付“最后一公里”

发布时持续交付的“最后一公里”，常见的发布策略有蓝绿发布、金丝雀发布（灰度发布）、ABTest，在国内的开发者中，对这几个概念有独立的理解。

Rolling Update

• 依次停止老容器，启动新容器

• 整个过程自动化，无需用户手动操作

• 适合于多副本的应用发布

蓝绿发布（热部署）

• 不会停止老容器，为新服务启动新容器

• 需要用户设置路由权重，实现不同版本应用的上线、下线

• 适合于版本的快速发布，不会停机影响用户

金丝雀发布（灰度）

• 不会停止老容器，为新服务启动新容器

• 需要用户设置路由权重，实现不同版本应用的共存

• 支持A/B测试，适合多方案选择

•