迁移到 Docker：让飞轮转起来

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

决定将整个RightScale 平台迁移到Docker 容器的确是一个很大的工程。而且，Tim Miller 团队也预想到了实际执行可能会遇到的挑战。他们想要将Project Sherpa 作为一个短期紧急项目进行执行，但是为了避免浪费时间和精力，他们需要一个计划来高效引导整个工程团队使用Docker。

在过去的18 个月，他们已经从Docker 的实验阶段走到了在开发中使用Docker 以及发布了7 个容器化的产品服务。一路走来，如何处理管理镜像、输入、监控和安全等挑战也已经被了解到。此外，迁移第一批服务到Docker 和开发“2.0”版本的设计模式还给了很多教训。

因此，他们决定在Project Sherpa 中采用灵活的方法。于是，在真正开始容器化进程之前，分配了两周时间进行准备。由于整个过程存在一定的风险会变得混乱，他们希望将这个过程尽可能的有效组织起来。

组织所有的团队

所有的工作从创建一个Sherpa 的项目团队开始。首先，RightScale 已经有了可以帮助别人的Docker 专家以及领导研发团队的架构师和项目管理经理。团队召开了若干Sherpa 项目的规划和启动会，并设定了一个每周的例会。此外，一个专门用于该项目的Slack 通道也已经被开通。

尽管开发团队仍然在进行正常工作，RightScale 公司为每个开发团队分配了一个运维工程师在容器化的过程中进行帮忙。来自开发和运维的Sherpa 项目的Docker 专家也被作为流动资源，根据需要分配到不同的团队进行帮忙，并保证设计决定的兼容性。在Sherpa 项目之外，他们还分派若干开发人员继续进行客户所需要的特性的开发以及修复所需的一些问题。

RightScale 的 Docker 圣经

一些曾参与早期 Docker 工作的 Sherpa 团队的专家提出了 RightScale 公司自己版本的“Docker 圣经”。该文档最重要的方面就是，它提供了针对 RightScale 的一些方法、编写了设计模型以及提供了 RightScale 适合完成的功能和特性。随着项目的进行，该文档会根据需要实时进行修改。

目前，Docker 圣经所包含的内容列表如下：

• 建立用于基于 Docker 开发的笔记本工作环境
• 将应用打包为一个 Docker 镜像
  • 准备容器化你的应用（ruby 版本！）
  • 创建一个应用于该应用的 entrypoint 脚本。
  • 决定 Docker 镜像的输入
    • 输入所做和不做的东西
    • 输入从而而来
    • 什么会是一个输入或不应该是一个输入？
    • 如何命名输入
  • 命名一个 Dockerfile/.dockerignore
  • 调试你的 Docker 应用
  • 将 Docker 应用交付给运维
  • 设计的考虑
  • 容器就是进程
  • TL;DR——短的版本
  • 详细的分解
    • 宿主机和容器的职责
      - 宿主机的职责
      - 容器的职责
    • 运维提供的东西
    • 开发者提供的东西
  • 在称事情为“已完成”之前需要验证的运维检查列表
  • 再次说明如何一起工作的？
  • 连续集成和部署 Docker 应用
  • 我如何使能针对应用的 CI/CD？
    • TL;DR
  • 具体的解释
    • 利用 sudo 使用 Travis box
    • 在 UI 中设置环境变量
    • 下载 Docker 的客户端二进制
    • 将 Git 提交信息添加到 Dockerfile
      - 必须有：带有 HEAD 提交引用的镜像标签
      - 最好有：备份到镜像的提交日志
    • 创建 Docker 编译脚本
      - 编译函数
      - CI 函数
  • 并行化编译

决定，决定！

在准备期间，他们还在如何处理一些常见情况方面做出了选择。这些情况就包括了如何在容器内运行 cron 任务以及如何命名、结构化和提供来自开发人员笔记本电脑中的各种输入到模拟环境和生产环境。Tim Miller 团队非常清楚，随着越来越深入了解这个过程，更多的常见情况会出现。他们会揭示并分享这些情况，使得团队能够保证方法的兼容性。

他们还讨论了技术负债和功能蔓延相关的问题。由于工程师们很容易就陷入到项目的海洋中很难自拔，他们划定了一个底线，以使得容器化可以作为近期的重点工作。然而，他们还是确定一些迁移到 Docker 所必须的技术负债，并分配工程人员来解决。

初始培训

Tim Miller 团队要求，一旦 Project Sherpa 启动，所有的开发人员都要做好全力冲刺的准备。作为对 Docker 新人的初始培训，他们召开了两次技术讨论来介绍 Docker 的基础知识。此外，他们还给每个开发人员指定了“家庭作业”——建立自己的环境，并创建一个“Hello World”应用。这保证了每一个人都可以正确建立环境，并在 Sherpa 项目启动时做好了准备。

工作划分

Sherpa 项目团队将 52 个应用 / 服务列在了内部的 wiki 上，并在每个上面标注了一个大致的难度等级（从简单到超级超级难）。大的项目团队将每个服务分配给了一个小团队，以平衡小团队之间的付出。一旦这些任务完成了，公司允许个别的开发小团队进行自组织。几乎在所有情况下，团队都会有至少两名开发人员来应对需要被容器化的服务。

调度

正如其他项目一样，决定项目的周期是需要一点技巧的。Sherpa 项目团队希望给定的时间刚好够完成容器化及解决哪些必须要应对的技术负债问题。因此，他们分配了 3 周时间来完成容器化工作，然后再利用 1 周的时间将所有内容整合起来，变成产品。为了到达“容器化完成”的里程碑，每个单独的服务都必须要被容器化，通过了基于 mini 环境的所有的 CI 测试并交付给了运维准备进入模拟环境。

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

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

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

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