Docker与实现DevOps的三种方式之系统思维

《ThePhoenixProject》是一本融合了IT专业知识的纪实小说，既有商业实战模式的真实案例，同时将IT运维的的四种工作类型和DevOps的三种方式融入其中。Docker如何在这三种方式中发挥作用？...



编者按：相信很多人都读过Gene Kim的《The Phoenix Project》，这是一本融合了IT专业知识的纪实小说，讲述了PU公司通过IT项目与公司业务结合继而将公司起死回生的故事，既有商业实战模式的真实企业案例，同时将IT运维的解决之道融入其中。三位作者Gene Kim 、KevinBehr和George Spafford，结合多年的IT相关经验，站在一个管理者的角度讲述了IT运维的四种工作类型和DevOps的三种方式（Three Ways of DevOps）。

1. 遵循『第一种方式（The First Way）』意味着思考系统的端到端流程，例如，考虑一次软件变更需要经历的所有步骤，从客户的初始需求一直到生产环境部署。正如Gene Kim等人在“凤凰项目”中所说的那样，这有助于避免局部最优和消除工作孤岛；
2. 『第二方法（The Second Way）』增加了反馈回路，问题因此可以得到快速识别和纠正。一个典型的例子是使应用程序的生产日志可以随时提供给开发团队；
3. 『第三方法（The Third Way）』意在培养一种不断实验以及通过反复实践达到精通的文化。Netflix的ChaosMonkey服务可以看作第三方法在实践中的一个极端示例。

Docker如何在这三种方式中发挥作用呢？以下为译文：

这种方式将系统作为整体的价值流来理解，管理这个流的目的是达到全局最优或减小瓶颈。DevOps的行话一般叫『A-Ha to the Cha-Ching』的时间，书面语中叫『lead time』。我更喜欢将这个过程形容为商品从生产到消费的过程。为了达到第一种的效果，要在不减慢全局工作流的同时，提高本地进程的速度。需要遵循三个主要原则：第一，提高流程中每个过程组件的速度；第二，减少每个子进程的资源和时间浪费；第三，通过功能隔离，进一步优化进程，从而能更好地可视化和理解全局的流程。

Docker和这种方式有什么关系呢？以下从速率（Velocity），差异性（Variation）和虚拟化（Visualization）三个角度展开：>>>>[/b]

开发流程（Developer Flow）

大多数使用Docker的开发人员，在个人电脑上搭一个多容器的测试环境。他们用Vagrant或Boot2Docker运行一个本地的虚拟实例，作为Docker主机。在这个环境中，就可以测试这个由多个容器组成的服务栈了。

>>>>[/b]

集成流程（Integration Flow）

通过Docker化的build机制，可以将持续集成的工作流程化。 一个CI系统可以设计为多个虚拟实例，每个实例都是独立的Docker主机（比如build slave），还有些build环境采用Docker-in-Docker的方式。这样将build环境和测试环境做了清晰的隔离。这种情况下，最初的虚拟实例一直在运行着，因为嵌入的Docker主机可以被CI slave实例重建。内部的Docker主机只是一个Docker镜像，可以像其它Docker实例一样被实例化。

就像开发者的个人电脑一样，集成服务可以作为Docker容器运行在这些build slave中。不但测试服务的效率获得了指数级增长，还能让测试场景更多样化，基于同一模板的测试可以在几秒内被重复创建。可能需要几天完成的集成测试可以在几分钟内完成。

Docker加速CI流程的另一种方式在于其Union FileSystem和Copy on Write（COW）机制。Docker镜像通过层级文件系统创建，只有最上层是可写的。比如MySQL容器在某次测试停止后，镜像还是原始的状态，可以创建新一轮的测试，这大大提高了在整个流程中创建环境的速度。

>>>>[/b]

部署流程（Deployment Flow）

蓝绿部署是一个流行的CD（Continuous Delivery）流程，常用来向生产环境无缝地迁移应用。生产环境部署的挑战在于保障无缝和实时的更新（从一个版本到另一个）。蓝绿部署的过程是这样的：集群中的一个节点（绿节点）更新到版本，其它节点不更新（蓝节点），先测试绿节点。蓝绿部署的关键在于两点：1)更新所有节点花费的时间要尽可能少；2)如果集群需要回滚，也要尽可能的快。

Docker容器可以让更新和回滚更高效。另外，由于应用被隔离了，每次更新涉及的变化组件更少，这个过程也更清晰。Docker对于像dark launch和canarying等其它部署方式带来的优势也类似。Docker image在软件交付过程中发挥的作用之一，在于基础设施和应用都可以被封装到Docker镜像中。Java的口号是『write once run anywhere』，但由于Java的产物只被包含了应用，对于Java runtime和特定的运维环境有很多依赖。

但对于Docker来说，开发人员用Docker镜像来打包真实的基础设施（比如基础OS，中间件，runtime和应用）。这种收敛的隔离，降低了交付流程（开发，集成和生产部署）中多个环境间潜在的差异。如果开发者能在笔记本上测试一组Docker镜像，那么这些服务同样能在集成测试和生产部署中运行起来。

将Docker作为基本的部署机制的话，镜像是二进制的，整个流程中的所有环境并没有太大的差异性。与传统方式中，每个阶段都要另外搭建一套环境形成鲜明对比。

在2014年旧金山举办的DockerCon上，Gilt Group讲述了他们如何利用Docker作为其基本的部署机制。Gilt以不可变基础设施的方式，利用了微服务架构，换句话说，他们生产环境中的基础设施是不能更新的，只能被替换。如果你看过他们CTO Michael Bryzek 的演讲视频，就会知道他们整个流程看起来也是不可变的，我给它杜撰了个名字『Immutable Delivery』。

Gilt在采用Docker部署之前，部署流程中是1000多条发布脚本，管理着1000多个软件库和25种部署模式。这种旧的方式为整个流程带来很多差异性，脚本的查找和所有权问题经常为流程带来瓶颈。在微服务架构中，服务被定义为有边界的环境。当这些服务被封装为Docker容器，并作为交付流程的一部分，马上就成为真实世界可见域。从DevOps运维的角度来看，MTTR (Mean time to Repair/Restore)是系统成功的关键要素。当这些服务被封装为Docker容器，并作为交付流程的一部分，马上就变得可见了。服务的可见性能够帮助组织更快地隔离，发现和确认所有权，从而提高整体的MTTR。

本文聚焦于Docker和通向DevOps的第一种方式，从效率，差异性和虚拟化三个角度展开讨论。本质上说明了，流程的Docker化可以在减少软件交付的成本和风险的同事，提高更新的频率，下一篇文章会继续讨论Docker和通向DevOps的第二种方式和第三种方式。

原文链接：https://blog.docker.com/2015/05/docker-three-ways-devops/

5月21日，灵雀云『释放云的无限潜能之微服务』为你带来微服务干货！时间：5月21日 14:00-17:00

地点：北京市朝阳区望京街10号 望京SOHO T3 A座 5层3Q点击【阅读原文】报名参会！

    关注 灵雀云