最終更新日 2019年10月21日
概要
先日の 【参考訳】HashiCorp Terraform 0.10 に続き、数々の変更に伴う説明が書かれている Upgrading to Terraform 0.10 も重要だと思い、参考情報として翻訳しました（8月4日現在）。皆さまのアップグレードの手助けになればと思っています。
Terraform v0.10 へのアップグレード
Terraform v0.10 はメジャー・リリースです。従って、アップグレードにあたっては、検討が必要な複数の変更を伴います。当ガイドは、この検討の手助けとなるのを目指します。
ガイドの目的はアップグレードにあたり、一般的な懸念事項や課題解決に役立つ詳しい説明や背景を扱います。全ての変更項目は Terraform 変更履歴（Changelog） で常に網羅しています。このガイドを読み終えたら、リソースをプロバイダの利用に対して、変更履歴にある各項目の確認をお勧めします。
特にこのガイドでは v0.9 から v0.10 の変更に焦点をあてています。これまでのメジャー・リリースにも、それぞれに更新ガイドがあります。古いバージョンをお使いの場合は、必要に応じて各ガイドを直接ご覧ください。
プロバイダ・プラグインの分離
v0.10 現在、主となる Terraform 配布物（パッケージ）にはプラグインを同梱しません。そのかわり、プラグインは戸別配布となり、 terraform init コマンド で自動的にインストールします。
長期的には、この新しい手法はあらゆる皆さんに役立つでしょう。たとえば、特定のプロバイダをアップグレードして新機能に対応したいけれども、変更によって他プロバイダの互換性問題が心配な場合です。短期的には、配布パッケージが小さくなりますし、全く使わない多くのプロバイダをダウンロードする必要もありません。
また、プロバイダ・プラグインは Terraform 本体とは個別にバージョン管理されます。 バージョン制限（version constraints） を使えば、新しいメジャー・リリース（破壊的な変更を含む可能性）があったとしても特定のバージョンを利用し続けられます。
対策 ：アップグレード後は、必要なプロバイダ・プラグインをインストールするために、各 Terraform 設定ファイルのある作業ディレクトリで terraform init
を実行します。もしも自動処理で Terraform を使っている場合は、バージョン・コントロールから Terraform
設定をクローンした直後の手順として、こちらのコマンド実行が必要です。また、必要なモジュールのインストールが必要だったり、リモート・バックエンドの設定が必要になったりするでしょう。
対策 ：「プロダクション」（本番環境）向けの設定にあたっては、 terraform init の出力で推奨される プロバイダのバージョン指定 の追加をご検討ください。この対策をしておけば、プラグインが将来的にバージョンアップしても、新しいメジャー・バージョンの自動インストールを防げます。
サードパーティ製のプロバイダ・プラグイン
プロバイダ・プラグインを分割しての初リリースで影響を受けるのは、HashiCorp がパッケージ化してリリースしているプロバイダに対してのみです。この方向性は、サードパーティ製プラグインの定期的サポートと似たような手法を目指しています。しかし、このような状態が一般的になる前に、私たちはインストールとバージョン管理の堅牢な仕組みを確保したいのです。
それまでの間、 サードパーティ製プロバイダをインストールする主な仕組み はサポートが続きます。サードパーティ製プロバイダのメンテナは、バイナリの名前による新しいバージョン管理メカニズムをオプションで取り入れることになるでしょう。例えば terraform-provider-名前-v0.0.1 の “0.0.1” にあたる部分を使う枠組みです。Terraform は セマンティックバージョン管理（semantic versioning） 手法をプロバイダが使っているとみなします。
しかしながら、現時点においてはサードパーティ製のプロバイダは自動的にバージョンを指定したインストールができません。 いずれ Terraform 0.10 は設定ファイルを通して指定されたバージョンをインストールするかどうか確認し、もしも指定されたバージョンが使えなければエラーがでるようになります。
対策 ：直ちに対策は不要ですが、サードパーティ製プラグインのメンテナは、利用者が今後のバイナリ配布にあたってバージョン番号を使えるよう、オプションとしての検討を始めたら良いかもしれません。
-target を使った再帰的なモジュール対象
-target 引数で各モジュールの場所を指定すると、（必要な）リソースの全てをターゲット（対象）にできるでしょう。
$ terraform plan -out=tfplan -target=module.example
このコマンドは、 0.10 までは指定したモジュールのリソース のみ を、直接の対象としていました。0.10 では挙動が変わり、コマンドの実行によって、 派生した モジュールも対象リソースとして含みます。
たとえばモジュール自身が module.example であれば、 先ほどのコマンドを実行すると、対象となるリソースは module.example と module.example.module.examplechild の両方です。
また、 リソース割り当て（resource addressing） 構文を使う Terraform の機能も使えます。ここでは terraform state と同じサブコマンドを含みます。
対策 ：Terraform の自動処理で -target を使っている場合は、指定しているリソースに子モジュールがあったとしても、何ら動作上の問題がないのを確認します。 -target を使う場合は plan のレビューにあたり、作業にあたって必要なリソースのみインストールするのを、確実に確認してください。 -target を定常的に使うのは推奨しませんので、どうかご注意ください。これは例外的な利用であり、手動での介入なのです。
terraform apply のインタラクティブな承認
Terraform 0.10 から、plan 時にインタラクティブな確認による一時停止があれば、 terraform apply は新しいモードになり、plan 時に確認した項目のみ適用（apply）します。これは terraform plan を個々に実行可能な利便性を得るためですが、インタラクティブなコマンド入力がワークフローの簡素化に影響を与えてしまいます。
これまでのラッパー・スクリプトが期待通りに動かなくなるのを防止するため、0.10 ではこの機能は無効がデフォルトです。もし、こちらの挙動を使いたい場合は、特定の plan ファイルを指定せずに terraform apply 時に -auto-approve=false を指定します。
Terraform の将来的なバージョンでは、この挙動がデフォルトになるよう計画しています。そのため、ただちに対策は不要ですが、将来的な変更に備え、Terraform の自動化もしくはラッパーを用いている場合は、次の手法による調整を強く推奨します。
- プロダクションのシステムに関わるインタラクティブではない自動処理では、
terraform plan -out=tfplanと、その後の（承認後の）terraform apply tfplanを 常に 分けるべきしょう。これは作業者が適用する（apply）前にレビュー（確認）する機会を設けるためです。 - プロダクション以外 のシステムにおいて、plan ファイルのない自動処理で
terraform applyを実行する場合、-auto-approve=trueをコマンドラインに追加するだけで、現在の 0.10 の挙動である自動承認がデフォルトで有効になります。
私たちは多くのチームがラッパー・スクリプトや自動化で Terraform をご利用されているのを把握しています。そのため、このような変更にあたり、移行期間を設けます。また、各チームには将来的な変更に備え、ツールを更新するための機会を確実に設けていただければと思います。
対策 ：0.10
はデフォルトでは以前の挙動と同じため、今すぐの対策は不要です。しかしながら、Terraform
をラップしているようなツールのメンテナは、自動処理をするか別のコマンドライン UI
を使うかどうかにかかわらず、将来的なバージョンに備えて活用方法や -auto-approve=... フラグを使うかどうかの明確な決定を考慮すべきでしょう。
原文
- Upgrading to Terraform 0.10 – Terraform by HashiCorp