迁移到 Docker：濒临失控的混乱

作为一家提供对多云平台统一访问接口的公司，RightScale 帮助客户管理云计算提供商的 IT 流程。随着 Docker 的流行，该公司也开始关注这一概念。而且随着对 Docker 的了解，RightScale 公司发现了该容器的好处，并准备将软件开发和部署过程迁移到 Docker 中。Tim Miller 是 RightScale 公司的副总工程师，领导着公司的产品开发与部署工作。在 Tim Miller 的上一篇博客文章中，他讲述了 RightScale 决定要迁移到 Docker 的原因。之后，Tim Miller 又发表了 Project Sherpa 项目和我们为什么迁移到 Docker 的系列文章的第二篇，讲述了 Sherpa 项目的相关情况。最近，Tim Miller 又发表了该系列文章的第三篇，讲述了 Sherpa 项目启动一周后的进展。

第二篇文章发布后，Slack 相关的问题、回答和讨论给了 Sherpa 团队更多的信心和灵感。他们在上一周遇到的最大问题就是，随着解决问题的想法不断涌现，标准和约定变化太快。他们不得不抽时间来保证每个人处于同步的状态，从而保证对等的信息交换和标准不互相冲突。其实，在项目开始之前，他们已经在“Docker 圣经”中专门编写了开发和运维之间的接口合约。以下就是有关 Docker ENTRYPOINT 的一个例子：

• Docker 镜像必须要有一个运行脚本的 ENTRYPOINT；脚本要能够针对两种类型的 bootstrap 请求做出响应：one-word 请求（只有 bootstrap 和 exit）和 two-word 请求（bootstrap 和进入服务）。
• 应用必须要在启动时进行完整性检查，以确保它已经被 bootstrap。也就是说，其数据库语法存在，而且所有的迁移已经在运行。而如果它没有被 bootstrap，应用应该直接崩溃。
• 即使是在 exit 0 的时候，应用也必须要将 bootstrap 命令字暴露出来。
• 如果应用执行数据库迁移，它应该将运行迁移并 exit 0 的命令字暴露出来。
• 如果应用运行某种 HTTP 服务器，它应该暴露 web 命令字。
• 如果与运维合作，应用应该暴露出其他的命令字。例如，对于在集群和 shard 中行为不同的应用而言，web-master 和 web-shard 就很常见了。
• 除了 bootstrap，每个镜像必须支持的命令字没有额外的要求。

随着 Sherpa 团队越来越多的成员开始使用 Docker，他们的标准在第一周变化的非常快。其中一个变化就是处理 Docker entrypoint 和命令的更简单的新方法。由于他们准备容器化的很多服务都是在微服务出现之间构建的，他们必须要完成更多工作；一个给定的 SCM 库将包含一个 REST API 以及后台进行脚本处理的实例。因此，其镜像拥有不止一个“特性”。当他们从中运行容器时，就需要指定“特性”。

为了减轻运行正确“特性”/ 命令的复杂度和保证应用的数据是兼容的，他们在不同库之间共享了一些样例性的 shell 脚本，然后复制 / 粘贴。而其中一名工程师发明了一种更简单的方法——将一个可重用脚本放入运维团队的基本镜像中，并允许单独的应用拥有一个描述可用命令的配置小文件。

在第二周，有关输入和部署细节的标准变化将开始慢慢变少。而他们一旦开始研究监控和警告，Sherpa 团队肯定会遇到新一波的混乱。而 RightScale 的工程师也非常喜欢作为一个团队来完成 Docker 迁移。正如他们所言：

“所有人都在做同样的一件事情实在是非常有趣。遇到的问题可以从各个方面得到解决方案，而这些解决方案又可以应用到多个团队的多个容器化项目中。”

而且，他们也取得了非常大的进展——三个服务已经完全容器化，而团队未来也能够保持这样的速度。他们还从中获得了其他好处：

“因为服务被容器化了，其运行速度是以前的三倍，消耗的内存却只有之前的一半。”

接下来，他们就要开始向第二周进发啦！

想了解更多 Tim Miller 团队如何使用 Docker 的内容，可以观看其在线研讨会。它包括了：

• 安全产生高质量、易于管理的 Docker 镜像的建议
• 在笔记本和云之间多宿主机互联的建议
• 在产品中编排 Docker：服务发现、配置以及可审核性
• Docker 带来的宿主机密度的增加
• 用于 Docker 容器的动态监控和警告

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。