迁移到 Docker：艰难的最后一半路程

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

在之前的几篇文章中，Tim Miller 一直试图以周为单位来记录Sherpa 项目的进展和相关情况。然而，项目启动后的第三、第四和第五周已经很难严格区分了——工程师们都在连夜赶工来完成迁移工作。

对于一项新的技术，工程师们总是会抱着极大的兴趣和热情，非常愿意在项目中进行尝试。因此，Sherpa 项目团队确立了将所有需要完成的迁移工作进行纵向划分的计划——每个小团队分别负责不同的服务。这也是他们所知道的保持团队成员高效工作的唯一方法。在计划确定一周后，每一个小团队都进行了热情高涨的状态——成员积极学习相关内容，喜欢正在做的事并积极对核心模板和部署方法的巨大改变进行宣传。这些行为经常与其他团队的想法是完全相反的。这使得Sherpa 项目的运维团队负责人Mark Dotson 非常不开心。他更喜欢T.G.I Friday 餐厅那种放松的感觉。因此，他的观点是：“想法非常好！在我们做完这个之后，可以讨论实现你的伟大想法。但是现在，还是让我先使用这个不是很好、但经过测试的方法”。

对于每一项服务，其迁移过程的第一个里程碑就是“传统部署”对象的Docker 化的1:1 替代版本部署到了集成环境中。在这之后，Mark 会接手，为模拟和生产环节做准备，并保证所有的服务都能够一起工作。为了让项目架构更加清晰，Sherpa 团队将服务依据Docker 化所需要的时间和服务是否会被逻辑部署在一起划分为了三个组。首先，他们确定了第一组应用各自进入模拟环节的目标日期。然后，再依次确定了第二组和第三组的时间。

随着每一组服务依次到达截止时间，这种划分一直没有问题。然而，他们很快便遇到了团队别阻塞的情况——构建集成环境的版本库各个分支变化太快，以至于合并后的版本没法和分支保持一致来支持Docker 版本。这就意味着，如果每个团队都不再将主分支合并到特征分支中，团队就没办法将代码提交到集成环境中。

例如，如果他们将主分支中的变化合并到了_tagservice_，每个工程师都需要更新_tagservice_。否则，由于依赖的应用无法工作，一些不相关的服务会突然崩溃。这就使得拥有一个稳定的配置更加困难，拉慢了所有人的速度。他们终于将所有工作进行到了模拟阶段，但在这个点遇到了难题。运维团队的负责人Mark 花费了15 个小时在他T 恤上加了一句话：“请将主分支合并到特征分支中…请记着一直这样做。”。

在最新的这篇文章发表时，他们已经进行到了项目的第五周。相比于之前的计划，项目进度有些落后。第一组服务进入生产环境的时间落后计划10 天；第二组服务进入生产环境的时间与计划时间刚好吻合；第三组服务只有3 个应用，预计还需要一周才能进入生产环境。引起时间延迟的主要原因就是集成环节——开发结束之后，容器需要移动到模拟环境，并且需要在移动到生产环境之前保证所有的回归测试通过。还有一部分延迟是服务的开发时间比预期长了一些。

目前的模拟环境包含了容器化的服务和传统部署的服务，而让两种服务一起工作是非常复杂也非常耗时的任务。由于之前的自动化工具并不能处理这种混合的情况，他们选派了一个运维工程师来保证这项任务的质量。因此，该任务就成为了一个瓶颈。但这名工程师也非常了解了如何让两类服务一起工作。尽管工作有所延期，之前采用的“置之死地而后生”的策略被证明为正确的决定。

重新定义工程师的每日工作任务

对于其开发团队而言，Sherpa 项目引起了工程师每天工作任务的两大变化：GitHub 的分支策略和本地开发应用的方式。之前，他们在GitHub 中设置了_master_、_staging_ 和_production_ 三个分支，来分别对应运行在各个系统中的代码。现在，他们重新定义了_staging_ 和_production_ 分支，将其对应为提交到驱动工作流的master 分支的指针。当代码提交到master 时，自动化工具会创建一个标记为“lastest”的镜像。该镜像会一直随着工作堆栈前进，直到进入生产环节。这使得该团队可以在追求持续交付方面走得更远。

Sherpa 项目的其中一个目标就是通过使用 Docker 来进行本地开发，增加开发和测试的速度和迭代效率。他们需要为开发人员提供两种机制来与微服务进行本地交互：

1. 为开发人员提供一种机制来从应用的版本库中检出代码，并在容器中建立应用和所有的依赖关系。
2. 为开发人员提供一种机制，利用现有的依赖关系的容器，来使用开发人员的本地源代码构建应用。

当开发人员正在编写与服务交互的代码，而他又并非该服务方面的专家时，第一种方法非常有用。配置和引导服务的速度越快，实际想做的事可以花费的时间也就越多。在这种用例中，他们使用了 docker-compose.yml 和标准的 Docker Compose 工具。一个简单的“docker-compose up”命令即可实现一个应用的自我安装、创建数据库并配置为与任何有依赖关系的微服务进行通信。

第二种用例是针对那些工作在其所擅长的应用的开发人员的。利用第二种方法，开发人员可以运行容器所需要的所有依赖关系，并对自己编写的代码在不必建立开发环境的情况下进行迅速迭代修改。RightScale 的架构师 Tony Spataro 编写的一个开源 RubyGem 在这方面提供了很大帮助。

到目前为止一切顺利

目前为止，迁移到 Docker 的行动已经取得了一些预期的成果，包括极大的提高了开发人员和 QA 团队的迭代速度。之前，当测试一个 bug 修复时，RightScale 的 QA 团队需要建立一个集成环境，并运行测试集才能重新生成之前的问题。然后，他们将代码放到一个单独的服务中来让系统运行到一个状态——系统正在运行包含修复的代码，之后重新运行测试集以验证之前的 bug 是否被修复，而且没有新的回归被引入。该工程通常需要 1-2 个小时。现在，RightScale 的 QA 团队可以在本地运行他们所需要的服务，将其作为基准进行测试，将包含修复的 Docker 镜像来下来，重新本地运行测试集，并可以在 20 分钟之内完成他们的任务。对一个 bug 修复而言，其速度提供了 3-6 倍。

此外，Tim Miller 等还发现移植后的服务可以节约服务器密度提高所带来的花销。未来，他会分享 Sherpa 项目的更多统计数据。至此，Sherpa 项目已经离终点很近了。接下来，他们只需要再加把劲，就可以完成整个迁移任务。

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

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

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

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