Terraform Associate 004 #8 新範囲集中 — ephemeral、write-only、メタ引数

インフラ Terraform IaC Certification
読了 4分

今回は、004 で新しく入ったか比重が増した項目を 1 か所に集めた、このシリーズの中で 003 時代の資料と最も差が出る回です。幸い、トラックを進めてきた方には全部実習済みの内容です。実践 #6 のシークレット構成と、基礎 #6・#7 のメタ引数がそれで、試験が問う角度に並べ直します。

ephemeral — 記録に残らない値 #

ephemeral(一時的な)値は、plan にも state にも保存されず、実行中にだけ存在する値です。出題ポイントは性質と使える場所です。

  • 性質: 実行のたびに新しく評価され、記録が残らないため、シークレットの扱いに適しています。
  • 使える場所: ephemeral "random_password" のような ephemeral リソース、ephemeral = true を付けた変数・output、そして ephemeral 値を受け取れる場所(write-only 引数、プロバイダー設定など)が対になります。
  • 制約: ephemeral 値は、通常のリソース引数のように state に保存される場所には入れられません。入れるには次の write-only 引数が必要です。この制約が次の節とのつながりであり、試験の連結問題のポイントでもあります。

write-only 引数 — state 平文問題への根本的な対応 #

#5 で「state は平文」という問題を確認し、sensitive は画面を隠すだけだと説明しました。write-only 引数はこの問題への言語レベルの解法です。password_wo のように _wo サフィックスが付いた引数は、値をプロバイダーに渡すだけで、plan にも state にも保存しません。

main.tf 
ephemeral "random_password" "db" {
  length = 24
}

resource "aws_db_instance" "main" {
  # ...
  password_wo         = ephemeral.random_password.db.result
  password_wo_version = 1
}

出題が集中するのは _wo_version が存在する理由です。値が state にないため Terraform は値の変更を検知できず、ローテーションしたいときは値を変えるのではなく、バージョン番号を上げて変更を知らせます。「write-only 値をローテーションする方法は?」の答えが「_wo_version を増やす」です。sensitive(出力のマスキング)→ ephemeral(記録のない値)→ write-only(記録のない受け渡し)という 3 段階の区別を整理しておけば、この領域の比較問題はすべて解けます。

depends_on — いつが正解か #

メタ引数の側に移ります。depends_on 問題の正解の方向は、基礎 #6 の原則そのままです。Terraform は参照から依存関係を自動で推論するため、depends_on は参照で表現されない隠れた依存(IAM ポリシーが付与されて初めて動くリソースなど)にだけ使います。「すべてのリソースに depends_on を明示して順序を確実にする」という選択肢は誤りです。不要な宣言は並列性を下げるだけです。

count vs for_each #

  • count: 整数で複製、count.index を使用、条件 ? 1 : 0 による条件付き作成のイディオム。
  • for_each: マップ・セットで複製、each.key・each.value を使用、リストは toset() が必要。
  • 選択基準: 同一の複製・条件付き作成は count、名前のある集合は for_each。count には途中の要素を削除するとインデックスがずれて意図しない再作成が起きるという引っかけがあり、これが頻出です。

lifecycle の 3 つの引数 — 効果で区別 #

引数効果代表的な用途
create_before_destroy交換の順序を「作ってから消す」に反転無停止の交換、name_prefix とペア
prevent_destroy削除の計画が生まれるとエラーでブロック本番 DB・データリソースの保護
ignore_changes指定した属性の外部変更を plan で無視オートスケーリングが変える desired_capacity

ここに #4 の -replace フラグ(taint コマンドの後継)と # forces replacement の表示(基礎 #7)を束ねれば、交換関連の問題セットが完成します。prevent_destroy の限界(コンソールからの削除は止められず、ブロックを削除すると保護も消える)も、シナリオ問題として出ます。

まとめ #

今回扱った内容です。

  • ephemeral 値は plan・state に残らない実行中専用の値で、state に保存される通常の引数の場所には入れられません
  • write-only 引数は値を渡すだけで記録せず、ローテーションは値の変更ではなく _wo_version の増加でトリガーします
  • sensitive は画面のマスキング、ephemeral は記録のない値、write-only は記録のない受け渡し、という 3 段階の区別が比較問題の軸です
  • depends_on は参照で表現できない隠れた依存にだけ使う例外的な道具です
  • count はインデックスのずれという引っかけ、for_each はキーベースで安全という違いがあり、lifecycle の 3 つの引数は順序の反転・削除のブロック・変更の無視と効果が異なります

次回(#9 HCP Terraform)では、004 で出題範囲が広がったマネージドプラットフォームの領域を扱います。workspace と project、variable set、ポリシーと drift detection です。

X