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

これまでの連載では、HashiCorpが提供する様々なツールの使い方を見てきました。連載の最後に、各々のツールを結び付けるAtlasを紹介します。

DevOpsを支えるインフラを提供するAtlas

Atlasは、HashiCorpが提供するオンラインのサービスです。これまでの連載で取り上げたツールは、いずれも連載の第一回で取り上げたThe Tao of HashiCorp（HashiCorp道）という設計思想に基いて作られており、その1つ1つがそれぞれの目的のために作られたものでした。現在、HashiCorpによって提供されているツールと役割は、以下の通りです。

HashiCorpが提供するツールとその役割

共通しているのは、いずれも何らかのワークフローの解決を目指すという点です。そのためにHashiCorpが提案しているのは、コード化を通した自動化です。それは、効率の向上だけでなく、人手による誤りを防ぐという役割も持ちます。そのため、本来行いたい開発や運用に関する業務に集中するための仕組みを提供しています。

その一方で、実際の開発から運用に至る流れを見てみますと、各ツールを組みあわせる必要が出てきます。たとえば、次のようなケースが考えられます。

• Vagrantで作った環境を、Packerでマシン・イメージ化したい
• Packerで作成したマシン・イメージを使ってTerraformで使いたい
• Terraformで作った環境を、Consulで監視・オーケストレーションしたい

そこに登場するのがAtlasです。Atlasは、サイトの説明によると「開発から運用に一貫したフローを提供する」とあります。Atlasは、これらのツール間の溝を埋めるために必要な、統一したインターフェースを提供します（図1）。GUI上でマシン・イメージ（アーティファクト）、インフラの設定、アプリケーションの稼働状況を、まとめて管理できます。それだけでなく、Atlas上に各種の設定を保存したり、Atlasの環境を通してリモート上のクラウド環境に対して、自動的な処理を行ったりすることもできます。

図1：Atlasの概念図

「誰が何をしているのか」を把握

通常のHashiCorpのツールはコマンドライン上で使うもののため、誰が何をしているか状況を把握することは困難でした。ですが、Atlasというプラットフォームを使うことにより、誰がどのようなイメージを管理しているか、インフラに対してどのような変更を行ったかなどを容易に確認できます。また変更時の記録（ログ）はAtlas上に一括して保管されるので、どこに記録を残すべきか迷うこともありません。

Atlasは、ネットワークを通した共同作業を行う場合に、特に力を発揮します。一社内、一部所でというより、広範囲のリモート—ワークにおける共同作業の場のほうが、Atlasを使うメリットを実感できるでしょう。一方で、既にチーム内で開発から運用に至るフローができている場合は、あえてAtlasを導入する必要がないかもしれません。

Vagrant CloudからAtlasへ

Atlasは、2014年12月に公開されました。突然の発表でしたが、Atlasにはその前身とも言えるサービスがありました。それが、2014年3月にリリースされたVagrant Cloudです。当初はVagrant用のbox（マシン・イメージ）を共有したり、Vagrantの共有機能を使ったりするためのものであり、どちらかと言えば開発者寄りのものでした。一方、現在のAtlasは開発者だけでなく、運用視点でのサービス監視機能や、開発と運用の境界ともいえるインフラの管理も行えるようになっています。

料金について

Atlasの料金体系について見ていきましょう。Atlasは、基本的に無料で利用できます。特にVagrantとPackerに関連するイメージ管理機能は、完全に無料です。一方、管理ノードは10ノードまで無料ですが、11ノードを超える分はノード毎に月額40ドルの料金が必要になります。この管理ノードとはConsulエージェントが稼働してAtlasの管理対象となるサーバか、Terraformによって管理されているリソースのことを指します。もしConsulとTerraformを両方使う場合は、多く使っている方が課金対象となります。ただし、課金対象となる管理ノードとは月平均で換算され、かつ前述のように10ノード分は無料となります。例えば、1ヶ月間に平均30ノードが稼働している場合、そこから無料対象となる10ノード分を差し引いた20ノード分が課金対象となります。

Atlasへのアカウント登録と準備

Atlasを使うためには、アカウントの登録が必要です。アカウントをお持ちでない場合は、登録用のページにアクセスし、アカウント名やメールアドレスの登録をお願いします（図2）。登録後のAtlasへのログインには、ここで入力したアカウント名またはメールアドレスを利用します。

図2：Atlasのアカウント登録画面

トークンの生成

HashiCorpのツールでAtlasを利用するためには、AtlasのAPIにリモートからアクセスするためのAPIトークンが必要になります。APIトークンを生成するには、Atlasダッシュボード画面右上にある自分のアカウント名をクリックし、「Tokens」のリンクを開きます。

入力フォームに「Atlas Token」等の文字を入れ「Generate Token」をクリックすると、画面上にトークンが表示されますので、コピーしておきます。この情報はパスワード認証なくAtlasの操作が可能なため、取り扱いには十分ご注意ください。また、トークンの文字列は再度表示できません。

取得したトークンは、環境変数ATLAS_TOKENにその文字列を定義しておきます。

export ATLAS_TOKEN="トークンの文字列"

それでは続いて、具体的な連携方法を見ていきましょう。

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 template.json
Push successful to 'packers/example'

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

Terraformのリモート機能とAtlas

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

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

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

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

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

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

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

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

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

$ consul agent -dc=cloud1 -node=web01 -data-dir=/tmp -config-dir=
/opt/consul/conf -atlas zembutsu/web -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/