Terraform Associate 004 #5 state 管理 — バックエンド、ロック、state コマンド、機密情報

インフラ Terraform IaC Certification
読了 4分

state は Associate 試験で最も比重の大きい軸の 1 つです。基礎 #5、#9、運用 #2で実習として固めた内容を、試験が問う形、つまり「このコマンドは何を変えるのか」「この状況での正しい対応はどれか」という角度で並べ直します。

state の目的と位置 #

試験が期待する定義から始めます。state は設定のリソースと実際のインフラオブジェクトのマッピングであり、plan が差分を計算するための根拠、そしてリソース間の依存関係と属性値の記録です。デフォルトの動作では作業ディレクトリの terraform.tfstate ファイル(ローカルバックエンド)に保存され、バックエンド設定でリモートの保存先に置けます。「state なしで Terraform は動作する」という趣旨の選択肢は誤答です。state がなければ、Terraform は何を管理しているのか分かりません。

ローカル vs リモートバックエンド #

リモートバックエンド(S3、HCP Terraform など)が解決する 3 つの問題は、基礎 #9がそのまま試験ポイントです。

  1. チーム共有: 全員が同じ state を見ます。
  2. ロック(locking): 同時実行が state を壊す事故を防ぎます。バックエンドがロックに対応している場合、plan と apply が自動でロックを取るため、別のコマンドは必要ありません。
  3. 保管の安定性: ローカルディスクの紛失、削除のリスクから離れられます。

ロック関連の定番問題は 2 つです。「ロックエラーが出たらどうするか」の第一の答えは待つ(別の実行が進行中という正常なシグナル)であり、force-unlock は実行中の主体がいないことを確認した後の最後の手段です。そして force-unlock はロックを解除するだけで state の内容を変えないという性質も区別ポイントです。

state コマンド — 何を変えて何を残すのか #

コマンドすること実際のインフラへの影響
state list管理中のリソースアドレスの一覧なし(読み取り)
state show アドレス1 つのリソースの属性を出力なし(読み取り)
state mv A Bstate 内でアドレスを変更なし(記録が移動するだけ)
state rm アドレスstate から削除(管理の放棄)なし(リソースは残る)

試験が狙うのは右の列です。state rm はリソースを削除せず、Terraform の管理から外すだけです。削除は destroy(またはコードからブロックを消して apply)の仕事です。state mv はリファクタリングで名前やモジュールを移動するときに再作成を防ぐ道具で、その宣言形の対である moved ブロック(実践 #9)、state rm の対である removed ブロック、既存リソースを取り込む import ブロック(運用 #2)まで、命令形と宣言形の対応をまとめて覚えれば、関連問題のすべてに対応できます。

命令形と宣言形の対応 
命令形               宣言形(コード、レビュー可能)
terraform import  →  import ブロック
state mv          →  moved ブロック
state rm          →  removed ブロック

refresh — 今は plan の一部 #

古い試験対策資料に出てくる terraform refresh 単独のコマンドは廃止の方向で、現行の答えは、plan と apply が実行時に自動で refresh を行うこと、そしてずれだけを点検したいときは plan -refresh-only を使うこと(#4で整理したあのオプション)です。ドリフトの概念とセットで出題されます。

state の中の機密情報 #

state には管理リソースのすべての属性が平文で保存されます。sensitive の指定は画面出力を隠すだけで state の中身は隠さないこと(基礎 #5で直接確認した事実)が、そのまま出題されます。したがって正答方向の記述は次のとおりです。

  • state ファイルをバージョン管理にコミットしない
  • リモートバックエンドに置き、保存時の暗号化とアクセス制御を適用する
  • state へのアクセス権限自体をシークレットへのアクセス権限として扱う

そして 004 の新しい軸である write-only 引数が「値が state にそもそも保存されない」というより根本的な対応だという接続まで続きますが、その詳細は #8 で扱います。

まとめ #

今回扱った内容です。

  • state は設定と実際のインフラのマッピングであり、plan の根拠です。デフォルトの位置はローカルの terraform.tfstate で、バックエンドでリモート化します
  • リモートバックエンドの価値は共有、自動ロック、保管の安定性です。ロックエラーの第一の答えは待機で、force-unlock は最後の手段であり state の内容には触れません
  • state mv と rm は実際のインフラを変えません。rm は削除ではなく管理からの除外です
  • import、mv、rm の宣言形の対が import、moved、removed ブロックです
  • refresh は plan に組み込まれ、点検は -refresh-only です。state は平文なのでコミット禁止、暗号化、アクセス制御が正答方向で、根本的な対応である write-only は #8 に続きます

次回(#6 モジュール)では、モジュールのソース指定とバージョン、入出力の文法という、短いながら問題密度の高い領域を整理します。

X