最初のベータ版に続いて，HashiCorpは，Atlasを一般向けにリリースした。インフラストラクチャのためのバージョン管理システム構築を目的に，同社の開発運用向けオープンソースツールを統合した商用プラットフォーム製品だ。Vagrant, Packer, Terraform, Consulといったツールを統合したAtlasの主な目的は，現代的なデータセンタ全体にわたる‘インフラストラクチャ変更の自動化，監査，コラボレーション’の促進にある。
同社のブログには，運用とインフラストラクチャを管理する目標として，‘自動化され，エラーフリーで，監査可能なプロセス’による，アプリケーションのデプロイとメンテナンスの実施があげられている。しかし現実には，時間を浪費し，エラーを起こしやすく，スケールアップの難しい，複雑な手作業のプロセスが用いられていることが少なくない。Atlasは，統合されたツーリングとコラボレーティブなワークフローを，開発者と運用担当者の両方に提供することによって，この問題の解決を図る。その対象は，アプリケーションのコードのプッシュからデプロイメント用のアーティファクト生成，インフラストラクチャ提供，最終的には運用中のアプリケーションライフサイクル管理にまで至っている。
Atlasのベータ版は2014年12月にリリースされた。参加企業の中には，MozillaやCisco，Capgeminiなども含まれている。HashiCorpのブログではAtlasについて，アプリケーションのコードバージョン管理システムと同じメリットを，インフラストラクチャコードやコンフィギュレーションに提供するものだ，と説明されている。
アプリケーションコードのバージョン管理はアプリケーション開発において，透過性，監査性，コラボレーションを可能にします。インフラストラクチャのバージョン管理は，パブリックおよびプライベートクラウドでのインフラストラクチャ管理において，これと同じことを実現します。それを通じてAtlasは，ひとつないし複数のクラウドに対するデプロイを簡略化する，共通的なワークフローを提供します。
AtlasはHasiCorpの以下のオープンソースツーリングを統合して，それらを有償(ノード単位)のホストサービスとして提供する。
- Vagrant。‘軽量で再現性があり，ポータブルな開発環境’を構築するために，仮想マシンのボックスを提供する。Atlasの統合環境では，チーム全体を対象としたVagrantボックスの生成，ホスティング，配布が可能だ。
- Packer。デプロイメント用アーティファクトの構築とストレージを自動化する。PackerをAtlas上で実行することにより，マシン/インスタンスの‘AWS EC2, Docker, VMWare, OpenStack, その他いくつかのクラウド/VMベンダを対象とするゴールドイメージ’の生成とストアが可能になる。
- Terraform。クラウド/データセンタベンダ間で，インフラストラクチャのプロビジョニングと管理が可能。TerraformをAtlasに統合することによって，(ローカルの運用マシン上ではなく)単一のリモートロケーションへの状態の保存，プロビジョニングの監査，(インフラストラクチャの’差異(diff)’と)アプリケーション変更のコラボレーションレビューが可能になる。
- Consul。高可用性キー/バリューストアを通じたサービスのディスカバリとコンフィギュレーション，一連のオーケストレーションプリミティブ(イベント，実行，監視)を提供する。Atlasの統合では，クラスタ状態の可視化，ノード監視，アプリケーションや関連インフラストラクチャに関するアラートなどが可能になる。
InfoQは，HashiCorpのカスタマサクセスディレクタを務めるKevin Fishner氏と対談して，Atlasの一般公開に関するいくつかの質問をした。
InfoQ: InfoQ読者の多くが疑問に思っているのは，‘ChefやAnsible, Puppet，あるいはSaltStack(“CAPS”)といったツーリングとGit(hub)のようなDVCSを組み合わせて使う場合に比較して，これにどのような違いがあるのか’，という点ではないでしょうか。
Fishner: ChecfやAnsible, Puppet, SaltStackなどのランタイムコンフィギュレーション管理ツールとAtlasには，いくつかの違いがあります。思想的なレベルでは，個別の問題解決のベースとして，アプリケーションデリバリ関連のオープンソースを使用している点が，他のデリバリオプションとは違います。そのようなオープンソースコンポーネントをひとつに取りまとめたものがAtlasなのです。具体的な問題としては 1)サーバの設定，2)サーバのプロビジョニング，3)サーバおよびその上で動作するアプリケーションのメンテナンス，などがあります。これらはそれぞれ，Packer, Terraform, Consulで解決されます。AtlasはPacker, Terraform, Consulをリモート実行しますので，すべての変更はバージョン管理され，監査可能で，コラボレーティブに行われます。私たちはこのモジュール型アプローチについて，Tao of HashiCorpで説明しています。これは，Unixの設計思想から着想を得たものです。先程あげられたCAPSツールもオープンソースを基盤としていますが，もっとモノシリックな構造です。HashiCorpのアプローチでは，チームは，Atlasエコシステムの部品(Packer, Terraform, Consul, Vagrant, Vault)を個別に利用することができます。不要かも知れないツールを強制的に購入させられることはありません。
技術的なレベルでのAtlasの大きな違いは，ランタイムコンフィギュレーションではなく，不変インフラストラクチャとビルドタイムコンフィギュレーションを採用している点です。不変インフラストラクチャに不慣れな人のために，ワークフローでは最初にデプロイメント可能なアーティファクトを，Amazon Machine Image(AMI)，Google Cloud Engineイメージ，OpenStackイメージ，Dockerコンテナなどの形式で構築します。そうした上で，構成の完了したこのアーティファクトを使ってホストをプロビジョンするのです。これに対してランタイムコンフィギュレーションでは，まずホストをプロビジョンして，実行時に構成する方式をとります。不変インフラストラクチャにはデプロイが多少速い，同一構成のホストを扱いやすい，全体としてよりスケーラブルな設計である，といったメリットがあります。
全体としてのAtlasは， インフラストラクチャ用のバージョン管理システムである，と説明できます。DVCSがPackerやTerraformのコンフィギュレーションを保持するのに対して，Atlasはこれらコンフィギュレーションをチューニングして，適切にプロビジョンされたインフラストラクチャを実現する責務を負います。アプリケーションコードのバージョン管理には，これまで多くの時間と努力が払われてきましたが，アプリケーションの動作するインフラストラクチャでは，不思議なことにバージョン管理が行われていませんでした。開発者にはコラボレーションの可能な，美しくて直感的なツールがあったのですが，運用担当者はある意味で取り残されていたのです。Atlasによって運用担当者にも，インフラストラクチャに対する責任を持ったコラボレーションと，変更の実施が可能になります。
InfoQ: Atlasを導入するメリットのある組織の規模，あるいはインフラストラクチャ資産の規模はどの程度なのでしょう？
Fishner: フルタイムの運用担当者が複数人いるチームが，Atlasの恩恵を最も受けられると思います。アプリケーションデリバリの全ステップにわたる透過性を提供することで，運用担当者がお互いに協力して変更作業をできるようになるからです。アプリケーションコードのバージョン管理システムと同じですね – プロジェクトの集中管理とコラボレーティブな変更を行うための，GitHubのようなバージョン管理システムを使わずに，チームが新たなアプリケーションプロジェクトを開始することなど考えられません。運用担当者とインフラストラクチャ用バージョン管理システム(VCI)でも同じです。これを実現するのがAtlasなのです。
InfoQ: CAPS/Githubスタックを離れてAtlasに移行する上で，中心的な要因ないし動機となるのは何でしょうか？また，マイグレーションパスはどのようなものになりますか？
Fishner: まず重要なのは，ふたつのスタックが互いに排他的ではないという点です。AtlasのTerraformを使ってインフラストラクチャのプロビジョニングを行った上で，コンフィギュレーション管理ツールでランタイムコンフィギュレーションを行うようなことも可能です。不変インフラストラクチャを使いたい場合でも，Packerによるデプロイ可能なアーティファクト生成にコンフィギュレーション管理プレイブックを使用することは可能です。ですから例えば，Chefをランタイムに実行する代わりに，完全に構成されたAMIを構築するためにPackerからChefを実行して，それをTerraformでプロビジョンすることもできます。その場合のマイグレーションパスは非常に簡単です - ChefのクックブックをPackerのビルドパスから参照すればよいのです！全体として，チームが不変インフラストラクチャかランタイムコンフィギュレーションか，どちらに投資したいかによって移行の動機は違ってきます。
InfoQ: Consulには基本的な監視機能が備わってはいますが，Data dogやBoundary，New Relicといった，コンテナ/クラウドを対象とする最近のモニタリング・アズ・ア・サービス製品に比較できるようなものではありません。HashiCorpとして，将来的にこの分野を目標としているのでしょうか？
Fishner: モニタリングツールについては，Consulを補完するものだと思っています。要するにConsulは，あなたの選択したモニタリングツールにメトリックを送信する，“データパイプ”の役割を果たすのです。
InfoQ: マイクロサービスベースのアプリケーション(および対応するインフラストラクチャ)では，包括的なテストという，現在未解決な問題も残っています。これに関して，読者に対する何らかの指針はありますか？例えば，Terraformで(おそらくはServerSpecのようなものを使って)TDDを行うことは可能なのでしょうか，あるいはAtlasでデプロイする場合，開発者はエンド・ツー・エンドのテストをどうやって行うのでしょう？
Fishner: とてもよい質問ですね，それが非常に大きな未解決の問題であることは間違いありません。その理由は，実運用環境を完璧に再現する環境の構築が，極めて難しい点にあります。Terraformは実際にこれを可能にしています。ステージング環境をスピンアップして，そこでServerSpecを実行している企業がいくつもあります。加えて，Terraformが“計画”と”実行”フェーズを分割することによって，運用チームは，コンフィギュレーション更新によって実行される変更が適切なものであることを，実運用環境への適用前に評価することが可能になります。Packerのビルド時コンフィギュレーションは，ランタイムコンフィギュレーションとは違って，実運用に到達する前に多くのエラーを検出できる点にも注目すべきでしょう。例えば，AMI構築中にPuppetがフェールしても，まったく問題はありません。
質問に回答して頂いて，ありがとうございました。その他，InfoQ読者に伝えたいことは何かありますか？
Fishner: Atlasでは，技術よりもワークフローを重視している点に注目してほしいと思います。これはつまり，Atlasでは，運用特有の問題 - 安全性と再現性があり，監査可能なプロセスを通じて，アプリケーションを開発中のコードから運用環境での実行へと移行すること - を解決している，ということです。Atlasはこれを，どのインフラストラクチャプロバイダ(現時点ではAWS, GCE, Azure, OpanStack, DigitalOceanをサポートしていますが，近日中にさらに追加される予定です)でも，どのようなテクノロジ(VM, コンテナ，コンフィギュレーション管理など)でも実行できます。AtlasはHashiCorpのオープンソースツールで構築されているので，チーム自身が使いたいAtlasの機能のみを選択して使用することができます。プラットフォームにロックインされる心配はありません。企業としての私たちは，データセンタを巡る技術の急速な変化を認識しています。例えテクノロジが同じでなくても，運用ワークフローは変化しないことは保証していきたいと思っています。
Atlasの公開リリースに関する詳細は，HashiCorpのブログ記事“Atlas General Availabiity”に紹介されている。Atlasおよび関連ツーリングの関する詳細情報は，HashiCorp Webサイトに掲載されている。