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测试，适合多方案选择
