「Terraformって何がいいんですか？」と訊かれる度に答えていた内容が、とても良い感じにまとまっていましたので、ここで紹介します。2017年11月28日現在の Terraform Recommended Practices の参考訳です。
自動化や運用に興味がある方にとって参考となるのは、HashiCorp の Terraform に興味が無くても、成熟度に応じた自動化の段階分けと、各々の段階からどのように発展すべきかという手順です。手動→半自動→インフラのコード化（Infrastructure as Code）への進歩と、最終的には協調的インフラのコード化（Collaborative Infrastructure as Code）を目指して、バージョン管理や構成管理ツールと連携するにはどうしたらよいのか。あるいは、そこに Terraform や Terraform Enterprise がどのように関わっているのか、自分のインフラを見直すための切っ掛けになると思います。
なお Infrastructure as Code は、日本語で一般的に「コードとしてのインフラ」や「インフラのコード化」という表現が用いられています。英語の訳としては前者が相応しそうですが、技術的な意味合いから当翻訳では後者を採用しています。これは、「Collaborative Infrastructure as Code」という見慣れない言葉を「協調的インフラのコード化」と訳すにあたり、整合性を維持するためでした（コードとしての協調的なインフラ、だと語呂がよくない感じがしたためです）。
（ここから訳）
本ガイドが想定しているのは、Terraform の利用を小数の個人から、組織全体への拡大を目指しているエンタープライズ・ユーザです。
HashiCorp が専門としているのは、 IT 組織がクラウド技術を採用するための支援です。基礎となっているのは、私たちのこれまでの取り組みです。私たちはプロビジョニング（訳者注；システム基盤となる計算資源やネットワークの自動構築や自動設定）に対するベストな手法が collaborative Infrastructure as code （協調的インフラのコード化） であると確信しています。そのためには Terraform をワークフローの中心として使い、皆さんの組織における異なるチーム、役割、アプリケーション、開発層における境界を Terraform Enterprise を使い管理します。
協調的インフラのコード化は多くの他の IT ベスト・プラクティス（バージョン管理の利用や、手動での更新防止など）に基づいています。そして、皆さんが私たちの推奨するワークフローを完全に導入するためには、その前にこれら基礎の導入が必要です。最先端のプロビジョニング・プラクティスを達成するとは、いくつかの明確な段階を進んでいく旅なのです。
本ガイドで説明するのは、私たちの推奨する Terraform 手順（プラクティス）と、どのようにそれらを導入するかです。ステップはツールを使い始める所から始まります。これは、手順での作業に依存している場合、特に注意を払うべき基礎についても扱います。
Part 1 : 推奨ワークフロー概要 は、Terraform Enterprise による協調的インフラのコード化・ワークフローの全体的な概要です。どのようにインフラを準備・管理し、私たちが情報をやりとりするかを扱います。
Part 2 : 現在のプロビジョニング手順を評価 は、皆さんのインフラをプロビジョニングする現状の手順、これを評価する手助けとなる一連の質問です。私たちはオペレーションの成熟に応じて４つの段階を定義しました。これは皆さんが正しい方向に進むのと、手順採用に必要となる基礎を理解するのに役立ちます。
Part 3 : プロビジョニング手順を発展するために は、４つの成熟度の段階を通し、プロビジョニング手順をどのように発展させるかを導きます。多くの組織において、既にこのプロセスの半分まで到達しているでしょう。パート２で学んだことを使い、この旅がどこに向かうかを決めます。
このパートは４つのページに分かれています。
Terraform の目的とは、あらゆるインフラに１つのワークフローで自動構築（プロビジョニング）することです。このセクションでは、大きな組織を縦断して Terraform を扱うために、推奨する手順を紹介します。これが「collaborative infrastructure as code」（協調的インフラのコード化）と呼ぶ手順群です。
プロビジョニング手順の改善を試みますと、誰もが２つの主な課題に直面します。それは、技術的な複雑さと、組織上の複雑さです。
1. 技術的な複雑さ（Technical complexity） … 新しいリソースをプロビジョニングするには、インフラ事業者（プロバイダ）ごとに異なるインターフェースを使うため、日々のオペレーションにおいて、インターフェース間の差異に対する追加コストを負担させられます。扱うインフラ事業者が増え、多くの共同作業者が増えるほど、これらのコスト負担が増します。
Terraform が対処するのは、プロビジョニングにおけるワークロードから、この複雑さの分離です。リソース間の関連性を、インフラをコード化した設定ファイル群に定義します。そして、これらを１つの中心となるエンジンが読み込みます。それから、各インフラ事業者上のリソースを作成、変更、削除するために、多くの プロバイダ・プラグイン を利用できます。これらプラグインは IaaS （例：AWS、GCP、Microsoft Azure、OpenStack）や SaaS （例：Heroku）サービス群にアクセスできます。
つまり、Terraform が用いるのはリソース・レベルの抽象化ではなく、ワークフロー・レベルの抽象化モデルです。これにより、１つのワークフローでインフラを管理する手法を提供します。ここでは各事業者間で等価交換できないリソースを、一般的な概念として扱うのではなく、事業者ごとに固有のものとして扱います。
2. 組織上の複雑さ（Organizational complexity） … インフラが拡大するにつれ、インフラを維持するためには多くのチームが必要となります。効率的な共同作業（コラボレーション）のために重要なのは、各チームを横断するインフラ所有権の権限委譲と、作業単位で並列に競合することなく権限を持たせることです。大規模アプリケーションでコンポーネントの権限委譲するのと同様の手法で、インフラの権限を委譲するのに Terraform と Terraform Enterprise が役立ちます。
大規模アプリケーションで権限を委譲するには、集団を徐々に小さく分割し、個々のチームが所有するマイクロサービスのコンポーネントに集約します。各マイクロサービスは API を提供します。そして、API に変更がない限り、お互いが機能的に依存しているのにかかわらず、マイクロサービス・チームは並列に変更を加えられるのです。
この手法と同様に、インフラのコードを、小さな Terraform 設定ファイルに分割可能です。設定は、チームごとに所有できる範囲を制限できます。これらの独立した設定ファイル群は output 変数 を使って情報を出力します。また、 remote state ステータス で、他のワークスペースにある出力データにアクセス可能です。これは、まるでマイクロサービスが API を経由して通信・接続しているように、 Terraform ワークスペースは remote state を通して接続できます。
Terraform の設定を緩やかに連携しますと、チームごとに開発とメンテナンスを委譲できるようになります。この効率性を達成するためには、コードとしてアクセス制限をする必要があります。バージョン管理システムには、誰がコードをコミットできるか制限できます。しかし、 Terraform は実際のインフラを扱うため、更に誰がコードを実行できるか制限する必要があります。
これこそが、Terraform Enterprise (TFE) が組織におけるプロビジョニングの複雑さを解決する手法です。つまり、Terraform の実行環境を集約することで、組織におけるアクセス制御を、全てのワークスペースを横断できるようサポート・実施します。並列な開発を可能にするためには、これがインフラ所有権を委譲する手助けとなります。
スケールするインフラを管理する、４つの主な登場人物がいます。それぞれの役割で、異なる責任と課題があり、異なるツールと権限を Terraform Enterprise がサポートします。
（訳者注；セントラル IT とは、大規模組織における情報技術を担うという意味の、専門用語。集約された情報システム部門に相当）
チームが責任を持つのは、共通のインフラ手順の定義、チームを横断するポリシーの執行、共有サービスの維持です。
セントラル IT の利用者は１つのダッシュボードを通して、全てのインフラの状態と整合性を閲覧できます。そのため、間違った設定や誤動作があれば、直ちに修正可能です。Terraform Enterprise は Terraform 実行時のデータと密に統合しています。また、Terraform Enterprise はワークスペース（workspace）における Terraform 概念と実行を包括するように設計しています。これにより、一般的なセントラル IT システムよりも、より統合されたワークフロー経験をもたらします。
このチームが定義するのは、事業単位内部のチームが、グローバルなインフラをどのように分割・権限委譲するかです。また、このチームはワークスペース間の連携もできるようにするため、それぞれのワークスペースが公開すべき API の定義や、組織間にわたる変数やポリシーを策定します。
組織アーキテクトが欲しいのは、１つのダッシュボードを通して、全てのワークスペースの状態を表示し、ワークスペース間の連携状態をグラフ化することです。
複数の環境を横断する Terraform 設定ファイルを作成する所有者が、それぞれのワークスペースごとにいます。所有者が責任を持つのは各ワークスペースの正常性と、開発・UAT（ユーザ受け入れテスト）・ステージング・プロダクションというライフサイクル全体を通した管理です。所有者とは、各領域のプロダクションにおける変更を承認する主担当者です。
ワークスペース所有者が欲しいのは：
ワークスペースにおけるコード化したインフラの設定ファイルを更新するには、コントリビュータが変更を実施します。通常、コントリビュータはプロダクションにおける変更を承認しません。しかし、開発・UAT・ステージングにおいては承認します。
ワークスペース・コントリビュータが欲しいのは、ワークスペース間の変更を実施して伝えるための、シンプルなワークフローです。ワークフロー・コントリビュータが編集できるのは、ワークスペースで共有する変数と、個人用に使う変数です。
大抵のワークスペース・コントリビュータは、Terraform の操作モデルとコマンドライン・インターフェースに慣れています。そのため、Terraform Enterprise のウェブ・インターフェースも迅速に採用できます。
Terraform Enterprise（以下 TFE ）を組織で使う主な単位（ユニット）がワークスペース（workspace）です。ワークスペースとは、 Terraform が処理を実行するために必要な全ての集まりです。これは、実行する度に操作を追跡可能とするため、設定ファイルの変数と状態データ（state data）のために必要となるものです。また、Terraform 設定ファイル（通常はバージョン管理システムのリポジトリを使用）と変数も含みます。
Terraform オープンソース版では、ローカルのディスク上にある個々の状態ファイルがワークスペースに相当します。TFE は共有リソースの一貫性を保ちます。そのため、共有リソースに対するアクセス制御や、実行状態の監視などが可能になります。
ワークスペースは TFE で権限委譲を管理する主要なツールです。つまり、ワークスペースの構造は、皆さんの組織における権限構造と一致すべきでしょう。ベストな取り組みは、インフラ・コンポーネントの環境ごとに、１つのワークフローを使うことです。言い換えますと、 Terraform 設定ファイル数 × 環境の数 ＝ ワークスペース数です。
これこそが環境を参照する他のツールとの明確な違いです。プロダクションやステージング環境の構築にあたり、全ての環境を１つの Terraform ワークスペースで管理すべきではありません。そうではなく、ワークスペースを小さくすることにより、権限委譲を簡単にします。また、環境が全く同じだとしても、全ての状況で同じ設定ファイルを使い回せません。例えば、ユーザ受け入れテストであれば、インフラに対する自社のセキュリティ基準をユーザには強制できないはずです。
ワークスペース名は、コンポーネントと環境の両方です。例えば、内部の請求アプリとネットワーク・インフラを関するための Terraform 設定ファイルがあるとしたら、ワークスペースの名前は以下のようになります。
各ワークスペースは１つのインフラ・コンポーネントごとに１つの環境を持つため、ワークスペースごとにアクセス制御をし、コンポーネントの所有者への権限委譲と、環境を横断するコード統制を伝えられます。例えば、
TFE を効率的に使うには、ワークスペースと権限の分割を、皆さんの組織における権限分割と確実に一致する必要があります。もしもワークスペースの効率的な分割が難しければ、インフラのある領域がベールに包まれ、責任範囲が混乱し、不明瞭になってしまうでしょう。もしもそうであれば、コード化と所有権の境界を改善するために、糸をほぐす機会となるでしょう。
今後のバージョンでは、TFE はワークスペースをまたがる周知用パイプラインを作成できます。
これまで説明してきたように、各ワークスペースは個々の環境ごとに Terraform 設定ファイルが与えられています。現時点では、コードの周知は手動で行う必要があります。進んだ環境にコードを切り替えるためには、以前の環境におけるコード実行に成功している必要があります。
いずれ、周知関連の設定もできるようになります。バージョン管理システムで直接コードを確認するのではなく、コードを受け入れるだけで、前の環境から新しい環境に切り替えられます。これにより、進んだ環境は正しいコードのみというのを保証します。
Terraform Enterprise は変数を設定する複数の場所があり、階層的に相互に上書きできます。全ての階層レベルにおいて、 TFE は Vault に安全に変数を格納します。
あらゆるワークスペースで、組織レベルに応じたデフォルト変数を使えます。例えば組織においては、全てのリソースが使えるデフォルトの請求タグを指定できるでしょう。
これは階層の最も低いレベルです。続くレベルは上書き可能です。
ワークスペースごとの変数です。大部分の変数はワークスペース・レベルに保管されます。これは、AMI ID やマシンのカウント、SSL 証明書等の保管に最も適している場所です。
個々のユーザに割り当てる変数です。全てのワークスペースで使うことができ、ワークスペース変数を上書きします。例えば、各ユーザに関連付けられた ARN に使えます。
これで Terraform Enterprise ワークフローの概要に詳しくなりましたので、皆さんの組織におけるプロビジョニング手順に進むときです。Part2 に続きます。
Terraform Enterprise は複数ある IT 手順の基礎に依存しています。Terraform Enterprise で協調的インフラのコード化を実装する前に、どの手順を既に使っているか、あるいは実装に何が必要かを理解する必要があります。
以下の本セクションはクイズやインビュー形式です。これまで見てきたように、組織で共通する成熟度に応じて、答えぶは複数の選択肢があります。メモ帳を手にして読み進めましょう。また、組織で自動化とコラボレーションを改善するために疑問があれば、あらゆることをメモしましょう。
このクイズには合格や不合格の基準点はありません。しかし最も重要なのは、皆さんの組織の答えを知ることです。どの IT 手順について最も注意を払うべきかが分かれば、現在の状態から推奨する手順に一直線で進むため、セクション 3 が役立つでしょう。
運用の習熟度においてレベルが異なるため、それぞれの質問には複数の答えがあります。４つのレベルは以下の通りです。
このセクションを最後まで読めば、皆さんの運用習熟度がどの段階にあるか、明確に理解できるでしょう。セクション３では現在の段階から次に進むための推奨する手順を紹介します。
それぞれの質問に対する回答は、皆さんの組織におけるインフラのプロビジョニング、ワークフローの変更、運用モデル、セキュリティモデルの理解に役立ちます。
現在の手順を理解したら、Terraform Enterprise を実装するために、どの段階に進めば良いか認識できるでしょう。
皆さんの組織では、インフラの設定とプロビジョニング手順を現在どのように行っていますか。自動化と一貫性のある手順こそが、インフラをより理解しやすく、信頼性があり、トラブルシューティングに費やす時間を減らすために役立ちます。
設定とプロビジョニングがどのレベルか評価するには、以下の質問が役立ちます。
UI 又は CLI を通します。一度限りの作業に対しては、最も簡単な手法に思えるでしょう。しかし、繰り返し行う作業はエンジニアの時間を大きく消費します。また、変更の追跡や管理は困難です。
コマンドライン・スクリプトの再利用を通してか、あるいは UI とインフラのコード化の組み合わせです。単なるその場限りの管理や繰り返し作業に比べ、より速く信頼できる手法です。しかし、一貫性とバージョン管理が欠如しているため、時間の経過とともに管理が困難になります。
インフラのコード化ツール（Terraform、CloudFormation）を通して行います。インフラのコード化により、インフラはスケーラブルで（訳者注；拡大・縮小を柔軟に行える）、再利用性があり、バージョン管理されます。各オペレータの生産性を著しく向上します。また、適切に使えば、環境を横断した一貫性を保てるようになります。
汎用的な自動化フレームワーク（例：Jenkins + スクリプト / Jenkins + Terraform）を通して行います。これはツールを使いながらも管理ワークフローを集約するため、プロビジョニング・タスクを個々に作る必要はありません。
１つのアカウントを使う、平らな体制です。全てのインフラを同じアカウントでプロビジョニングします。
複数のアカウントを使う、平らな体制です。インフラのプロビジョニングには、アカウント環境ごとに異なるインフラ・プロバイダを使います。
ツリー階層です。請求アカウント、監査、セキュリティ、ログ記録アカウント、プロジェクト／環境の用途ごとに、インフラのアカウントを使い分けています。
手動です。全てが手動であり、設定管理は行われていません。
サイロ化しています。アプリケーション・チームごとに、独自の手法でインフラを管理します。あるチームは手動で、あるチームはインフラのコード化やカスタム・スクリプトを用います。
環境ごとに異なるコードに基づく、インフラのコード化です。インフラをコード化する設定ファイルは、異なるコードを元にしています。そのため、環境内に変更が加えられたとしても周知できず、ある環境の設定は他の環境から追跡できません。
１つのコードに基づき、環境ごとで違う変数を扱うインフラのコード化です。環境に依存しない全てのリソースを、同じコードでプロビジョニングします。また、変更の周知を確実に行うため、何をデプロイするのか予測可能となる手法です。
全くありません。インフラのコード化を行っていません。
ローカルです。インフラの設定はローカルに保存し、メールやドキュメントやスプレッドシートを通して共有します。
チケット管理システムです。変更リクエストや問題/インシデント・チケットによる日々のエントリを通して共有します。
バージョン管理はありませんが、集約しています。コードを共有ファイルシステムに保管し、セキュリティ・グループで安全を保ちます。変更はバージョン管理されません。ロールバックを行える可能性があるのは、バックアップ又はスナップショットによる修復のみです。
設定ファイルの保管と共同作業をバージョン管理システム上（VCS）（Git リポジトリ、等）で行います。インフラ設定に関するチームの共同作業は VCS ワークフローを通して行います。また、これによりプロダクションに投入する前に、インフラの変更をレビュー可能にします。これが最も成熟した手法です。そのため、記録を保持しながら、異なる部署・異なるチームにおける可視化をもたらします。
全てが手動です。現時点ではインフラのコード化をしていません。
モジュール化していません。インフラのコード化は行っていますが、設定ファイルの利用は一度限りがほとんどです。ユーザは通常コードの共有・再利用を行いません。
チームはモジュールを内部で使いますが、他のチーム間では共有しません。
モジュールを組織全体にわたって共有します。ソフトウェアのライブラリを共有するように、インフラの共通パターンをモジュールにするため、更新は１度だけで済み、それが組織全体の利益となります。
プロダクトやシステムにおいて、変更の調整や承認にあたり、変更管理（change control）は適切な工程です。変更管理工程のゴールに含むのは：
変更管理ワークフローの習熟度を評価するために、以降の質問が役立ちます。
アクセスに対する制限がされていないか、監査されていません。プラットフォーム・チームの誰もが柔軟に、全てのインフラを作成、変更、削除します。これにより、再利用できず管理が大変な、複雑なシステムになります。
アクセスに対する制限はありますが、監査はします。これにより、何か事故がおきた後の追跡を容易にします。しかし、インフラの安定性を積極的に守ることはできません。
サービス・プロバイダのアカウント・レベルに基づきアクセス制限を実施します。各チームのメンバが持つ管理権限は、環境ごとに責任範囲が異なるアカウントに基づいています。
ユーザの役割（ロール）に基づきアクセス制限を実施します。全てのアクセスは、インフラのプロバイダ・レベルでユーザの枠割りに基づき制限されます。
リモートマシンにログインし、手動で変更します。繰り返しの手動タスクは非効率であり、人的ミスを引き起こしがちです。
ランタイム構成管理（Puppet、Chef、等）です。構成管理ツールは、信頼できて監査できるコードに基づき、素早く自動的に変更を行います。しかしながら、作成する成果物は毎回同じではありません。特定の設定ファイルのバージョンを使ったとしても、必ずしも 100% の再現性はありません。また、信頼してロールバックできるのは一部のみです。
（イメージ、コンテナの）イミュータブル・インフラストラクチャ（Immutable Infrastructure＝訳者注；固定されて変わらないインフラの意味、不変のインフラ）です。固定されたコンポーネントでデプロイされたものは、（個々に置き換えるのと比較して）全てを置き換え可能です。もしも一時的なレイヤ（ephemeral layers）と状態を格納するレイヤ（state-storing layers）間にある明確な境界を管理するのであれば、イミュータブル・インフラストラクチャこそがテスト、検証、ロールバックに最も簡単です。
手動（SSH、WinRM、rsync、robocopy、等）です。繰り返しの手動タスクは非効率であり、人的ミスを引き起こしがちです。
スクリプト（Fabric、Capistrano、カスタム・スクリプト、等）です。
構成管理ツール（Chef、Puppet、Ansible、Salt、等）です。あるいは、ユーザデータ・スクリプトを経由して CloudFormation テンプレートや Terraform 設定ファイルに渡します。
スケジューラ（Kubernetes、Nomad、Mesos、Swarm、ECS、等）です。
ソースコードに決め打ちします。極めて安全ではありません。
インフラ・プロバイダのロール（AWS では EC2 インスタンス role のように）を用います。サービス・プロバイダはマシンを識別できますので、実際の認証情報のコピーを使うことなく、API リクエストを用いてマシンに対する権限を付与できます。
シークレット（訳者注；SSH鍵やパスワードのような、機密性の高い情報のこと）管理ソリューション（例：Vault、Keywhis、PAR）を用います。私たちはこの手法を推奨します。
有効期間の短いトークンを使います。これは最も安全な手法の１つです。一時的な認証情報を用いるため、迅速な無効化ができます。そして、攻撃を非常に困難にします。しかしながら、シークレット管理ソリューションを使うよりも、より複雑になりがちです。
共通の admin や スーパーユーザ アカウントをエンジニアで共有します。インフラ・プロバイダ・アカウントの抜け道となる可能性が増します。
個々のユーザ・アカウントです。これにより、認証情報の喪失を引き起こしても、復旧は簡単です。しかし、チームが成長するにつれ、規模の拡大がとても大変になります。
LDAP やアクディブ・ディレクトリとの統合です。アカウントを共有するよりも安全です。しかし、プロバイダから自社ネットワークへの接続が適切に行われる状態を確保するためには、設計上の熟慮を追加する必要があります。。
OAuth や SAML を通したシングル・サインオンです。インフラ・プロバイダにはトークンを基準としたアクセスを可能にします。認証のために、プロバイダが自社ネットワークに接続させる必要はありません。
ログを記録していません。誰がいつ何を行ったかの記録がないため、監査やトラブルシューティングが非常に困難です。
手動の変更履歴です。共有ドキュメントにインフラの変更点をユーザが書き加えます。この手法は人的ミスを引き起こしがちです。
監査追跡サービスやログ管理サービス（CouldTrail、Loggy、Splunk、等）のために、全ての API コールを記録します。私たちはこの手法を推奨します。これにより、監査追跡がトラブルシューティングやセキュリティ評価においても確実に利用可能となります。
直ちに手動で行います。インフラのコード化を用いていない場合であれば、インフラ・プロバイダのコンソールを使い、手動で過去の従業員のアクセスを削除するのが、最も簡単かつ高速です。
後ほど、次期リリースの一部として対処します。もしもリリース手順が極めて連結している場合や、プロダクションに反映する前に、セキュリティの変更に変更諮問委員会（CAB; Change Advisory Board）のミーティングに諮る必要がある場合は、遅れがちです。
直ちにインフラのコード化のホットフィックスを書きます。これが最も安全かつ推奨する手法です。従業員がビルから退出する前に、アクセス権を削除します。
これら全ての質問に対する内容を検討したら、メモを振り返り、皆さんの組織全体の成熟度がどの段階にあるか評価しましょう。評価によっては、手順がほとんど手動ですか、半自動化ですか、インフラのコード化でしょうか、協調的インフラのコード化でしょうか。
現在の状態を心にとどめたまま、次のセクションに進みましょう。
現在の手順によって、厳しい表情になっているかもしれません。しかし、これからが改善するときです。
本セクションでは、組織における手動プロビジョニング手順を、協調的インフラのコード化に移行する手順を説明します。運用成熟度の各段階において、皆さんの組織が次の段階に進めるように手順を伝えます。最終的には、私たちの推奨するワークフローに到達します。
本セクションを複数のページに分割しました。そのため、既に実装を追えている手順があればスキップできます。Part 2 のメモを読み直し、運用習熟度がどのレベルにあるかを確認しましょう。
インフラ構築を手動で（ CLI や GUI ツールを使って）行う結果、インフラは検査が大変で、再構築が困難で、規模の変更が難しく、インフラに対する知識の共有も困難です。
現在、プロビジョニング手順の大部分が手動でしょうか。そうあれば、インフラで小さく管理可能なサブセットに対し、オープンソースの Terraform を使い始めるのが最初のゴールです。Terraform を使い小さな成功を重ねますと、プロビジョニングの成熟度は半自動の段階に進みます。そして、Terraform の利用を拡大しますと、スケールアップができるようになります。
こちらの手順に従って Terraform OSS をインストールします（英語） 。
Terraform 設定ファイル を書きます。
Terraform 導入ガイド を読み進めます。ページではリソースの 変更 と 破棄 や、 リソースの依存関係 の働きなどを通して学びます。
小さな実働中のプロジェクトを選び、そこへ Terraform を導入します。組織における次期プロジェクト一覧から、Terraform の概念実証となるプロジェクトを指定します。あるいは、既存のインフラを Terraform で再実装することも可能です。
プロジェクト選択の鍵は、範囲が限定され、明確な境界線があることです。例えば、AWS 上に新しいアプリケーションのインフラをプロビジョニングするケース。これにより、チームが機能や可能性に圧倒されるないために役立つでしょう。また、 プロジェクト例 から、他の選択肢を感じ取ることもできます。（スタート地点としては AWSの２層例 が良いでしょう ）
この時点でのゴールは、構築は小さいながらも、信頼性の中心である Terraform で経験を積むことです。そして、組織内の他人にとっても利点があると証明できます。
この時点で、プロビジョニング手順の半自動段階に到達しました。リソースのプロビジョニング手や変更のために、組織の１人又は複数人が Terraform のコードを書けます。小規模ですが、インフラのサブセットをコードとして管理し始めることに意味があります。これは他のチームに対してデモを行う良いタイミングです。インフラをプロビジョニングするには、Terraform の設定を書いて実行するだけです。Terraform がいかに簡単かを見せましょう。
次は、更に複雑なインフラのコード化・ワークフローに移行するときです。
ここでは半自動プロビジョニングとは、次の手順の少なくとも２つの組み合わせであると定義します。
現在のプロビジョニング手順が以上の状況であれば、次のゴールは Terraform の利用を拡大し、手動の手順や命令的なスクリプトの利用を減らすことです。そして、インフラのコード化をより一貫性をもって使いやすくするために、基礎となる手法を採用することです。
メモ：まだインフラのコード化をインフラの一部でも採用していなければ、次に進む前に、前のセクションをお読みください。
もしも組織で バージョン管理システム（VCS; Version Control System）が使われていなければ、VCS を選択し、導入します。
おそらく最小の Git/Mercurial/SVN サーバを準備できるでしょう。しかし、私たちはより堅牢な協調的 VCS アプリケーションの導入を推奨します。API でのデータ音アクセスや、リポジトリやアカウントの管理が可能なものです。ここでは Bitbucket、GitLab、GitHub が有名なツールです。
既に VCS ワークフロー、レイアウト、アクセス管理手順を確立している場合は、素晴らしい！ もしまだであれば、これらを決定する良い機会です（私たちは このアドバイス がスタート地点として相応しいと考えています ）。どのような状況下で、誰が変更をマージ可能かを計画します。コードはインフラ全体を管理可能ですので、整合性と品質の維持は非常に重要です。
また、組織における期待を紙に書き出し、チーム間で幅広く共有しておきます。
VCS システムを選定したら、Terraform Enterprise はアクセスできます。現時点で、Terraform Enterprise による統合をサポートするのは GitHub、GitLab、Atlassian Bitbucket（Server と Cloud の両方）です。
インフラのコードをバージョン管理に移行し始めましょう。新しい Terraform のコードは、全てバージョン管理かに置かれるべきです。つまり、既存の Terraform コードはバージョン管理外にあるため、移行を行います。これにより、組織内の誰でも特定の場所を見るだけで、変更の目的や履歴を追跡可能となります。
Terraform モジュール (module) は再利用可能な設定ファイルの単位（ユニット）です。これはインフラの部品を１つのパッケージとして管理可能にできます。そのため、主要な設定ファイルを、ワークスペースで何度でも呼び出し・書き込みできます。AWS 用にはオートスケーリング・グループを構成する Terraform モジュールの良い例があります。これは設定と、オートスケーリング・グループ、EC2 Elastic Load Balancer (ELB) を一まとめにします。もし既に Terraform モジュールを使っているのであれば、以下のベスト・プラクティスに従っているかどうかや、皆さんのモジュールを改善可能かどうか見落とさないでください。
次の図はモジュールを書くときに決める手助けとなります：
（フローチャートは提案中です。モジュールは構築パターンに応じて複数のリソースを再利用であるべきで、設定を削減したり、あるいは多くのリソース・タイプに応じてカスタムセットアップしたりします）
Terraform のスキルを他のチームに展開します。そして、これまでのインフラ・チームのスキルを改良します。さらに、内部でのトレーニングや自習についても、検討するかもしれません。
Terraform のコードを書くガイドラインとして使うため、標準構築アーキテクチャを作成します。組織を横断して共有する場合は、モジュールの活用がベストです。そして、インフラを設計周辺で、誰もが持つ期待が共通している場合、その共有がより効果的です。IT アーキテクトは、皆さんの組織が必要とする標準的なアーキテクチャを構築できるように設計すべきでしょう。チーム間を横断する一貫性を保ちながら、高い可用性、柔軟性、障害復旧を考慮した構築を後押しします。
以下はクラウド・プロバイダごとに役立つ構築パターン例です：
もしも既に組織で構成管理ツールを導入している場合は、Terraform と連携すべきときです。 Terraform プロビジョナ を使えば、リソースの作成後に、設定管理を使った処理を引き渡せます。Terraform はインフラを取り扱うべきであり、他のツールはユーザ・データやアプリケーションを扱うべきです。
あるいは設定管理ツールを使っていない場合、厳密にはイミュータブル・インフラストラクチャではありません。そのため、設定管理ツールの導入を検討すべきでしょう。これは大きなタスクとなりうるのですが、インフラのコード化を採用するのと同じゴールに至るのです。つまり、アプリケーションの設定をより制御可能に、理解可能に、そしてチーム間を横断して再利用可能にするのです。
ここから始めるのであれば、 Chef クックブックを作成するチュートリアル を通して、ローカルの Vagrant でテスト可能です。また組織において 設定管理ツールの何がベストか を決めるのかに関する記事をお薦めします。
Terraform と Vault を連携するか、他のシークレット管理ツールを使います。サービス・プロバイダの認証情報のようなシークレットは、常に安全を保ち続ける必要があります。しかし、必要に応じて簡単に使えなくてはいけません。ベストな手法は、専用のシークレット管理ツールを用い、必要に応じて割り当てることです。私たちは HashiCorp Vault こそが多くの皆さんにとって最上の選択肢と考えますが、Terraform は他のシークレット管理ツールとも同様に連携可能です。
この時点で、組織は VCS で設定ファイルを管理し、インフラ管理の鍵となるのが Terraform となり、少なくとも１つ再利用可能な Terraform モジュールを手に入れました。半自動手順と比べ、皆さんの組織は一貫性のある言語とワークローを用いることにより、インフラ設定のより優れた可視化をもたらしました。
次は高度なワークフローが必要です。スケールと、多くの貢献者による権限を委譲可能であることです。
バージョン管理された Terraform 設定ファイルを用いることで、インフラ管理の鍵となる技術的な複雑さと一貫性のなさを解消できました。これで基本は抑えましたので、次は他の問題に取り組む準備が整いました。
次のゴールは以下の通りです：
皆さんが直面しているのは、次のレベルにある問題です。これに対処するため、私たちは Terraform Enterprise (TFE) を作りました。以下のセクションでは、より効率的に使うにはどうしたら良いかを紹介します。
メモ：まだ皆さんのインフラの重要な部分で Terraform を使っていないのであれば、以下のステップに進む前に、前のセクションをご覧ください。
Terraform Enterprise の導入には２つの選択肢があります。SaaS かプライベートへのインストールです。SaaS バージョンを選択する場合は、次のステップを省略できます。そうでなければ、 インストール・ガイド から始めましょう。Terraform は output の出力として TFE の URL を表示します。
TFE ではどのように Terraform を使うのか、慣れていきましょう。Terraform OSS では、一般的に外部の VCS ツールを使い、ファイルシステム上にコードを置きます。それからコマンドラインか汎用 CI システムを使い、Terraform を実行します。
TFE は違います。VCS リポジトリとワークスペース（workspace）を直接関連付けます。そして、TFE の UI や API を使い、開始や実行状況を監視します。この運用モデルに慣れるには：
TFE では、各 Terraform 設定は個々のインフラ・コンポーネントごとに管理されるべきです。また、環境ごとに設定ファイルを設け、ワークスペースは分割されるべきです。言い換えれば、Terraform 設定数 × 環境数 ＝ワークスペース数です。ワークスペース名は「networking-dev」のような形式です。そのため、一目見るだけで、どのインフラと環境を管理しているのか分かります。
「インフラ・コンポーネント」定義は、皆さんの組織構造に依存します。与えられたワークスペースはアプリケーション、サーバ、あるいはグループに関連するサービスを管理するでしょう。つまり、あるエンジニアリング・チームがインフラをプロビジョンするかもしれません。あるいはビジネス全体で使うインフラの基本部分、このプロビジョニングを共有するかもしれません。
ワークスペースの構造は、皆さんのインフラに対する部門間の責任と一致するようにすべきです。おそらく、最終的には混合型となるでしょう。ネットワークのような複数のコンポーネントは共有し、インフラの基本部分はセントラル IT スタッフによって管理されます。つまり、各エンジニアリング・チームは各アプリケーションに関連する部分しか管理しません。
また、以下の点に注意してください。
１つ目の連携として、ワークスペース間の連携とはコンポーネントごとに異なります。しかし同じ環境では、ワークスペース間の依存性グラフ（訳者注；ノードの集まりとエッジの集まりで構成されるデータ構造）を作成します。これにまず注意を払うべきです。２つ目の連携は、同じコンポーネントを使うワークスペース間でも、環境が異なる場合は、ワークスペース間のパイプラインを作成します。現時点の TFE には、これらの関連性を処理できませんが、近い将来これらの機能を取り込みます。そして、ワークスペース間の連携について理解しておけば、より簡単に扱えるようになります。
TFE でワークスペースを作成します。そして VCS リポジトリをワークスペースに割り当てます。各ワークスペースはそれぞれが Terraform のコードをバージョン管理システムから読み込みます。ワークスペースごとにリポジトリとブランチの指定が必要です。
私たちが推奨するのはアプリケーションやサービスの全ての環境で、同じリポジトリとブランチを使うことです。Terraform コードを書くとき、環境の差異を変数で扱えます。また、ワークスペースごとに適切な変数を割り当て可能です。しかし、既存のコードでは実践的ではない場合があります。マージ方針によってはワークスペースごとにブランチを分けている場合もあるからです。しかし、私たちはブランチを１つに集約するモデルがベストだと信じています。
VCS ブランチの変更により、マスタにマージすることで、ワークスペースを通したステージング環境、UAT 環境、完全なプロダクション環境を促します。
皆さんの同僚は、一人一人が TFE ユーザを作成する必用があります。そして組織の導入においては、適切なチームへの追加も可能です。
TFE チームとは、ワークスペースに対する権限を与えられたユーザの一覧です。つまりTFE チームはインフラごとに責任を持っている担当者と一致すべきです。これは、組織図とは一致しない場合もありえますが、組織にわたる人々をどうするかに時間を費やすべきですし、会話すべきです。次の点にご注意ください：
協調的インフラのコード化導入で最も難しい部分が、権限を正確かつ完全に委譲するために、どのように管理するかです。
チームに対してワークスペースの所有権と権限を割り当てます。各ワークスペースは３つのレベルの権限があります。ユーザやチームごとに、admin、read/write、read-onlyを割り当て可能です。Admin は効率的にワークスペースを所有し、対象ワークスペース上のユーザにする権限を変更可能です。
多くのワークスペースは、複数のチームに対して異なる権限を与えられます。
ワークスペース チーム権限
----------------------- ------------------------------------
app1-dev Team-eng-app1: Read/write
Team-owners-app1: Admin
Team-central-IT: Admin
app1-prod Team-eng-app1: Read-only
Team-owners-app1: Read/write
Team-central-IT: Admin
networking-dev Team-eng-networking: Read/write
Team-owners-networking: Admin
Team-central-IT: Admin
networking-prod Team-eng-networking: Read-only
Team-owners-networking: Read/write
Team-central-IT: Admin
クラウド・プロバイダの UI や API によるアクセスを制限します。インフラのプロビジョニングにおいて、Terraform Enterprise は組織における優先インターフェースです。そのため、TFE を経由しない他のあらゆるアクセスを制限すべきです。ほとんど大部分のユーザは、インフラの変更を手動では行えないでしょう。Terraform ワークフローの組織同意に基づかないためです。
誰もが Terraform を経由することで、コードレビューの手順や TFE ワークスペース権限によって、インフラに対して誰が変更を加えたのか明確に記録できます。これにより、インフラの全てを理解しやすく生業可能になるのです。Terraform Enterprise は１つのワークフローを学ぶだけで、１つの安全なワークフローや、そのほか組織における監査可能なプロビジョニングのためのワークフローとなるのです。
この時点で、Terraform Enterprise を使った「協調的インフラのコード化」の導入に成功しました。１つのワークフローを使い、複数のプロバイダを横断するインフラをプロビジョニングできます。そして、共通したインターフェースを通し、皆さんの組織における標準的なアクセス制御やコードのプロモーションなどに役立つでしょう。
次はワークフローと手順の改善を進めましょう。
これでプロビジョニングに対する協調的インターフェースとワークフローを手に入れました。手順をより改善するためには、決まったフレームワークがあります。
以下の提案は、順番に行う必要はありません。そしてビジネスによっては全て実現する必要はないかもしれません。私たちは可能性を示すだけであり、皆さんが次に何をすべきか、自分自身に問うときのご参考になさってください。
更に手順やリソースを TFE に移行します。TFE の導入に成功したら、まだ残っている手動・半自動のワークフローや手順を移行するチャンスです。私たちが提案するのは、インフラの実行維持に責任を持つ全てのチームにより、自動化の将来的な目標を明確にする発見（discovery）ミーティングの開催です。あるいは、セクション２で用いたガイドのメモをもとに、あるいは古い変更リクエストやインシデント・チケットも使えます。
イメージ作成のために HashiCorp Packer の採用。Packer はメンテナンス可能で再利用できるマシンイメージの構築に役立ちます。また Terraform の利便性を倍増できます。
Terraform 設定に Sentinel を適用し、ビジネスとコンプライアンスに準拠するように従います。
TFE のために監査ログを設定します。Terraform Enterprise プライベート・インストールは、デフォルトで CloudWatch にログを送れます。
インフラの監視と性能メトリクスを追加します。これにより、環境のプロモーションが安全になり、アプリケーションのパフォーマンスのセーフガードとなります。多くのツールが利用可能ですが、私たちが推奨するのはインフラ自身の管理と、ユーザ視点でのアプリケーション性能の監視の両方です。
TFE API を使います。TFE API を汎用 CI/CD ツールと連携し、あらゆるイベントを Terraform の実行トリガにできます。