写点什么

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

  • 2016-07-10
  • 本文字数:1754 字

    阅读完需:约 6 分钟

作为一家提供对多云平台统一访问接口的公司,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 )关注我们。

2016-07-10 17:342964
用户头像

发布了 268 篇内容, 共 113.6 次阅读, 收获喜欢 23 次。

关注

评论

发布
暂无评论
发现更多内容

品软件架构原则模式之美

老姜

为什么坐车会晕车呢

石云升

生活,随想 日常思考 晕车

第二周作业

武鹏

架构师训练营第二周

小树林

产品视角看推荐算法

峰池

人工智能 算法 产品经理 推荐算法

老大吩咐的可重入分布式锁,终于完美的实现了!!!

楼下小黑哥

Java redis 分布式锁

依赖倒置原则

极客李

第二周学习总结

武鹏

架构师训练营第二章课后作业

叮叮董董

“麻烦”的处理流程

zhoo299

随笔杂谈

架构师训练营 - 第二周架构师实现自己架构的主要手段

zcj

极客大学架构师训练营

什么是依赖倒置原则,为什么有时候依赖倒置原则又被称为好莱坞原则?

朱月俊

数据库周刊28│开发者最喜爱的数据库是什么?阿里云脱口秀聊程序员转型;MySQL update误操作;PG流复制踩坑;PG异机归档;MySQL架构选型;Oracle技能表;Oracle文件损坏处理……

墨天轮

数据库

架构师训练营第2周学习总结

Season

极客大学架构师训练营

第二次作业总结

朱月俊

做一个有原则的码农可好?

Dawn

极客大学架构师训练营

给行动找个理由

Neco.W

行动派 决策

架构师训练营二期作业

老姜

ARTS打卡Week 04

teoking

ios LeetCode ARTS 打卡计划

618你的系统顶住了么?系统发生重大灾难难道只能“删库跑路”?

punkboy

小师妹学JVM之:GC的垃圾回收算法

程序那些事

JVM 小师妹 JIT GC 签约计划第二季

依赖倒置和案例

王锟

这也太拧巴了吧?结局意想不到

非著名程序员

程序员 程序人生 提升认知

一个包子铺看懂 I/O 模型演变

小眼睛聊技术

Java 程序员 架构 后端 nio

用接口隔离原则优化 Cache 类的设计

朱月俊

架构师训练营第二章总结

叮叮董董

基本的面向对象原则(Basic OO principles)

旭东(Frank)

编程思维 极客大学架构师训练营

千万不能让程序员给娃娃取名字

码农神说

程序员

第二次作业

朱月俊

架构师训练营-第二章-依赖倒置原则&接口隔离原则

而立

极客大学架构师训练营

哪些框架是遵循依赖倒置原则的?

朱月俊

迁移到Docker:事情已完成近半_语言 & 开发_Tim Miller_InfoQ精选文章