迟到的精彩笔记：Docker 对传统 DevOps工具链的冲击

本文经作者陈正玮同意转载，原文网址为http://blog.chengweichen.com/2016/01/ithome-container-summit-2015-docker.html

延续去年的盛况，今年 iThome 再次举办了 Container Summit。当举办的消息刚释出时，本来是没有太多兴趣的，是一直等到议程公布，发现有邀请了数位国外讲师，包含 Mesos、Rancher 及 DaoCloud⋯⋯等，才改变心意，立马向公司申请公差决定要来好好朝圣一番。

这次的议程我觉得可以分成三种类型，分别是“大师推坑”、“观念分享”及“就是来卖产品”。因此并非每一场都需要做详细的笔记，有些场次只有几个重点需要记录，剩下的时间都是在欣赏讲者的推坑功力，看看能不能顺利让听众们买单。

这次“小城故事不多-科技部”以团体战术在第一时间就释出了各场重点笔记，有兴趣者可以直接参阅他们的两篇笔记文，内含每一场的重点笔记。

• http://smalltowntechblog.com/2015/12/10/ithome-container-summit-day-1/
• http://smalltowntechblog.com/2015/12/11/ithome-container-summit-day-2/

在这一次的 Container Summit 2015，iThome 依然邀请了叶秉哲（以下简称：叶大）为大家分享议程，这次叶大同样带来一场属于“观念分享”的题目“拥抱或对抗？谈 Docker 对传统 DevOps 工具链的冲击”。

简报已释出，可直接线上浏览

开场叶大先用几则笑话调侃了一下 DevOps 的现况，基本上就是 DevOps 的定义问题、DevOps 涵括太多的领域及 DevOps 的工具种类与数量多而繁杂。

有鉴于 DevOps 目前的现况，因此若想要在一场分享中介绍这么多 DevOps 相关的内容是不可能的，必须换个角度思考，只能针对有限的关键问题分享。

那么到底在实际面上 DevOps  切身相关的问题是什么？

于是叶大借用了 Brian Brazil 在文章中提出的三个严肃的问题来回答。这三个问题分别是：

• How to recreate your system（如何重建你的系统 ）
• How to safely change your system（如何安全地改变你的系统）
• When something has gone wrong（你有办法知道系统出状况并解决它）

相信 Ops 一定会立刻认同这三个问题的重要性，因为不论是重新打造或修复重建系统，系统建立是 Ops 最基本的关键工作。

而系统建立之后，还会遇到需求变更或软件升级⋯⋯等原因导致系统必须被改变。最后即便放了绿色乖乖也不代表系统永远不会出问题，因此系统监测绝对是第三项不可缺少的关键项目。

可以说对 Ops 而言若想要提供一个稳定的系统，这三项是绝对逃不了的关键问题。所以在谈更多 DevOps 的内容之前，不如先好好的讨论这三个问题。

接着叶大就一一的针对这三项问题以“传统作法 vs Docker 作法”的方式一一介绍 Docker 所带来的冲击，并分别从“机器”、“组态”与“角色”三个项目切入。

但在进入正题之前，叶大立刻就说今天只会谈到前两个问题。因为在 Docker 如此火红的时代，还没有任何一间 Monitoring 相关厂商胆敢不支援 Docker。不论是新兴厂商或老牌厂商，多多少少都已经支援 Docker  ( 或 Container) 的 Monitoring，差别只在于能做到多细致，所以第三项问题直接 PASS，整场分享只会聚焦在前两个问题。

首先是“How to recreate your system”，从“机器”开始谈起。

传统作法基本上就是先有一台资源超强的实体机，为了善用它的所有资源，于是实体机上再透过虚拟化技术建立出多个 VM。但 VM 的缺点就是会有资源消耗的问题，毕竟它不是直接取用实体机的资源，中间必须透过 hypervisor 这一层。于是假如应用程序是各自放在不同的 VM 之中，那么每个 VM 皆会各自在 hypervisor 上有资源消耗。

那 Docker 作法呢？基本上 Container 的出现有一部分原因就是为了解决 VM 在 hypervisor 的资源消耗。将每个应用程序独立放在各自的 Container 中，所有的 Container  共享一个 hypervisor，如此即能节省这部分的资源。而目前很多应用程序也都已经被 dockerized，方便使用者可以快速建立并使用。

若由此进一步思考 OS 的重要性，会赫然发现 OS 似乎只剩下用来运行 Docker ( 或 Container) 的价值。所以 Container OS 这种新玩意也就此诞生，Container OS 即是专门用来在其上运行 Container 的操作系统，如目前有名的 Core OS、Rancher OS⋯⋯等。

另外，VM 并没有因为 Container 的出现就被彻底舍弃。如果你非常看重“硬件资源”的隔离，那么 VM 依然是一个好选择。在追求“资源隔离”的前提之下，又延伸出另一派的新思维“Container per VM”，例如 Hyper。

顺道提一下 Hyper，之前就有注意到这个有趣的专案，就如它网页的介绍 “Make VM run like Container. Fast as Container, Isolated by VM.”，它尝试保有 VM 与 Container 两者的优异之处，也许这是另一条不错的路线，可以继续观察它后续的发展。

在 OS 层面最后一个影响就是“Unikernel”，个人是前一阵子才在 Docker 相关的资讯中看到这个词，这次能听到叶大的解说，刚好解答了一些疑惑。

它的重点即是将能拔除的东西全部拔除，连 OS 都嫌太大太多，连 OS 都想拔除。在此思维之下，将环境精简到只有特定应用程序所需的 “minimal set” 形成所谓的 “library OS” 的概念。

那为何要这么做呢？我觉得可以先看看叶大在 jcconf 2015 的分享“Immutable infrastructure：观念与实作 (建议)”及 Boxfuse 的介绍 “Why Immutable Infrastructure ?”，应该能提供一些观念上的补充。

上面讲了这么多，到底该如何选用哪一条路线？叶大的建议可以参考简报 P. 30，根据 service consolidation 与 resource isolation 相互的重要性来评估。

接着谈到“组态”。

不同的应用程序在环境设定上会有各种不同的组态，如果是传统的 DevOps 做法，第一个想法应该就是利用 Configuration management tools 来解决它。不过在使用如 Chef、Puppet 或 Ansible 这些工具之前，先决条件是你必须先具备足够的环境建置、部署及维运能力，同时还要学会这些工具自己的脚本语法、使用情境、操作逻辑⋯⋯，才能有效地运用它。

不过即便有了 Configuration management tools 的辅助，但“组态设定”这件事本身的“复杂度”依然并未减轻多少。

而 Docker 呢？我们可以先回想一下 Docker 官网上重要的三个字 “Build, Ship, Run” 。透过 Dockerfile 与 Docker image 的 Layer 特性，Docker 这个工具可以让你分层管理、重复利用、快速迁移与部署。

因此你可以将复杂的系统环境或组态切分为数层 Layer 方便管理。build 的 Image 还能存放于自己的 Docker Registry 重复利用，或者也能直接上 DockerHub 寻找优质可用的 Image。只要透过妥善的设计与规划，不论是在 dev、stg 或 production 的各种复杂环境也能透过简单的 “Docker pull、Docker run” 再现。

这样看起来 Configuration management tools 似乎变得不再重要？就如叶大简报 P. 40 的重点，Configuration management tools 未来将可能只被用来安装 Docker 及初始化设定。简报 P. 40 中附注的文章《Containers Vs. Config Management》个人建议也值得一读。

最后谈到“角色”。

这里叶大要讲的是 “Pets or Cattle” 的观念。因为这观念已不是第一次听见，所以就没有记录太多细节，如果用 “Pets or Cattle”、 “Pets vs Cattle” 之类的关键字去 Google 即可找到许多优质文章与简报。

叶大也在这段分享中再次提到 12 Factors App，呼应 Docker 在运用上与 Cattle 的观念及 12 Factors App 有多么吻合。个人的想法是这一切都与“架构”有关，不管是系统架构、应用程序的软件架构。假设你期望系统能做到弹性扩展，但你的架构却缺乏弹性、可移动性，应用程序的资源被高度绑死在一台又一台的 Pets，那怎么有办法弹性？

How to safely change your system ?

叶大这场分享主要都是花在观念说明。因为只要了解这些观念就不难理解第二个问题“How to safely change your system”在传统作法与 Docker 作法的差异。

如何安全地改变系统，在传统作法即是会采用一些如 Rolling upgrade、Blue / Green deployment、Canary deployment 的方法来尝试安全的更新软件或改变系统，同时你必须要自己事先注意好所有的细节，避免在系统改变中出错。

那么 Docker 作法呢？则延续前面介绍的 “Pets or Cattle” 的观念，如果你的机器是以 Cattle 的方式管理并且应用程序的架构吻合 12 Factors App，更将应用程序封装为 Docker image，那么传统作法中的某些繁杂细节你就不需担心了。

例如 Google 的 Kubernates 要做出 Rolling upgrade 即非常容易，只要一行指令即可。很多麻烦的细节 Kubernates 会帮助你处理。至于其他如 Mesos 与 Docker 官方更不用说，也都在这方面有工具可以辅助。

所以说重点依旧是 “Pets or Cattle” 的观念，若想要获得 Docker 作法带来的优点，还是先好好的检查一下你的“架构”吧！

叶大的分享就到此，结束前会再有一次总结，即是简报 P. 71~75，基本上看简报就知内容重点，所以就不再复述了。