ひとりの state から、チームの state へ

何も設定しないと、Terraform は local バックエンドを使い、作業しているディレクトリの terraform.tfstate に state を書きます。ひとりなら困りませんが、チームでは困ります。ほかの人は最新の state を見られず、同じものを二重に作ったり、古い state で上書きしたりします。state には機密の値も平文で入るので、ファイルを配り回すのも危険です。

backend ブロックで置き場所を決める

• terraform ブロックの中に backend ブロックを1つ書く（S3・GCS・azurerm など、種類ごとに設定が違う）
• backend ブロックの中では、変数やローカル値を参照できない。環境ごとに変えたい値は、init の -backend-config で渡す
• 置き場所を変えたら terraform init をやり直す。いまの state を新しい置き場所へ移すかどうかも、init が扱う

ロック

state を書き換える操作の前に、Terraform はロックを取ります。ロックが取れなければ先に進みません。これで、2人が同時に apply して state を壊すことを防ぎます。S3 バックエンドでは use_lockfile = true でロックを有効にし、state の横に .tflock のファイルを置きます。以前の DynamoDB によるロックは非推奨です。

force-unlock

処理が途中で落ちてロックが残ったときだけ、terraform force-unlock にロックの ID を付けて外します。インフラは変えませんが、誰かが実行中のロックを外すと state が壊れるので、最後の手段です。

• local バックエンドの限界と、リモートに置く理由
• backend ブロックの書き方と、init のやり直し
• state のロックの仕組みと S3 の use_lockfile
• force-unlock を使ってよい場面