迁移到Docker：让飞轮转起来

发布于 2016年7月6日

http://www.infoq.com/cn/articles/migrate-to-docker-part02?utm_campaign=rightbar_v2&utm_source=infoq&utm_medium=articles_link&utm_content=link_text

作为一家提供对多云平台统一访问接口的公司，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容器的动态监控和警告