#Terraform

48 件の記事

Terraform 依存関係エラーの総整理 — Cycle、depends_on の誤用、known after apply
読了 5分

Terraform 依存関係エラーの総整理 — Cycle、depends_on の誤用、known after apply

Terraform の依存グラフから出てくる 3 つの問題をまとめて整理します。Error: Cycle の代表例であるセキュリティグループの相互参照を分離リソースで断ち切る方法と terraform graph による診断、暗黙の依存が基本で depends_on は隠れた依存にだけ使うべき理由と乱用の副作用、count と for_each のキーに計算前の値が入って出る Invalid count argument の解決法まで扱います。

tfstate にシークレットが平文で保存されたとき — キーのローテーションと再発防止
読了 5分

tfstate にシークレットが平文で保存されたとき — キーのローテーションと再発防止

tfstate が sensitive の指定と無関係に値を平文で持つ構造から整理します。露出範囲を判断する順序、state の整理よりキーのローテーションが先である理由、git に state がコミットされていた場合の履歴整理、そして再発防止としての ephemeral リソースと write-only 引数、S3 バックエンドの暗号化とアクセス統制、シークレットをそもそも state に残さない設計まで扱います。

terraform plan が遅いとき — refresh の負荷、並列度、スタック分割の合図
読了 4分

terraform plan が遅いとき — refresh の負荷、並列度、スタック分割の合図

plan の所要時間の本体が差分計算ではなく、リソースごとに API を読む refresh だという事実から整理します。リソース数と API 往復が時間を決める構造、-refresh=false を使ってよい局面といけない局面、parallelism の調整を rate limit を見ながら実測で決めるべき理由、-target が性能の道具ではない理由、そして根本対策であるスタック分割に移るべき合図まで扱います。

AWS provider 6.x アップグレード — breaking change の診断と安全な移行順序
読了 5分

AWS provider 6.x アップグレード — breaking change の診断と安全な移行順序

AWS provider のメジャーアップグレードを安全に越える手順を整理します。CLI アップグレードより影響が大きい理由、最新の 5.x を経由して deprecation 警告を消化する標準手順、6.0 の主要変更(リソース単位の region 引数、OpsWorks・SimpleDB の削除、ブーリアンの厳格化、Redshift デフォルトの反転)、スキーマ変更が作る見かけの差分と本物の置き換えを区別する plan の読み方、共有モジュールのバージョン下限が作る落とし穴まで扱います。

Terraform バージョンアップグレードの手順 — 互換性の約束、no-op 検証、ロールバック備え
読了 5分

Terraform バージョンアップグレードの手順 — 互換性の約束、no-op 検証、ロールバック備え

Terraform CLI のバージョンを上げる安全な手順を整理します。1.x の範囲では構成とワークフローの互換が維持されるという互換性の約束、CLI のアップグレードと provider のアップグレードを分けるべき理由、アップグレード前後で変更なしの plan を確認する検証法、新バージョンが書いた state を旧バージョンが読めないことがあるため必要なロールバックの備え、tfenv と mise によるチーム・CI のバージョン統一まで扱います。

terraform destroy が失敗するとき — DependencyViolation と消えないリソース
読了 5分

terraform destroy が失敗するとき — DependencyViolation と消えないリソース

destroy 失敗の 3 つの枝を区別して整理します。Terraform の外で作られたリソースが掴んでいて出る DependencyViolation の診断手順、空になっていない S3 バケットと force_destroy を有効にしてから先に apply が必要な理由、prevent_destroy や deletion_protection のようにわざと掛けた安全装置の正しい解除手順、削除が遅いリソースのタイムアウト、部分 destroy 後の残存物の整理まで扱います。

terraform plan は成功したのに apply が失敗するとき — 原因と部分適用の復旧
読了 5分

terraform plan は成功したのに apply が失敗するとき — 原因と部分適用の復旧

plan が通ったのに apply が失敗する理由を構造から整理します。plan はスキーマと参照だけを検証し、実際の API 検証は apply で初めて起きるという非対称、権限不足と IAM 伝播遅延、サービスクォータ、グローバルな名前衝突といった典型原因 5 つ、apply がトランザクションではないために生まれる部分適用状態を安全に復旧する手順、already exists エラーが出たときの import 判断まで扱います。

Terraform Associate 004 #10 模擬試験 — 全範囲 50 問 + 解説
読了 20分

Terraform Associate 004 #10 模擬試験 — 全範囲 50 問 + 解説

シリーズ 9 本の範囲全体から出題する 4 択 50 問の模擬試験です。IaC の概念からワークフロー、state、モジュール、設定の記述、004 の新規範囲である ephemeral と write-only、HCP Terraform まで領域別に配置し、各問題に正解の根拠と誤答の罠を解説として付けました。採点後に弱い領域を該当回に戻って整理する、仕上げの確認用です。

Terraform Associate 004 #9 HCP Terraform — workspace、variable set、ポリシー、drift detection
読了 5分

Terraform Associate 004 #9 HCP Terraform — workspace、variable set、ポリシー、drift detection

HCP Terraform の workspace が CLI のワークスペースと名前だけ同じ別概念であることから始めて、project で workspace を束ねる構造と、実行方式 3 つ(VCS・CLI・API 連携)を整理します。variable set で複数の workspace に値を供給する方法、Sentinel・OPA ポリシーの適用ポイントと hard・soft の失敗区分、常時の drift detection、そして Terraform Enterprise との関係まで、004 で広がった出題範囲を固めます。

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

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

004 の看板となる新範囲を 1 本にまとめます。plan と state に残らない ephemeral 値の性質と使える場所、write-only 引数がシークレット問題を解く仕組みと _wo_version でローテーションをトリガーする理由を整理し、depends_on の正当な用途、count と for_each の選択、lifecycle の 3 つの引数(create_before_destroy・prevent_destroy・ignore_changes)の効果の区別まで、メタ引数全般を試験の観点で固めます。

Terraform Associate 004 #7 設定の作成 — 変数の優先順位、関数、カスタム条件
読了 5分

Terraform Associate 004 #7 設定の作成 — 変数の優先順位、関数、カスタム条件

変数の型と値の入力元の優先順位、sensitive の効力範囲、output と locals の役割を試験の観点で圧縮し、頻出の組み込み関数と式を整理します。004 で強化されたカスタム条件である変数の validation、リソースの precondition・postcondition、check ブロックの区別と評価タイミングまで、トラックで浅く扱った部分を補強します。

Terraform Associate 004 #6 モジュール — ソース指定、バージョン固定、入出力の文法
読了 4分

Terraform Associate 004 #6 モジュール — ソース指定、バージョン固定、入出力の文法

モジュールの定義とルート、子モジュールの区別から、レジストリ、Git、ローカルパスというソース指定方式ごとの文法と version 引数が動作する条件を試験の観点で整理します。モジュールに値を渡す入力と module.名前.出力 の形で受け取る出力の文法、モジュール内のリソースには直接アクセスできないというカプセル化の原則、パブリックレジストリの verified 表示まで、出題ポイントを固めます。