QCon New York 2015でMitchell Hashimoto氏は，大規模ソフトウェアシステムの安全なデリバリという究極の目標に対して，インフラストラクチャのプロビジョニング，コンテナベースあるいはクラウドアプリケーションのライフサイクル管理といった作業のオーケストレーションを行う上で，HashiCorpのTerraformやConsulなどのツールをどのように利用するか，というテーマを論じた。
HashiCorpの共同創業者で，VargrantやPackerの開発者であるHashimoto氏の講演は，ソフトウェアシステムというコンテキストにおけるオーケストレーションの究極的な目標は，大規模なアプリケーションを安全にデリバリすることにある，と述べることから始まった。アプリケーションのパッケージング，イメージ記録，実行といった問題に対する解決策がコンテナ技術だ。例えばDockerでは，これらの問題をDockerイメージ，Dockerレジストリ，Dockerデーモンでそれぞれ解決している。しかしながら，インフラストラクチャのライフサイクルやプロビジョニング，モニタリング，ディスカバリとコンフィギュレーションの提供，セキュリティ，アプリケーションライフサイクル管理といった課題は依然として残ったままだ。
Hashimoto氏は，開発者と運用担当者が“インフラストラクチャを安全かつ効果的に構築，結合，ローンチ可能”にするものとして，Terraformを紹介した。Terraformは，Hashicorp Configuration Language(HCL)で記述されたコンフィギュレーションファイルを使用して，コードによるインフラストラクチャ構築を行う。HCLはlibuclにヒントを得た，JSON完全互換の言語で，サーバやコンテナ，ロードバランサ，データベースなどをコマンドひとつで定義し，提供することができる。インフラストラクチャの変更のプレビューを生成して“diff”で比較し，議論し，プルリクエストを行うことが可能で，GitなどのDVCSを利用した通常の開発ワークフローとほとんど変わりがない。
サービスディスカバリとコンフィギュレーションはConsulで処理することができる。“サービスfooはどこにある？”，“マシンfooの稼働状態は？”，“デバイスfooのコンフィギュレーションは？”といった質問は，すべてConsulで回答可能だ，とHashimoto氏は言う。サービスディスカバリはHTTP APIの他，“レガシフレンドリ”なDNSでも提供される。いずれの手順でも，サービスの稼働状態に関する情報が提供される (あるいは，不正なノードについては報告しない)。
Consulは，コンフィギュレーションの高可用性ストレージ用として利用可能なキー/バリューストアも提供する。運用担当者は，“大規模なコンフィギュレーション管理プロセスを必要とせず，ノブを回す”ことが可能だ。また，デフォルトはローカル動作だが，マルチデータセンタ対応に構成することもできる。さらにHashimoto氏は，Consulがコンテナの中外問わずに実行することができる点も紹介している。Consulはその実行速度とスケーラビリティによって，将来的なアプリケーションの‘コンテナスケール’や，そこで生じる問題に対しても対応可能となっている。
InfoQは講演後のMitchell Hashimoto氏に連絡を取り，TerraformやConsul，コンテナ技術について質問することにした。
InfoQ: こんにちはMitchell，InfoQコミュニティの質問への回答に同意してくれてありがとう。最初にあなた自身，それからTerraformについて紹介してくれますか？
Hashimoto: そうですね，私が一番よく知られているのは，多分Vagrantの作者としてでしょう。 ですがops業界では，PackerやSerf, Consul, Terraform, Vaultの作者としての方が知られています。これらツールはすべて，世界中のWebサイトで大規模に運用されています。そのようなツールの開発に関われたことを，本当に誇りに思っています。私は自分自身のことを“オートメーション馬鹿”だ，と説明しています。この仕事と，コンピュータにそれを教え込むことが大好きなのです。今はこれをDevOpsのフィールドでやっていますが，これまでは教育やコミュニティ(フォーラム)，ゲームなど，さまざまな領域で行っていました。
Terraformは昨年登場したツールです。初期設定とメンテナンスの両面からインフラストラクチャの定義と構築を行うためのツール，と説明すればよいでしょうか。Terraformを始めて使った人は，AWS CloudFormationなどのツールと比較するかも知れませんが，Terraformを深く知れば，はるかにパワフルなツールであることが分かると思います。Terraformは任意のクラウドプラットフォーム上でインフラストラクチャを生成して，それらを組み合わせることができます。例えばAWS EC2インスタンスを生成して，そのインスタンスのIPアドレスをCloudFlare内のDNSレコード設定に使用するようなことも可能です。
これはまだ，ほんの入り口です ... まずはterraform.ioをご覧ください！
InfoQ: Terraformがデータセンタ/インフラストラクチャ自動化において担う役割について，特に機能面で重複するAnsible(あるいはPuppetやChefなど)との関係についての質問をよく見かけます。この件について何らかのガイダンスや，Terraformの理想的なユースケースはありますか？
Hashimoto: Ansibleをフルタイムで使用したことがないので，申し訳ないのですが，自信を持って比較することはできません。ですが，ChefやPuppetなどとの関係についての指針は提供できます。
Chef/Puppetなどの構成管理ツールは，Terraformの比較対象ではありません。リソースの初期生成(サーバを起動しロードバランサに接続するなど)の管理が可能という意味で，オーバーラップする部分はありますが，その部分でも簡単に区別が付きます。構成管理ツールに対して，Terraformには，コアエンジンのレベルで２つの大きなアドバンテージがあります。まずTerraformでは，任意のリソース内部にあるリソースの属性を参照することが可能です。これにより，AWSインスタンスを起動してIPアドレスを参照し，DNSレコードを設定する，といった操作が可能になります。ChefもPuppetも変数をサポートしていますが，属性にアクセスすることはできません。IPアドレスのような情報は事前参照ができないので，これはとても重要なことです！実行時にのみ存在する値という意味で，Terraformではこれを“計算(computed)”属性と呼んでいます。
もうひとつのアドバンテージは，リソースのライフサイクル管理が複雑であることです。例えばChefやPuppetでは，“古いリソースを削除する前に新たなリソースを生成する”という定義は簡単ではありませんが，Terraformではごく基本的なライフサイクル機能です。この重要性は明白です – ロードバランサに接続されたサーバがあって， 新たなサーバ生成を必要とする更新を行う場合(例えばベースイメージの変更など)，新しいサーバを生成して，ロードバランサをアトミックに更新した上で，– その後で – 旧サーバを削除したいと思うでしょう。この種のロジックが，Chef/Puppetでは表現が難しいのです。
それから，半分冗談のような話ですが，Terraformからリソースを削除すれば，Terraformはそのリソースを削除します。Puppet/Chefでは，リソースを削除済みであると明示的にマークしなくてはなりません。構成から削除したことを検出してくれないのです。面白いことに，ユーザミーティングでこの話をすると，毎回，ユーザから歓声が上がります！
InfoQ: AWS CloudFormationのようなベンダ/プロバイダ特有のインフラストラクチャツールは，ターゲットプラットフォーム向けにチューニングされているため，きめ細かい設定のコントロールが可能です。単一ベンダを利用している(あるいは大きく依存している)企業が，Terraformのような汎用的なツールをこれらのツールと比較したときに，不安になる部分はありませんか？
Hashimoto: まったく心配していません。
TerraformでAWSサポートを開発するために，一人をフルタイムで採用したのですが，ユーザから要求されていたリソースのほぼすべてをカバーするのに，１ヶ月も掛かりませんでした。そして先月(私たちと仕事を始めて２ヶ月目)には，CloudFormationに先行して，さまざまな機能を追加することができたのです。心配の解消にはこれで十分です。もう少し加えておくと，Terraformのリソース記述は極めて簡単です。これを可能にしたのは，コミュニティからのコントリビューションの大幅な拡大です。 将来的には，”新機能サポートのリードタイム”の面では，誰よりも先行できると思っています。
AWSに関してだけではありません。私たちはGoogle Cloudの，未発表の機能でさえ既にサポートしています。一般的に私たちは，これらのベンダと密接に協力して，彼らのプラットフォームを迅速にサポートできるようにしています。つまりWin-Winの関係です – 彼らはベンダ独自のツーリングのユーザを失う代わりに，プラットフォームに支払うユーザの数を増やす，私たちもユーザを増やす，ということです。
InfoQ: TerraformがプロバイダAPIの固有部分(SSLロードバランサでの暗号化サポート設定のような)をサポートしない場合，ユーザはこのような変更をTerraformの外で行わなくてはなりません。これらの変更を行った後でTerraformを実行すると，どうなるのでしょう？また，Terraformの将来のバージョンでこのような機能がサポートされた場合は，どうなりますか？
Hashimoto: Terraformが管理しないプロパティ(SSLロードバランサの暗号のような)に関しては，その変化を偏差としては監視しませんし，Terraformの動作に影響することもありません。
そのプロパティがサポート対象になっても，それが設定と一致している限りは偏差として見ることはありませんから，動作の変わることはありません。
単純なことだと思います。
InfoQ: インフラストラクチャベンダやプロバイダの提供するAPIやSDKは，時間の経過とともに変わります。下位互換性の維持やベンダの新機能のサポートについて，Terraformではどのような計画を持っていますか？
Hashimoto: インフラストラクチャベンダは，APIの互換性を十分に確保しています。例えばAWSを見てください，2006年当時のAPIプロトコルが今でもサポートされているのです！ですから，APIレベルではあまり心配していません。問題なのはライブラリのレベルです。ただし，TerraformはGo言語で記述されていて，ライブラリは静的にコンパイルされているので，リリース済のバイナリが影響を受けることはありません。ただし，上流ライブラリの変更が原因で，Terraformのマスタブランチのコンパイルが突然止まった，というケースが過去にありました。困ったことですが，これにはGoに追加される予定のベンダリングサポートで対処するつもりです。
新機能に関しては，主要なインフラストラクチャプロバイダは現在，SDKの完全自動生成に移行しつつあります。新機能が有効になると，すぐにSDKでもサポートされるようになるので，それを組み込むのも簡単になります！
InfoQ: TerraformはまだGA(General Available)としてリリースされていませんが，v1.0のリリースまで，現行のコマンドや生成されるコンフィギュレーションファイル(“.tfstate”ファイルなど)の下位互換性は，どの程度維持されるのでしょうか？
Hashimoto: Terraformには，非常に大規模な企業が何社も投資しています。私たちはTerraform 1.0に向けて，容易に実行可能なマイグレーションパスを必ず用意します。これまでは自動マイグレーションを用意してきました。状態には“バージョン”フィールドが含まれているので，構造のバージョニングに使用しています。
InfoQ: 現在のTerraformは，アップデートを実行する前に，前回実行時のインフラストラクチャ状態を格納した“.tfstate”ファイルが必要です。Terraformが単にプロバイダの照会だけで状態ファイルを構築可能になるのは，いつ頃を予定していますか？
Hashimoto: “もうすぐ”です。 1.0よりも，多分ずっと前になるでしょう。推測で言うならば，0.8ではないでしょうか。
インフラストラクチャプロバイダのデータは，Terraformのフルコンフィギュレーションよりもずっと少ないので，このプロセスは非可逆ということになります。それでも，可能な限りの設定を生成できることには意味がありますから，それを実現したいと思っています。
InfoQ: 最新リリースのTerraform 0.5ではマルチプロバイダサポートが追加されて，複数のプロバイダのインフラストラクチャをひとつのファイルに(AWSのマルチリージョンのように)定義できるようになりました。大量のグローバルインフラストラクチャを単一ファイルで管理するために，新たなツールを提供する予定はありますか？
Hashimoto: Terraformは同一ディレクトリにあるすべての*.tfファイルをロードしますから，ファイルの分割は可能です。さらにモジュールを使うことで，分割だけでなく，パラメータ指定も可能になります。
Terraformの目標は十分な選択肢の提供にあるので，必要以上に複雑になることはありません。
InfoQ: 先日，現代的なデータセンタの自動化に注目した新たなカンファレンスとして，“Hashiconf”の発表がありました。これについて詳しく説明して頂けますか？HashiCorp製品に関わるコミュニティの拡大を意図したものなのでしょうか，あるいは，同じような考えを持つ開発者や運用担当者がアイデアを共有する場所の提供が目的なのですか？
Hashimoto: 私たちには，非常に大きなコミュニティがあります！私たちは過去一年間，私たちのツールに興味を持ち，考えを同じくする人たちが集まって，その知識を共有するための，HashiCorpコミュニティイベントを作り上げるため，さまざまなことを尋ねてきました。これがHashiConf，すわなちHashiCorpのツールと，現実社会におけるプロジェクト間の対話にフォーカスしたカンファレンスなのです。例えば“HashiCorpの製品Xの使い方”といった講演ではなく，もっと一般性のある，“X社は製品Yと非HashiCorpプロジェクトZをどのように活用したか”というものになります。
加えて私たちには，数百人という，HashiCorpの最も情熱的なユーザたちがある場所にいますから，彼らに必ず報いたいと思っています :)
InfoQ: 質問に答えるために時間を頂いて，改めてありがとう，Mitchell。 その他，InfoQの読者に伝えたいことは何かありますか？
Hashimoto: 全部話したと思います！質問頂いてありがとう，とても楽しかったです。その他，私に連絡したいことがあれば，私のTwitterアカウントにEメールアドレスがあります。
Mitchell Hashimoto氏のQCon講演 “Orchestrating Containers with Terraform and Consul”に関する詳細は，カンファレンスのWebサイトで見ることができる。