转载

迁移到Docker：事情已完成近半

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

由于他们在项目启动之前已经做好了充分的准备工作，Sherpa团队保持了非常好的项目节奏。在文章发表时，52个服务中的26个已经完成迁移工作。而前两周的主要关注点都在输入方面。因此，Tim Miller更多的讲述了有关输入的细节。

Docker有吸引力的一点就是可以提升公司形象——容器化意味着用户在研发环境中构建的东西可以轻松在测试环境中运行，并最终成为产品中部署的内容。然而，事实并非完全如此——用户需要根据运行镜像环境和方式的不同进行配置。例如，一个容器化的应用在产品中是连接带有多个节点的MongoDB的。而其在模拟环境中运行时，用于灾难恢复和提高可用性的节点是不存在的。在两种情况下的配置肯定是不同的。那么，不同的配置究竟有多大难度呢？Tim Miller团队探索了所有的服务，发现了60-100个可配置的值。他们就需要能够在多个容器组成的环境中运行每一项服务：

在一个容器内或容器外的开发者笔记本/台式机上
通过用于自动编译和测试的CI系统
用户测试的集成环境
模拟环境
生产环境

把这些环境进行组合就会发现，配置的复杂度相当高。因此，他们就需要一个良好定义的方法。

Sherpa项目团队选择了十二因子方法。根据 12factor.net ，“在一个十二因子应用中，环境变量是粒度控制，而且相互正交。他们绝不会组合在一起成为‘环境’，而是针对每次部署单独被管理。这是一个随着应用自然扩展到更多部署时，平缓扩展的模型。”。

其一个例子如下：

迁移到Docker：事情已完成近半

十二因子方法给了Tim Miller团队一个管理应用输入的更加简单的途径。但是，他们仍然需要为每个环境提供合理的值。那么，这些值从何而来呢？他们根据对一系列问题的回答，将可配置的值进行了分类：

值是每个环境动态变化的吗？
哪个相关者负责提供该值？
值多久会发生变化？
该值是私密的吗？

根据这些问题的答案，他们将每一个值映射到了它的来源。接下来就是horse-trading环节了——说服每一个工程师映射的意义，并让他们同意标准和命名规范。为了能够区分“常用”和应用相关的配置，他们尽可能的专注于输入的标准化。“常用”的输入能够被跨平台重用，从而减少复制和复杂度。命名规范由他们所选择的工具、填充该工具的层次以及每个容器在针对常用和应用相关的输入查询该工具时使用的机制所驱动。

最终，他们选择了HashiCorp公司的Consul作为其提供配置值的集中化键值库。这些值包含了集成/模拟/生产环境中所需要的和定义的产品shard及集群相关的。其他操作团队肯定不会修改、开发人员又需要的值都放入了Dockerfile中。私密的值会在运行时通过RightScale ServerTemplate上的凭据输入来提供。此外，他们还产生了带有用于开发/测试工作流默认值的 .env 文件。Sherpa团队使用了Git版本库来保存历史数据和这些值的修改记录。基于Git库，他们还构建了通过验证配置文档的结构来对输入的变化进行审查的CI/CD工具，并对值进行完整性检查以避免部署时的错误。最后，设计一个结构化的组织、存储和传递值的流程能够很好的帮助他们实现跨用例重用Docker镜像的目标。

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