HashiCorp 公开发布基础设施版本控制系统 Atlas

经过最初的试运行（beta program）， HashiCorp 公开发布了 Atlas ，这是一个商业平台，把他们开发和运营的开源工具统一起来，为基础设施的管理创造版本控制系统。Atlas 集成了 HashiCorp 的 Vagrant、Packer、Terraform 和 Consul 工具，主要目标为促进跨现代化数据中心的基础设施变更的“自动化、审计和协作”。

HashiCorp 博客表 示，管理运营和基础设施的目的是用‘自动化的、无错误和可审计的过程’来部署和维护应用程序。然而，组织经常使用复杂的手动流程，耗时、容易出错，而且难以规模化。Atlas 尝试通过为开发人员和运营人员提供集成化的工具和协作化的工作流来解决该问题；从应用程序代码的推送到部署工件的创建、基础设施的安装（provisioning）以及最终运行时应用程序生命周期的管理：

Atlas 的 beta 版本在 2014 年 12 月发布，使用该产品的组织包括 Mozilla、思科和 Capgemini。HashiCorp 博客指出，Atlas 为基础设施的代码和配置提供的好处，与应用程序代码的版本控制系统提供的相同：

就象应用程序代码的版本控制为应用程序的开发提供了透明性、可审计性和协作，基础设施的版本控制为在公有云和私有云上的基础设施管理实现相同的效果。其结果是，Atlas 提供统一的工作流程来简化跨一个或多个云的部署。

Atlas 集成了下面这些 HashiCorp 的开源工具，并把它们作为（针对每个节点）按需支付的托管服务来提供：

• Vagrant 提供虚拟机器的构建，来创建“轻量、可复制的和可移植的开发环境”。Atlas 的集成允许创建、托管和在整个团队中发布 Vagrant 盒子（box）。
• Packer 自动化部署工件（artifact）的构建和存储。Packer 可以在 Atlas 上运行，创建和存储按照版本管理的 AWS EC2 、 Docker 、 VMWare 、 OpenStack 和一些其它云 / 虚拟机供应商的机器 / 实例的‘黄金映像 ( golden images )’。
• Terraform 自动化跨云 / 数据中心供应商的基础设施的安装和管理。Atlas 和 Terraform 的集成允许状态保存到单一远程空间（而不是保存到本地运营商的多台机器上），安装会被审核，并能够协同审查（基础设施的‘变化’）以及应用的改变。
• Consul 提供服务的发现，通过高可用的键 / 值存储和一组编排（orchestration）原始类型（事件、可执行结构和监视）对服务进行配置。Atlas 的集成允许群集状态的可视化、应用程序和相关基础设施的节点的监视和报警。

InfoQ 和 HashiCorp 的客户服务（customer success）部门的总监 Kevin Fishner 一起坐下来，就 Atlas 的公开发布问了几个问题：

InfoQ：我们的很多读者可能会想到的一个关键问题是，‘相比于结合 DVCS，比如 Git(hub)，来使用 Chef、Ansible、Puppet 或 SaltStack（“CAPS”），这有什么不同’？

Fishner：Atlas 和象 Chef、Ansible、Puppet、SaltStack 这样的运行时配置管理工具相比，有几个不同之处。在哲学层次上，Atlas 不同于其它应用程序发布手段，因为它使用开源基础来解决应用程序发布领域的特定问题，然后把这些开源组件联合起来，形成一个统一的平台。这些特定的问题是 1）配置（configuring）服务器 2）安装服务器 3）维护服务器以及在其上运行的应用程序。这些问题分别由 Packer、Terraform 和 Consul 解决了。Atlas 远程运行 Packer、Terraform 和 Consul，所以所有的变更有版本控制，可以审计和协作。我们在 HashiCorp 之道中描述了这种模块化的方法，这是从 Unix 的设计哲学中提取出来的灵感。你提到的 CAPS 工具也有开源的基础，但是产品更为单一。HashiCorp 的方法 意味着团队可以使用 Atlas 生态系统的各个部分（Packer、Terraform、Consul、Vagrant、Vault），而不必被迫买入他们 可能不需要的额外工具。

在 技术层面上，主要的区别是，Atlas 拥抱不可变更的基础设施和构建时配置，而不是运行时配置。对那些不熟悉不可变更的基础设施的，流程是先构建可部署的 工件，比如亚马逊机器镜像（AMI)、谷歌云引擎镜像、OpenStack 镜像、Docker 容器、等等，然后使用完整配置的工件对一台主机进行安装。有 了运行时配置，主机首先进行安装，再在运行时进行配置。不可变更的基础设施带来更快一点儿的部署、相同的主机配置、以及整体更具伸缩性的设计。

总而言之，Atlas 可以认为是基础设施的版本控制系统。DVCS 可以存储 Packer 和 Terraform 的配置，而 Atlas 则负责把这些设置 变成正确安装的基础设施。有趣的是，我们花了这么多时间和努力对应用程序代码进行版本控制，而运行应用程序的基础设施却没有进行版本控制。开发人员有漂亮、直观的工具进行协作，而运营人员却有点儿被遗留在黑暗中了。有了 Atlas，运营人员现在能够负责任地对基础设施进行协作和变更。

InfoQ：什么规模的组织或者基础设施资源可以通过使用 Atlas 获得最大的好处？

Fishner： 有多名运营人员的团队可以从 Atlas 获得最大的好处，因为这为应用程序发布过程的所有步骤提供了透明性，让运营人员可以就变更进行协作。这类似于应用程 序代码的版本控制系统——为一个新的应用程序项目工作的团队，没有象 GitHub 这样的版本控制系统来集中管理项目，就改动进行协作，就绝不会开始。对运营人员也是如此，也需要基础设施的版本控制系统（VCI，version control system for infrastructure），这恰好就是 Atlas 所完成的事情。

InfoQ：从 CAPS/Github 堆栈离开，转移到 Atlas，核心的驱动力／动机会是什么？迁移过程会是怎样的？

Fishner：首先，重要的是意识到堆栈不是互相排斥的。你可以用 Atlas 中的 Terraform 来安装基础设施，然后在运行时由配置管理工具进行配置。如果团队想要使用不可变更的基础设施，配置管理剧本仍然可以被 Packer 用来构建可部署的工件。所以，例如，不在运行时运行 Chef，而是由 Packer 运行，来构建完全配置好的 AMI，然后再由 Terraform 安装。迁移的过程极其简单——只需在 Packer 的构建中引用 Chef 的菜谱（cookbooks）！总体而言，动机真的取决于，团队是想在不可变更的基础设施或者是在运行时配置上进行投入。

InfoQ：尽管 Consul 提供基本的监控，但是它并不和新兴的来自 Datadog、Boundary 或 New Relic 的容器 / 云监控作为服务的产品相竞争。这会是 HashiCorp 将来感兴趣的领域吗？

Fishner：我们把监控工具看作对 Consul 的补充。最终，Consul 可以作为“数据管道”发送量度数据到你选择的监控工具。

InfoQ：全面的测试也是目前以微服务为基础的应用程序（和相应的基础设施）尚未解决的问题。你对我们的读者对此有什么指导意见？例如，可以和 Terraform 一起使用 TDD（也许使用类似 ServerSpec 这样的东西？），以及在使用 Atlas 进行部署时，开发人员应该如何对其应用程序进行端到端（end-to-end）的测试？

Fishner：首先，这个问题问得很好。我同意这是尚未解决的巨大问题。其原因是，运行精确模拟生成环境的环境，是极其困难的。而 Terraform 实际上可以让团队做到这点，我们也看到很多公司运行 staging 环境，并在其中运行 ServerSpec。而且，因为 Terraform 分开了“计划”和“执行”阶段，运营团队可以验证配置的更新会导致适当的变更，然后再把这些配置应用到生产环境。重要的是也要注意，用于 Packer 的构建时配置，而不是运行时配置，在用于生产环境之前，会出现很多错误。例如，如果在构建 AMI 时 Puppet 的运行失败，实际上这没关系。

非常感谢回答这些问题。还有什么想跟 InfoQ 的读者分享的？

Fishner：重要的是要认识到，Atlas 是以工作流为中心的，而不是以技术为侧重点。我这么说的意思是，Atlas 解决了运营的固有问题——通过安全、可重复、可审计的过程，把应用程序从开发中的代码转移到在生产环境中运行。这可以使用你选择的基础设施供应商（现在我们支持 AWS、GCE、Azure、OpenStack、DigitalOcean，即将推出更多的）和你选择的技术（虚拟机、容器、配置管理、等等）来完成。因为 Atlas 构建在 HashiCorp 的开源工具之上，团队能够选择他们想使用的 Atlas 的任意功能，而不必锁定在该平台上。作为一家公司，我们认识到，数据中心的技术在迅速变化，我们将确保运营的工作流程保持不变，即使技术会变化。

有关 Atlas 的公开发布的更多信息，可见 HashiCorp 的‘ Atlas General Availability ’博客， Atlas 的其它详细信息和相关工具可见 HashiCorp 网站。

查看英文原文： HashiCorp Publicly Release Atlas, a Version Control System for Infrastructure

感谢张龙对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群）。