Terraform import blockで生成したHCLを整理する手順

既存リソースをTerraform管理へ取り込むには、import blockで取り込み先と既存リソースのIDを指定し、terraform plan -generate-config-out=generated.tfで設定を生成する。HashiCorpの構成生成手順では、出力先に新しいファイルを指定するよう求めており、既存ファイルを指定するとエラーになる。

生成されたHCLは、取得できた値を基にTerraformが推定したテンプレートだ。引数を整理したうえで通常のplanをやり直し、取り込みと同時に予定される更新、置換、削除を読んでからapplyする。ファイルが生成されたことだけでは、既存リソースを現状のまま取り込めるとは判断できない。

import blockでアドレスとIDを対応させる

最初に、対象を表すresource型と、Terraform内で使うアドレスを決める。import blockの公式リファレンスでは、toを取り込み先のリソースアドレス、idをプロバイダー側の識別子としている。idに使う値の形式はリソース型ごとに異なるため、対象のプロバイダーのimport仕様と現物の識別子を照らし合わせる。

仮にAWS IoTの既存Thingを取り込むなら、import blockの中でto = aws_iot_thing.bar、id = "foo"のように対応を指定する。fooは説明用の値であり、実際には対象の識別子へ置き換える。後で残すresourceブロックもaws_iot_thing.barという同じアドレスに置き、別のアドレスですでに同じ実物を管理していないか、設定とstateを確認する。

複数のリソースを取り込む場合は、それぞれのtoとidの組を先に確定する。planに表示された取り込み先を現物と照合しやすくなり、似た名前の資源を取り違える危険を減らせる。生成に使うプロバイダーをTerraformが判定できない場合は設定を追加し、プロバイダー設定を新たに加えた後はterraform initを実行する。

planで新しいファイルに設定を生成する

取り込み先のresourceブロックをまだ書いていない状態で、terraform plan -generate-config-out=generated.tfを実行する。Terraformはimport blockの対象についてplanを作り、生成したresourceブロックを指定先へ書き出す。すでに設定にresourceブロックがある対象については、この方法で新しいブロックを生成する必要はない。

generated.tfには、実行前に読むべき情報が二つある。生成された引数の内容と、その内容を使った場合にplanが予定する操作だ。出力先のファイルが存在していた場合は、別の新しいファイル名を選ぶ。生成後に設定を直して確認するときは、生成オプションを外した通常のterraform planを使う。

生成中に引数の衝突が見つかっても、ファイルが残る場合がある。たとえば一緒に指定できない引数が生成されたなら、エラーに示された箇所を確認し、どちらを設定として残すかを判断する。ファイルが書き出されたという事実だけを成功の印とせず、引数を修正してplanが通る状態まで進める。

生成HCLを保守できる設定へ直す

生成されたresourceブロックには、既定値と同じ値や、値のない引数まで並ぶことがある。まず必須の引数と、現物の状態を維持するために明示すべき値を残し、それ以外を一つずつ検討する。ただし、行数を減らすこと自体を目的にしない。引数を省いた結果、プロバイダーの既定値が適用されて現物との差分が生じるなら、その値には意味がある。

次に、固定文字列の出所を見直す。他のTerraformリソースを指す値なら参照へ、環境ごとに変える値なら入力変数へ移す選択肢がある。生成処理は、取得した値を基に設定を推定できても、その値を選んだ運用上の理由や資源間の関係までは決められない。参照へ置き換える際も、指し先が実際の依存関係と一致するか確かめる。

整理したresourceブロックは既存の設定ファイルへ移してもよい。その場合、元の生成ファイルと移動先の両方に同じアドレスのブロックを残さない。生成ファイルをそのまま管理用のファイルとして使う場合も、レビュー後の引数だけを残す。どちらの配置でも、次のplanが読むHCLを一つに定めることが重要だ。

再planでは取り込み以外の差分まで読む

編集後は-generate-config-outを付けずにterraform planを実行する。toのアドレスとidが目的の実物に対応しているかに加え、取り込み対象に更新や置換が予定されていないかを見る。既存の設定も同じplanで評価されるため、対象以外の作成や削除も読み飛ばさない。

HashiCorpのインポート演習では、生成されたDockerコンテナの設定にあるenvの値によって、取り込み後の置換が最初のplanに現れる。演習はenvを修正して再planし、その置換を解消している。この修正値を別のリソースへ流用するのではなく、自分の対象で置換を要求している引数とプロバイダーの仕様を確認する。

置換や削除が予定されているなら、取り込みを進める前に原因となる設定を直す。更新についても、表示されたというだけで安全とは判断できない。演習のようにstate内の既定値を反映する変更と、稼働中の資源そのものを変える操作では影響が異なる。最初の取り込みで現物を維持したいなら、各差分が何を変更するかを把握できるまで再planを重ねる。

planはその時点の設定と現物から作られる実行予定だ。HCLを編集した後や現物に変更があった後は、以前の表示を判断材料にせず、改めてplanを読む。取り込みと別の変更を同時に実行する意図がない場合は、余分な操作を設定から取り除いてからapplyへ進む。