作为一家提供对多云平台统一访问接口的公司,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 ,“在一个十二因子应用中,环境变量是粒度控制,而且相互正交。他们绝不会组合在一起成为‘环境’,而是针对每次部署单独被管理。这是一个随着应用自然扩展到更多部署时,平缓扩展的模型。”。
其一个例子如下:
十二因子方法给了 Tim Miller 团队一个管理应用输入的更加简单的途径。但是,他们仍然需要为每个环境提供合理的值。那么,这些值从何而来呢?他们根据对一系列问题的回答,将可配置的值进行了分类:
- 值是每个环境动态变化的吗?
- 哪个相关者负责提供该值?
- 值多久会发生变化?
- 该值是私密的吗?
根据这些问题的答案,他们将每一个值映射到了它的来源。接下来就是 horse-trading 环节了——说服每一个工程师映射的意义,并让他们同意标准和命名规范。为了能够区分“常用”和应用相关的配置,他们尽可能的专注于输入的标准化。“常用”的输入能够被跨平台重用,从而减少复制和复杂度。命名规范由他们所选择的工具、填充该工具的层次以及每个容器在针对常用和应用相关的输入查询该工具时使用的机制所驱动。
最终,他们选择了 HashiCorp 公司的 Consul 作为其提供配置值的集中化键值库。这些值包含了集成 / 模拟 / 生产环境中所需要的和定义的产品 shard 及集群相关的。其他操作团队肯定不会修改、开发人员又需要的值都放入了 Dockerfile 中。私密的值会在运行时通过 RightScale ServerTemplate 上的凭据输入来提供。此外,他们还产生了带有用于开发 / 测试工作流默认值的.env
文件。Sherpa 团队使用了 Git 版本库来保存历史数据和这些值的修改记录。基于 Git 库,他们还构建了通过验证配置文档的结构来对输入的变化进行审查的 CI/CD 工具,并对值进行完整性检查以避免部署时的错误。最后,设计一个结构化的组织、存储和传递值的流程能够很好的帮助他们实现跨用例重用 Docker 镜像的目标。
想了解更多 Tim Miller 团队如何使用 Docker 的内容,可以观看其在线研讨会。它包括了:
- 安全产生高质量、易于管理的 Docker 镜像的建议
- 在笔记本和云之间多宿主机互联的建议
- 在产品中编排 Docker:服务发现、配置以及可审核性
- Docker 带来的宿主机密度的增加
- 用于 Docker 容器的动态监控和警告
感谢陈兴璐对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论