開発から運用に至るフローを一体化するAtlas

Atlasの機能

Atlasは正式版のリリースがされたばかりで、日々、機能改善も続いています。以降は連載の最後として、これまでのツールの機能を振り返りつつ、Atlasとの基本的な連携方法を紹介していきます。

AtlasでVagrantの開発環境を統合

Vagrantは、開発環境を自動的に構築し、状態をコードで管理できるようにするためのツールです。Atlasと連携することによって、Vagrant用のマシン・イメージにあたる「box」を、Atlas上に保管し、共有・配布する機能があります。

さらにAtlasと連携し、ローカルの開発環境に対して、リモートからのSSHまたはHTTP（S）接続を有効にすることができます。そのため、複数の開発環境を抱える現場では、ネットワークを通して環境を共有できるため、開発効率の向上に貢献します。

詳しい設定方法は、連載の第二回目をご覧ください。

PackerとAtlasを使ったマシン・イメージの自動構築

Packerは仮想化・クラウド環境上のマシン・イメージを、自動的に構築するためのツールです。

Packerを使ったマシン・イメージの自動作成を、Atlasを通して利用可能になるだけでなく、誰がいつイメージを作成したのかを管理できます（図3）。作成したイメージ（アーティファクト）を自動的に保管したり、イメージ構築時のログを参照したりできます。また、複数のマシン・イメージを並列に自動構築する機能も提供されています。

図3：AtlasでPackerを用いたマシン・イメージの自動作成を管理する

具体的には「packer push」コマンドを使います。このとき、Packerが使用するJSON形式のファイルで任意のVirtualBoxのイメージを指定したり、AWSのAMIやDockerイメージを作成したりできるようになります。

この機能を活用すると、開発担当者がコードを作成した後、実際のインフラで利用する準備のためのマシン・イメージ作成を、スムーズに行えるようになります。実際に操作してみる際には、公式のチュートリアルも参考にしながらの実行をお薦めします。

Terraformのリモート機能とAtlas

Terraformは、クラウドや仮想化の環境を設定ファイル（コード）で管理するためのツールです。一般的にGUIを通した操作は、設定作業に時間がかかったり、作業ミスが発生したりする懸念があります。また、複数の環境を使用している場合は、ネットワークやシステム構成の違いにより、状況の把握が大変になりがちです。

Terraformはこれらの問題を解決するためのもので、コマンドライン上の簡単な操作によって、自動的な環境の構築・変更・破棄を、迅速かつ手軽に行えます。環境に関する設定はテキスト形式のファイルによって管理するため、環境の再現性も高く、繰り返しの環境構築・破棄が多い場合に特に力を発揮します。

環境の構築作業が自動的に行えるTerraformは便利ですが、チームやグループで使う場合には、管理上の課題が発生します。そのなかでも、いつ、誰がインフラの設定を変更したのかを把握することは、課題の１つです。また、Terraform実行時の記録の保管や、環境の変化をどのように記録・保存しておくべきかという課題もあります。

これらの問題を解決するのが、Atlasと連携するTerraformのリモート機能です。通常Terraformを実行するには、ローカルまたはリモートのPC上にTerraformのバイナリを設置して実行する必要がありました。ここで「terraform remote push」を実行すると、Atlasを通して環境の構築・確認ができるようになります（図4）。

図4：Atlas上からTerraformの機能を利用して環境の構築・確認を実行する

Atlasであれば、Terraformとの連携にとどまらず、他のツールも共通のGUIで操作・管理可能です。たとえば、Packerで自動作成したマシン・イメージ（アーティファクト）を使って環境を構築したり、Consulと共通のインターフェースを通して稼働状況を把握したりすることも可能になります。さらに、GitHub等の外部のサービスと連携することもできます。

こちらにつきましても、詳細はTerraformに関するチュートリアルのページをお読みください。

Consulのサービス・ディスカバリをAtlasで行うには

Consulは、サービス・ディスカバリと分散環境におけるオーケストレーションを行うためのツールです。AtlasのConsul統合機能（auto-join）を使えば、AtlasのGUIを通してConsulノードやサービスの状態を監視することもできます（図5）。

図5：Atlas上からConsulノードやサービスを監視する

複数のクラウド間やリージョンにまたがるようなシステムでは、これまで個々の環境にConsulサーバをセットアップする必要がありました。現状、環境間の連携はできませんが、AtlasのConsul機能を利用することで、一括して状況を把握できるようになります。

具体的には、consulエージェント起動時、以下のように「-atlas」と「-atlas-join」オプションを追加するだけです。

あとは自動的にConsul上のGUIにクラスタのノード情報や、Consulエージェントが把握しているサービス名・ヘルスチェック情報や標準出力がブラウザ上で参照できるようになります。また、Atlasと連携することにより、サービスの障害発生時に外部のサービスを経由してアラートを送信することもできます。詳しくはドキュメントをご覧ください。

そのほかのAtlasの機能

Atlasは、2015年の7月に正式サービスが開始されたばかりです。HashiCorpの他のツールと同じように、Atlasも日々機能の追加や改善が行われています。Atlasの興味深い点は、単にHashiCorp製ツール間の統合で閉じてしまわないところです。実際HashiCorpのブログ（英語）には、TerraformとGitHubを連携する方法や、Consulと外部の通知サービスとの連携記事が紹介されています。

Terraform in Atlas：GitHub Integration – HashiCorp
https://hashicorp.com/blog/atlas-terraform-github.html

Consul in Atlas：Alerts and Monitoring – HashiCorp
https://hashicorp.com/blog/atlas-consul-alerts.html

他にも、VagrantとPacker、PackerとTerraform、そしてTerraformとConsul間の連携を行うこともできます。詳しくはチュートリアルをご覧ください。

チュートリアル
https://atlas.hashicorp.com/tutorials

Atlasのまとめ

HashiCorpの様々なツールが持つ機能を取りまとめるのが、Atlasという名前のプラットフォームです。Atlasの役割は、インフラをバージョン管理できるシステムを提供することと、設定変更の自動化やログの記録を、様々なインフラ事業者を横断して使えるようにするものです。

しかし、他のHashiCorpのツールと同様に、Atlasも必ず「使うべき」ものではありません。単純にAtlasを導入するだけで、DevOps的な開発・運用スタイルが実現できるわけではないのです。もし、問題解決に役立つのであれば、他のHashiCorpのツール群や、そのほかのDevOpsツール・サービスと連携して使うのが望ましいと思われます。

The Tao of HashiCorp（HashiCorp道）では、HashiCorpのツールやサービスの設計思想は「本来あるべき姿」を第一に考えているとあります。大切なのは、HashiCorpのツールをいかに使うのかではなく、いかに「自分たちの業務を効率的に行うか」であり、自分たちの「業務フローがどのようにあるべきか」を考えることが大切です。

The Tao of HashiCorp（HashiCorp道）
https://hashicorp.com/blog/tao-of-hashicorp.html

もし、HashiCorpの思想と方向性が一致しているのであれば、是非これらのツールを試してみてください。本連載が皆さんの業務改善や自動化や効率化の一助になることを願っています。

【参考文献】

Atlas（アクセス：2015/09）
https://atlas.hashicorp.com/

Atlas General Availability - HashiCorp（アクセス：2015/09）
https://www.hashicorp.com/blog/atlas-general-availability.html

The Tao of HashiCorp 日本語参考訳 | Pocketstudio.jp log3（アクセス：2015/09）
http://pocketstudio.jp/log3/2015/03/14/the-tao-of-hashicorp/