Terraform Linux

この記事のポイント

・terraform backend localはCI環境でステートが毎回リセットされリソース重複作成が起きる
・ローカルファイルロックは別マシン・別コンテナには効かず並行apply時にstate競合が発生する
・AWS環境ならS3＋DynamoDB組み合わせが最小構成のリモートバックエンド定番
・localが許容できるのは個人学習・使い捨て試験環境のみ。チーム利用・CI導入時は即切替が必要

この記事のポイント

・ALBはaws_lb・aws_lb_target_group・aws_lb_listenerの3リソースで構成される
・HTTP→HTTPSリダイレクトはaws_lb_listenerのredirectアクションで1本宣言できる
・ヘルスチェックのthreshold値を絞りすぎると正常インスタンスが外れ続ける
・path-basedルーティングはaws_lb_listener_ruleのpriority順で評価される

この記事のポイント

・aws_acm_certificate_validationは証明書リソースとRoute 53 CNAMEレコード両方に依存する
・for_eachでdomain_validation_optionsを展開すると検証レコードを自動生成できる
・CloudFront用証明書はprovider = aws.us_east_1のalias設計が必須
・DNS検証がタイムアウトするときはRoute 53ゾーンのNameserver一致を最初に疑う

この記事のポイント

・TerraformはtfstateをS3等に保管し自分で管理するが、CloudFormationはAWSがStack状態を管理する
・HCL（Terraform）はYAML/JSON（CloudFormation）より変数・ループ・モジュール化が読みやすく書きやすい
・マルチクラウド（AWS＋Azure＋GCP）を扱う場合はTerraform一択、AWSのみならCloudFormationも有力な選択肢
・Terraformのapply失敗は手動ロールバックが必要だが、CloudFormationはStack単位の自動ロールバックが標準機能

この記事のポイント

・MinIOのS3互換バックエンドにはforce_path_styleとskip系3オプションの設定が必須
・regionはMinIOが使わない値でも us-east-1 のようなダミー文字列の指定が必要
・最小権限は GetObject・PutObject・DeleteObject・ListBucket・GetBucketVersioning の5権限
・Terraform 1.10以降は use_lockfile=true でDynamoDB不要のstateロックが使える

この記事のポイント

・name/hash_key/range_key変更はforces replacement（テーブル再作成・データ消失）
・GSI追加・TTL有効化・Streams変更はインプレース更新で通る
・GSIのhash_key/range_keyを変え直すときは2ステップapplyで置換を回避する
・terraform planの「forces replacement」を必ず確認してからapplyする

╭
│ Error: Backend configuration changed
│
│ A change in the backend configuration has been detected, which may require
│ migrating existing state.
│
│ If you wish to attempt automatic migration of the state, use "terraform init -migrate-state".
│ If you wish to store the prior configuration, use "terraform init -reconfigure".
╰

この記事のポイント

・「Backend configuration changed」は.terraform/terraform.tfstateとの設定差分が原因
・本番インフラを管理中なら-migrate-stateが原則（stateを新backendへ移行する）
・-reconfigureはstateを移行せず再初期化するため、本番環境での乱用は危険
・シナリオ（ローカル→S3移行、バケット名変更等）ごとに正しい手順が異なる

この記事のポイント

・requesterはaws_vpc_peering_connection・accepterはaws_vpc_peering_connection_accepterが担当
・auto_acceptは同一アカウント内のみ有効・別アカウントでは必ずaccepterリソースを記述する
・別アカウント構成はprovider aliasを2つ用意し・requester apply後にaccepter applyの順序が必要
・ルートテーブル更新はaccepterリソースへのdepends_onを明示し・順序崩れを防ぐ

この記事のポイント

・backendブロックはterraform init時にしか評価されない（planでは読まれない）
・backendブロックで変数は使えない。-backend-configで外から渡す
・s3はbucket/key/region、gcsはbucket、httpはaddressが必須キー
・認証情報はbackendに書かず環境変数かIAMロールで渡すのが標準

この記事のポイント

・ 子ゾーンのname_servers属性をそのまま親ゾーンのNSレコードのrecordsに渡せる
・ NSレコードはtype="NS"＋records=aws_route53_zone.子.name_serversで書く
・ IAMポリシーはARNにゾーンIDを含めてゾーン単位で権限を絞れる
・ 委任後はdigコマンドで親ゾーンのNSサーバーに直接問い合わせて確認する

この記事のポイント

・use_lockfileはTerraform v1.11でGA。.tflockファイルをS3条件付き書き込みで管理する
・dynamodb_table引数はdeprecated。移行期間中は両設定の同時有効化が可能
・移行はIAM権限追加→use_lockfile追加→動作確認→dynamodb_table削除の4段階で進める
・ロック競合は terraform force-unlock コマンドで解除できる

この記事のポイント

・Interface型エンドポイントはsubnet_ids・security_group_ids・private_dns_enabledの3点セットが必須
・for_eachでlocalsのサービスマップを回すとDRYな一括定義が実現できる
・マルチAZにサブネットを分散するだけでエンドポイントもHA構成になる
・private_dns_enabledにはVPCのenable_dns_hostnames/supportが有効である前提条件がある

この記事のポイント

・-backend-config fileはinit時に部分設定ファイルでbackendの向き先を切り替える仕組み
・backend.tfはtype宣言のみの空定義、バケット名等の実値は環境別.hclに分離する
・TF_CLI_ARGS_initで-backend-configを環境変数化するとCIパイプラインと連携しやすい
・initを再実行する時は-reconfigureを付けないと前回のbackend情報が残り失敗する

この記事のポイント

・ aliasレコードはHCLでalias {}ブロックで書く。CNAMEとは構文が全く異なる
・ ALBをRoute 53で向ける場合はaliasが正解（apexドメインでも使えてTTL不要）
・ apexドメイン（example.com）にCNAMEは書けない。HCLでのエラー回避に重要
・ zone_idの混同（Route 53のIDとALBのzone_idは別物）がよくあるトラブルの原因

この記事のポイント

・TerraformのbackendにはHCL変数が使えないため、環境差分が重複しやすい
・Terragruntのincludeブロックで親設定を継承し、backend設定を1箇所に集約できる
・dependencyブロックでVPC→EC2のようなモジュール間outputを安全に参照できる
・run-allコマンドで依存グラフを自動解決しながら複数モジュールを一括実行できる

この記事のポイント

・terraform plan -refresh-onlyはstateと実インフラの乖離（ドリフト）だけを表示するサブモード
・ドリフト修正には「コードで上書き・stateを現実に合わせる・ignore_changesで許容」の3戦略がある
・CI/CDに週次のrefresh-onlyジョブを組み込むことで早期発見できる設計を紹介
・lifecycle ignore_changesは「意図的に許容するドリフト」を宣言する正しい設計手段

この記事のポイント

・google providerの認証はService Accountキーファイルで行う
・VPCはAWSと違いリージョンを持たず、サブネットがリージョン単位になる
・Compute Engineはゾーン指定が必須でrequired_providers設定と一緒に確認する
・APIの有効化忘れと権限不足が最頻出エラーの2大原因

この記事のポイント

・mergeで共通タグと個別タグを合成すると重複コードが消える
・templatefile・jsonencode でuser_data・IAMポリシーをHCL構文で書ける
・tryとcanで存在しない属性を安全に参照してモジュールを柔軟にできる
・terraform console で関数をその場で対話検証できる

この記事のポイント

・TerraformでWAF v2をALBに適用するにはaws_wafv2_web_aclとaws_wafv2_web_acl_associationを使う
・マネージドルール（AWSManagedRulesCommonRuleSet等）はoveride_actionで有効・無効を切り替えられる
・IPブロック・レートリミットのカスタムルールはstatementブロックで宣言的に記述できる
・CloudWatch Logsへのログ出力はaws_wafv2_web_acl_logging_configurationで設定する

この記事のポイント

・aws_eks_clusterとnode groupリソースで最小構成EKSを作れる
・Pod IdentityはIRSAの後継でOIDC設定が不要になる
・EKS add-onはaws_eks_addonでバージョン固定できる
・managed node group vs Fargate profileの設計判断基準も解説

この記事のポイント

・OAI（旧）ではなくOAC（Origin Access Control）でS3を保護するのが現在の推奨設計
・S3バケットはパブリックアクセスを全ブロックし、OACからのGetObjectのみをバケットポリシーで許可する
・CloudFrontのviewer_protocol_policy = "redirect-to-https"でHTTPSへの強制リダイレクトを設定できる
・ACM証明書はCloudFrontのグローバル要件によりus-east-1リージョンで作成する必要がある

この記事のポイント

・OpenTofu は Terraform 1.5 のオープンソースフォーク・CLI は tofu コマンドで置き換わる
・HCL 構文・プロバイダー・state ファイルはほぼ完全に互換で既存コードの変更は不要
・移行は tofu init → tofu plan の 2 ステップで動作確認できる
・Terraform Cloud 非依存なら移行コストは低く・判断は「社内ポリシー」「将来リスク」で決まる

この記事のポイント

・aws_lambda_function + aws_iam_role + aws_cloudwatch_log_group を3点セットで定義するのが基本
・source_code_hashでコード変更を検出し、差分があるときだけ再デプロイを走らせる
・LambdaのIAMロールはAWSLambdaBasicExecutionRoleを起点に最小権限で追加する
・ログ保持期間をTerraformで強制管理しないと無制限になり請求が膨らむ

この記事のポイント

・aws_db_instanceの前にサブネットグループとセキュリティグループの定義が必要
・aws_db_parameter_groupで文字コード・タイムゾーン・スロークエリをコードで管理できる
・本番環境ではdeletion_protection=trueとskip_final_snapshot=falseを必ず設定する
・storage_encrypted=trueはインスタンス作成後に変更できないため最初から有効にする
・iam_database_authentication_enabled=trueでパスワード不要のIAM認証接続が実現できる
・lifecycleブロックでパラメータグループの無停止差し替えとエンジンバージョンのdrift防止を両立できる
・apply後はterraform outputとAWS CLIでRDSエンドポイントと稼働状態を必ず確認する

この記事のポイント

・terraform console でHCL式をplan不要で対話確認できる
・var.変数名・local値・data sourceも console で参照可能
・cidrsubnet・jsonencode・formatlist等の関数をその場で試せる
・for式・条件式のデバッグに console は特に効果的

この記事のポイント

・data sourceはリソースを作らず既存の属性値をTerraformコードへ動的に取り込む仕組み
・aws_amiでmost_recent=trueとfilterを組み合わせると常に最新AMIを自動参照できる
・aws_vpc・aws_subnetsで既存VPCのサブネットIDを一覧取得しEC2やALBへ渡せる
・aws_route53_zoneでゾーン名からIDを動的取得すればRoute 53レコード追加にハードコードが不要になる

この記事のポイント

・preconditionはapply前に入力値を検証し、失敗するとapplyをブロックできる
・postconditionはリソース作成後の状態をselfで参照して確認できる
・checkブロックは非ブロッキングで継続的なインフラ整合性チェックができる
・3機能を組み合わせると入力→作成→状態の3段階バリデーションが実現できる

この記事のポイント

・terraform apply -targetは「緊急避難のオプション」であり通常運用向けではない
・乱用するとtfstateの整合性が崩れ、次の全体applyで予期しない変更が発生する
・正当な用途は「壊れたリソースのピンポイント再作成」「ドリフトした単一リソースの修正」の2つ
・-targetに頼る設計はモジュール分割やdepends_onで根本解決できる

この記事のポイント

・provider aliasで複数AWSアカウントへのproviderを1つのコードで定義できる
・assume_roleブロックにrole_arnを指定するだけでクロスアカウント認証が切り替わる
・リソース定義でprovider = aws.devのように明示すると作成先アカウントを固定できる
・本番/開発で構成差が大きい場合はディレクトリ分割のほうが安全

この記事のポイント

・null_resourceはTerraform 0.x時代の回避策、terraform_dataが現代の正解
・local-execは「Terraformで管理できないもの」に限定して使う
・スクリプト実行はnull_resource/terraform_dataではなくAnsible等に委ねるのが設計上正しい
・triggers_replace引数の正しい使い方を理解すれば意図しない再実行は防げる

この記事のポイント

・aws_iam_policy_documentはIAMポリシーJSONをHCLで書くためのdata sourceで、コードレビューが可能になる
・statementブロックにactions/resources/effectを明示し、最小権限を宣言的に設計できる
・Conditionブロックを使うとIPアドレス制限やMFA必須などの細かい権限制御ができる
・tfstateにIAMアクセスキーが入るリスクに注意し、IAMロール設計を優先する

この記事のポイント

・HCL参照式（aws_vpc.main.id など）を書くだけで暗黙依存が自動生成される
・depends_onは暗黙依存が捕捉できない副作用依存にのみ使う最後の手段
・terraform graph | dot -Tpng で依存関係グラフを画像として確認できる
・depends_onの過剰使用は計画精度を下げるため最小限にとどめる

この記事のポイント

・moved ブロックは state mv の宣言型代替で VCS 管理・PR レビューが可能
・removed ブロックの destroy=false でインフラを残したまま state 除外できる
・plan 実行時に「Moved」表示で事前確認できるため誤操作リスクがほぼゼロ
・Terraform 1.1 以降で moved、1.7 以降で removed が利用可能

この記事のポイント

・terraform testはTerraform 1.6から正式搭載されたネイティブテスト機能
・.tftest.hclにrunブロックとassertを書くだけでモジュール検証ができる
・tflintの静的解析とterraform testの動的テストは役割が異なる二軸
・GitHub Actionsへの組み込みでリグレッションを自動防止できる

この記事のポイント

・sensitive = true はログ隠蔽のみ。tfstateには平文でシークレットが残る
・SSM Parameter Store（SecureString）でシークレットをコード外で管理する
・outputにsensitive指定を忘れるとCI/CDログに平文が流れる
・リモートバックエンドのSSE-KMS暗号化が最低限の対策

この記事のポイント

・tflint / terraform fmt / validateは「規約違反・構文・書式」をそれぞれ担当する
・実行順序はfmt → validate → tflintの順が鉄則
・pre-commitフックに登録するとコミット前にチェックが自動実行される
・GitHub Actionsに組み込むとPRレビュー時にチェック結果が可視化される

この記事のポイント

・user_dataでEC2起動時にcloud-init処理を実行するのがprovisionerより安全な設計
・HCLのheredocまたはtemplatefile()で外部cloud-config YAMLを渡せる
・変更を反映するにはEC2の再作成（replace）が必要な点に注意する
・実行結果は /var/log/cloud-init-output.log で確認できる

この記事のポイント

・terraform registry モジュールはsource + versionでバージョンを固定して使う
・terraform-aws-modulesはAWS公式支援・Star数1万超の実績ある公開モジュール群
・メンテ活性度・Issue対応速度・バージョン更新頻度の3点で本番採用を判断する
・variablesで吸収できないカスタマイズが出た時点で自作モジュールへの移行を検討する

この記事のポイント

・単一main.tfはリソースが増えると「全リソースplan」「環境コピー増殖」で必ず破綻する
・environments分割型はdev/stg/prodをディレクトリで分離しtfstateも環境ごとに独立させる
・modules/共通化の基準は「2環境以上で同じ構成を使うリソース群」を抽出することだけ
・tfstateのS3バックエンドはenvironments/dev・stg・prodで必ずkeyパスを分ける

この記事のポイント

・workspaceはtfstateを分離し、-var-fileはパラメータを分離する役割を担う
・2つを組み合わせることで1セットのHCLで3環境を安全に管理できる
・S3バックエンド使用時はworkspaceごとにtfstateのパスが自動で分かれる
・「workspace selectを忘れたまま apply」が最多事故パターンで対策が必要

この記事のポイント

・terraform importでAWSコンソール作成済みリソースをIaC管理下に移せる
・Terraform 1.5以降のimportブロックはPRレビュー可能な宣言的方式で推奨
・state mv/rmとは軸が異なる——実インフラを「取り込む」操作がimportの本質
・よくある失敗はIDフォーマット不一致とplan差分の修正漏れの2パターン

この記事のポイント

・terraform_remote_stateで別tfstateのoutputを参照できる
・backendブロックのS3設定で参照先のstateを指定する
・outputにsensitive=trueで機密情報を安全に渡せる
・設計の鉄則は「一方向参照のみ」で循環参照は禁止

この記事のポイント

・dynamic blockはresource内のネストブロックをリストや集合から動的に生成するHCL構文
・for_each + content{} の組み合わせが基本形。iterator引数で参照名を変更できる
・セキュリティグループのingress・EBSボリューム・DynamoDB GSIが代表的な実務ユースケース
・ネストしたdynamic blockで「typeに応じてブロックを切り替える」条件分岐パターンも実現できる

この記事のポイント

・TF_LOG=DEBUG 設定だけでAPIレベルのエラー原因を特定できる
・DynamoDB Stateロック詰まりはforce-unlockコマンドで安全に解除できる
・terraform plan -refresh-only でドリフトを診断し、インフラは変更しない
・ドリフト解消は「コード修正・インフラ修正・terraform import」の3択で判断する
・CI/CDに -detailed-exitcode を組み込めばドリフトをexit codeで自動判定できる

この記事のポイント

・terraform state listで管理中リソースのアドレス一覧を確認できる
・terraform state mvはdestroyなしでリソースを移動・リネームできる
・terraform state rmは実インフラを削除せず管理対象から外すだけ
・操作前のterraform state pullによるバックアップが安全運用の絶対条件

この記事のポイント

・PR作成時にterraform planを自動実行しPRコメントでレビュアーが差分を確認できる
・GitHub Environmentsで本番applyに承認フローを挟み誤操作と手動実行を防ぐ
・OIDCを使いアクセスキー不要でAWSへ安全に認証する設定方法を解説
・workflow_dispatchで緊急時の手動applyも承認フロー経由で安全に制御する
・if: failure()でapply失敗時のSlack通知を組み込みパイプライン障害を見逃さない
・initの失敗・OIDC認証エラー・stateロック残留など現場で起きるエラーの対処法

この記事のポイント

・required_providers でプロバイダーのsource・バージョン制約を必ず明示するのが基本
・~> 演算子でメジャーバージョンを固定しつつセキュリティパッチを自動取り込みできる
・terraform.lock.hcl は必ずGitにコミットしてチーム全体の環境を固定する
・provider alias で複数リージョン・クロスアカウント構成を1コードベースで扱える

この記事のポイント

・prevent_destroy = true で誤ったdestroy/replace操作をエラーでブロックできる
・create_before_destroyでALB・セキュリティグループのゼロダウンタイム置換を実現する
・ignore_changesでコンソール手動変更によるドリフトを安全に吸収できる
・RDSにはDeletion Protectionとの二重防護でより確実に誤削除を防げる

この記事のポイント

・variable{}で入力値を外部化し、terraform.tfvarsで環境ごとに安全に切り替えられる
・locals{}は繰り返し使う式や計算結果を1箇所にまとめてDRYにするための要素
・output{}はモジュールから外部へ値を公開し、モジュール間の疎結合を保つ
・data{}ソースは「Terraformで作っていない既存リソース」をコードから参照するための機能
・precondition・postconditionはvariable validationで届かない実行時コンテキスト条件を多段で検証する

この記事のポイント

・TerraformはインフラのプロビジョニングにAnsibleは設定管理に向く
・「宣言型」と「手続き型」の設計思想の違いが選定の核心になる
・現場では両ツールを役割分担させて併用するのが主流
・null_resource＋local-execでAnsibleを呼ぶのは避けるべきアンチパターン

この記事のポイント

・tfstateはTerraformがインフラの「現在の状態」を記録するJSONファイル
・S3バックエンド設定でtfstateをチーム共有・バージョン管理できる
・DynamoDB State Lockingで同時実行によるstate破損を防ぐ
・state破損・ロック残留はterraform force-unlockで対処できる
・チームが拡大したらTerraform Cloud（HCP Terraform）への移行も選択肢に

この記事のポイント

・terraform aws vpcはHCLのresourceブロックで宣言的に定義する
・VPC→サブネット→IGW→ルートテーブルの順に依存関係を組む
・dynamic ブロック＋for_eachでSGのingressルールを動的に展開できる
・terraform plan で差分確認、apply で実際にAWSリソースが作成される
・tfstateはS3+DynamoDBでチーム共有するのが本番運用の鉄則
・TypeScriptで書きたい場合はCDKTF（Cloud Development Kit for Terraform）が選択肢になる

この記事のポイント

・TerraformはHCLでAWSインフラを宣言的にコード化できるIaCツール
・tfstateで状態を管理し、S3+DynamoDBでチーム共有するのが実務の基本
・terraform importで既存リソースをTerraformのstate管理に取り込める
・terraform fmt/validateでコードの構文ミスを即座に検知できる
・plan/apply失敗の多くは依存関係・権限・tfstate不整合が原因