Intro の参考訳です。Terraform に対する理解の手助けになればと思います。※v0.1.0に対する記述のものであり、バージョンが変わると、内容にに変更が加わる可能性があります。
変更リクエスト大歓迎です。
Terraform 入門
Introduction
http://www.terraform.io/intro/index.html
Terraform 入門ガイドへようこそ！ こちらのガイドは、これから Terraform を始めるために役立つものです。ガイドでは、Terraform とは何か、どのような問題を解決するのか、既存のソフトウェアとの違いは何か、そして Terraform のクイックスタートから構成されます。
既に Terraform の基本に慣れているのであれば、Documentation は利用可能な全ての機能や、内部実装に関するリファレンスとなるガイドを提供します。
Terraform とは何か？
Terrafrom は、インフラの構築・変更・バージョン管理を安全かつ効率的に行うためのツールです。Terraform は既存の有名なサービスプロバイダや社内のソリューションを管理することができます。
まず、設定ファイル(configuration file)を使って、アプリケーションを実行するために必要な構成物や、どこのデータセンタを使うかといった、全ての情報を Terraform に対して伝えます。それから Terraform は実行計画(execution plan)手順を生成します。これは、インフラをどのような状態にしたいのか記述したもので、対象となるインフラ上で実行し、構築(build)するものです。
設定ファイルを変更することで、Terraform は、（インフラの内部の）何を変更すると、適用する(apply)できるのかという、実行計画(execution plan)を立てることができます。
Terraform が管理出来るインフラは、ローレベルの構成物（計算インスタンス、ストレージ、ネットワーク）だけでなく、ハイレベルの構成物（DNS エントリ、SaaS 機能、など）も扱うことができます。
Teffarom がどのように動作するか、具体的な例を知りたければ、使用例 (use cases) をご覧ください。
Terraform の主な機能は、以下の通りです：
コードとしてのインフラ (Infrastructure as Code) : インフラを高レベル設定構文を使って記述します。つまり、データセンタ（ネットワーク）の設計をバージョン管理したり、他のコードと比較できるようになることを意味します。さらに、インフラに関する情報を共有したり再利用することができます。
実行計画 (Execution Plans) : Terraform には "計画" (planning) というステップがあり、実行計画 (execution plan) を作成します。実行計画というのは、Terraform に対して適用(apply) を命令したときに、どのように処理するかを定義したものです。この計画があるため、Terraform がインフラを操作するとき、想定外の挙動をすることを防ぐことができます。
リソース・グラフ(Resource Graph) : Terraform は全リソースのグラフを生成できるので、依存関係の無いリソースを含め、作成・変更する内容を並列化することができます。そのため、Terraform は可能な限り効率的にインフラを構築しますので、運用担当者は各々のインフラに対する依存度を考察することができます。
変更の自動化 (Change Automation) : 人間による最低限の指示によって、インフラに対して複雑な変更を適用することができるようになります。それは、これまで説明した実行計画(execution plan)とリソースグラフによって、Terraform が何を変更して、何を実行しようとしているのか明確化できるので、人間による作業ミス(human errors)を防ぐことができます。
次のステップ
Terraform 使用例のページでは、Terraform の様様な利用方法について知ることができます。それから、Terraform と他のソフトウェアとの比較では、既存のインフラとの併用方法について。最後の入門ガイド(getting started guide)では、Terraform を使って実際のインフラを管理し、どのような働きをするか知ることができます。
使用例 USE CASES
使用例に入る前に、Teraform とは、のページを読んでおくと良いでしょう。この使用例のページでは、Terraform の使用例について考察しますが、実際には、もっと広い範囲で Terraform を使う事ができます。Terraform が持つ機能のうち、プロバイダ(provider)とプロビジョナ(provisioner)によってもたされる拡張可能な性質により、Terraform が利用可能になるリソースを、遙かに拡張することができるからです。
Heroku App セットアップ
Heroku はウェブアプリのホスティングでは有名な PaaS です。開発者はアプリケーションを作成したあと、データベースやメールプロバイダといったアドオンを付ける事ができます。dyno や worker の数を柔軟にスケールすることができるのは、最高の機能の１つでしょう。ですが、多くのアプリケーションは、外部のサービスが提供する機能を、迅速にアドオン的に必要とします。
そこで Terraform は、Heroku アプリケーションがセットアップ時に必要なアドオンをコード化（明文化）・保証することができるようになります。Terraform ができるのは、それだけではありません。アプリケーションの動作のために、DNSimple の CNAME を変更したり、CDN の CloudFlare のセットアップを行う事もできます。特に、Terraform であれば、これらの作業すべてがウェブインターフェースを使わず、30 秒以内に行う事ができるのです。
Multi-Tier （複数層）のアプリケーション
N層アーキテクチャは非常に一般的なパターンです。そのなかでも 2 層アーキテクチャで最も有名なのは、ウェブサーバをプールする層と、データベース層を使うものです。追加層としては、API サーバ、キャッシュサーバ、ルーティング(routing mesh)等があげられます。こちらのパターンは、各々の層を独立してスケールさせることができるので、問題を分離することができます。
Terraform は、このようなインフラを構築・管理するための理想的なツールです。各々の層をリソースの集合として記述することができるので、層でお互いに必要な依存関係を自動的に処理します。Terraform が保証するのは、ウェブサーバが起動する前にデータベース層が利用可能にすることであったり、ロードバランサが稼働するのであればウェブサーバの動作を確認する点です。各々の層が簡単にスケールできるように、Terraform は count という設定値を使うこともできます。これにより、リソースの作成とプロビジョニング（展開）は定型化かつ自動化されるので、負荷に応じてスケールさせることは、取るに足らないことになるでしょう。
セルフサービスのクラスタ
ある程度の組織の大きさになると、中央集権化された運用チームに、大きく成長したインフラを管理するように求められがちです。その一方でプロダクトチームは、運用チームが提供するツールを使うより、"セルフサービス"インフラを作るほうが魅力的になるでしょう。
Terraform は、サービスをどのように構築するか、スケールするかといった知識を、設定ファイルにおいてコード化（明文化）できるようになります。Terraform の設定ファイルを使えば組織の中でも共有できるので、顧客チームがブラックボックスとして設定ファイルを使う事もできますし、Terraform をサービスの管理ツールとしても使う事ができます。
ソフトウェアのデモ
最近のソフトウェアは、ネットワーク化や分散化されつつあります。Vagrant といった既存のツールを使って、デモ用の仮想環境を構築することができます。しかし、ソフトウェアのデモでは、実際のインフラを用いてプロダクション環境に近いものを提供できるかどうかとなると、チャレンジングなもの（取り組みがいがある、面倒）となるでしょう。
そこで、ソフトウェア開発者は Terraform の設定ファイルを作るだけで、AWS のようなクラウド事業者(providor)上でのデモ環境の作成・展開（provision）が可能となります。つまり、エンドユーザは簡単にソフトウェアのデモを各々のインフラ上で実行できるので、パラメータの調整、たとえば、クラスタのサイズをどのようにスケールさせるかのような厳密なテストができるようになります。
使い捨ての環境 ( disposable environment )
本番（プロダクション）や、準備（ステージング）、品質管理（QA）といった環境があるのは、日常的なものです。各々の環境は本番環境の小さなクローンに相当しますが、本番環境でリリースする前に、新しいアプリケーションのテストでも用いられます。しかし、本番環境は大きく成長し、より複雑になるため、ステージング環境を更新して維持するのは面倒になってくるでしょう。
Terraform を使えば、本番環境はコード化（明文化）できるので、ステージングや、品質管理や開発のために共有することができます。この設定ファイルを使う事で、テスト向けの新しい環境を迅速に使えるだけで無く、終われば捨てることもできます。Terraform は並列環境を管理することの面倒さを抑えるのに役立ち、柔軟に構築・廃棄することを実践できるようになります。
ソフトウェア定義ネットワーク ( SDN; Software Defined Networking )
ソフトウェア定義ネットワーク(SDN)は、データセンタにおける利用が一般的になりつつあります。アプリケーションの稼働をよくするために、運用担当者と開発者も、ネットワークを管理することができるようになりました。大部分の SDN の実装は、制御層(control layer)とインフラ層(infrastructure lyaer)です。
Terraform であれば、ソフトウェア定義ネットワークをコード化（明文化）することができます。Terraform の設定によって、制御層(control layer)におけるインターフェースの調整を自動的に行う事ができます。つまり、設定変更のバージョン管理を自動的に行えます。例えば、AWS VPC は最も一般的な SDN の実装ですが、Terraform を使って設定することが可能です。
リソース・スケジューラ
大規模なインフラでは、アプリケーションを特定のマシンに割り当てることは、少しづつ大変になりがちです。その問題を解決するために、Borg、Mesos、YARM、Kubernetes といった様様なスケジューラがあります。動的なスケジューラとして、Docker コンテナ、Hadoop、Sparok、そして多くのツールを使う事もできるでしょう。
Terraform が使えるのは、AWS のような物理的なプロバイダに限りません。リソース・スケジューラもプロバイダと見なすことができるので、Terraform は、それらに対してもリソースを要求できます。Terrafrom であれば、物理インフラ上であっても、スケジューラのグリッドを同様に動作させることができるでしょう。
マルチクラウドへの展開（デプロイ）
障害耐性(fault-tolerance)を高めるため、複数のクラウドを使い分ける事は魅力的な選択肢です。しかし、単一のリージョンなりクラウドプロバイダで障害耐性を高めようとしても、事業者（プロバイダ）に依存してしまいます。複数のクラウドに展開（デプロイ）することができれば、プロバイダの一部または全体で障害が起こったとしても、緩やかな回復ができるでしょう。
マルチクラウドへの展開を実現するためには、多くの既存のインフラ管理ツールを使う必要がありますが、クラウド特有のものもあり、難しいものです。Terraform はクラウドに依存しない（agnostic）ので、１つの設定ファイルを使って複数の事業者(provider)への展開を、クラウド間の依存性を考えずに利用できます。これにより、運用担当者は複数のクラウドインフラ上で、簡単に管理したり、オーケストレーションであったりスケールさせることができます。
Terrfarom vs 他のソフトウェア
Terraform vs. Other Software
http://www.terraform.io/intro/vs/index.html
Terraform は、リソースや事業者(provider)の柔軟に抽象化します。このモデルによって、物理ハードウェア、仮想マシン、コンテナ、メールや DNS といったプロバイダなど、全てを表記することが可能になりました。この柔軟性を使えば、多くの問題の解決に使えるかもしれません。つまり、Terraform と既存の多くのツールとは、一部で機能が被るでしょう。ここでは Terraform を、いくつかの既存のツールと比較します。ですが、Terraform は他のツールと排他的ではない事に留意してください。それらは、１つのアプリケーションを管理することもできますし、データセンタを管理することもできます。
Chef, Puppet, etc.
Terraform vs. Chef, Puppet, etc. - Terraform
http://www.terraform.io/intro/vs/chef-puppet.html
マシン上において、構成管理ツールを使ってのインストールや管理は既に存在しています。Terraform は構成管理ツールではありませんが、リソースの起動・初期化を最も適切に処理するため、それらのツールを使用します。
Terraform のプロビジョナ(provisioner)を使う事で、作成したリソースのセットアップ時に設定管理ツールを使えるようになります。Terraform はデータセンタやサービスに関連する高レベルの抽象化に焦点を当てています。そのため、既存の構成管理ツールが最も適切に処理できるところを、犠牲にする必要はありません。Terraform は、構成管理ツールと同様にコード化（明文化）に取り組むものであり、それらのツールを使ってインフラのデプロイを簡単かつ正確に処理するという、信頼性をもたらします。
CloudFourmation, Heat, etc.
Terraform vs. CloudFormation, Heat, etc. - Terraform
http://www.terraform.io/intro/vs/cloudformation.html
CloudFourmation や Heat 等のようなツールは、インフラの詳細を設定ファイルにコード化（明文化）することができます。設定ファイルを通して、インフラを柔軟に作成・構築・破棄することができます。Terraform は、それらが解決する問題に関して、影響を受けています。
Terraform は設定ファイルを使ってインフラのセットアップを簡単に行う事ができますが、それだけではありません。クラウド懐疑論(cloud agnostic；非クラウド環境？）や複数の事業者やサービスとも組み合わせる事ができるのです。例えば、Terraform であれば AWS と OpenStack 上のクラスタを擬似的に操作（オーケストレート）できます。それだけでなく、サードパーティ製サービス、たとえば CloudFlare や DNSimple といった他事業者の CDN や DNS サービスとも連携できるのです。つまり、Terrafrom は、特定の事業者(provider)が提供する限定的なサービスを管理できるだけでなく、あらゆる種類のインフラを管理出来ることを意味します。そのため、運用担当者は、各プラットフォームやサービスが提供する独特のツールによる互換性考慮する事なく、単純な構文で利用可能になります。
また、Terraform は実行計画(execution plan)という概念を使う事で、計画フェーズと実行フェーズを分離します。terraform plan コマンドを実行することにより、現在の状態をどのように変更するか、行動計画(action plan)を検討します。この計画には、どのようなリソースを生成するか、破棄するか、あるいは変更するかといったものを含みます。あるいは、terraform graph コマンドを使う事で、処理手順の依存性を視覚化することができます（訳者釈；dot言語のテキストを出力するので、それを graphviz 等に通すことで、複雑な処理手順を視覚化、評価することができます）。計画が策定されると、実行フェーズでの処理内容は、あくまでも計画にそったものしか処理されません。他のツールは、計画と実行フェーズを組みあわせています。つまり、運用担当者が変更を実施したときの影響範囲を、担当者自身が判断しなくてはいけないことを強いているため、大きなインフラにおいては迅速に取り扱いづらくなってしまいます。Terraform であれば、運用担当者が（作業実施前に）行う処理内容が極めて明確なので、安心して変更を適用(apply)させることができるのです。
Boto, Fog, etc.
Terraform vs. Boto, Fog, etc. - Terraform
http://www.terraform.io/intro/vs/boto.html
Boto や Fog 等のライブラリを使う事で、クライアントはクラウドプロバイダやサービスに対し、API を通してネイティブにアクセスできるようになります。いくつかのライブラリは特定のクラウドに特化し、他との差異をマスクし、繋ぎこもう（ブリッジ）としています。クライアントライブライを使う事は、API を使って低レベルなアクセスを提供するだけですが、そのためにアプリケーション開発者に対し、各々のツールの構築や管理を各インフラにおいて行う必要があります。
Terraform は事業者(providoer)に対するローレベルなプログラム的な接続を行いませんが、そのかわりに、クラウドリソースやサービスをどれだけ作成するか・展開するか(provisioned)・連結するかという、ハイレベルなコード化による記述によって、それを実現します。Terraform は、事業者(provider)やプロビジョナをサポートするために、プラグイン基盤モデルを提供しているので、公開されている API を通して利用可能なあらゆるサービスを扱う能力を持ちます。
その他のソリューション
Terraform vs. Custom Solutions - Terraform
http://www.terraform.io/intro/vs/custom.html
多くの組織における基盤の管理は、単純なスクリプトであったりウェブをベースしたインフラを通して行われ始めるでしょう。基盤が大きくなると、管理を手動で行っていると、ミスを誘発したり、退屈なものになりがちです。その結果、多くの組織は、複雑な手順の自動化を目指し、自前の管理ツールを作り始めるでしょう。
これらのツールを作ろうとすると、構築や管理のための時間とリソースを必要とします。ツールは、差し迫った問題を扱うため作られるため、組織が必要とする最低限の機能しか提供しません。その結果、拡張が難しく、かつ維持が難しくなりがちです。さらに、インフラ側で新しい機能が実装され、インフラの成長にもあわせて拡張したくても、ツールの更新が滞ることになってしまいがちです。
Terraform は、これらの問題に対応できるよう設計しています。単純な構文を提供する事で、あらゆるリソースを新しいツールについて学ぶ必要なく使えるようになります。Terraform は必要な全てのリソースを包括していますので、運用担当者は、各リソースの詳細を覚えたり作業時に判断する必要がないよう、リソース間における依存度は自動的に処理することができます。ツール構築という重荷を取り除くことで、運用担当者は、ツールではなくインフラそのものに対して集中することができます。
加えて、Terraform はオープンソースのツールです。さらに HashiCorp やコミュニティが、ヘルプや機能の拡張、
バグ修正、そして新しい使い方のドキュメント作成をおこないます。Terraform によって、あらゆる組織の中に存在する問題を解決するための手助けをするものです。組織の中で、わざわざゼロから作り直すことを避けるために、どこでも使えるような標準的な機能を提供します。オープンソースとしての性質も、長期間にわたって使えることをもたらすでしょう。