Terragrunt入門: TerraformをDRYに運用するための実務指針

TerragruntはTerraformの実行を補助する軽量ラッパーで、モジュールの再利用、リモートステート設定の共通化、環境差分の管理をDRYに保つ狙いがあります。

試験対策の観点では、Terraformの公式機能（モジュール、バックエンド、状態管理、ワークスペース、CLI動作）を正しく理解することが最優先です。Terragruntは実務で役立ちますが、試験はTerraformの動作が出題の中心です。

Terragruntの立ち位置と試験範囲の切り分け

TerragruntはTerraform CLIを呼び出す補助ツールで、HCLで記述されたterragrunt.hclからモジュールの取得や入力変数の注入、共通設定の適用を行います。Terraform自体の状態管理やプラン・適用といったコア機能は、あくまでTerraformが担います。

Terraform Associate/Proレベルの試験は、バックエンド・状態ファイル・モジュール構成・ワークスペース・CLIの詳細挙動など公式機能の理解が前提です。Terragrunt固有の文法やサブコマンドは直接出題されにくく、出題されたとしてもTerraformの原理に基づいて判断できる内容に留まります。

• DRYの主眼: ステートやプロバイダー設定等の共通化
• Terraformの真実のソース: .tf / .tf.json と state（Terragruntは変更しない）
• 試験ではTerraformのバックエンド、ロック、依存関係解決を重点復習

TerraformとTerragruntの役割比較（要点早見）

両者の責務を峻別すると設計がぶれません。Terraformはインフラ宣言と状態管理の“実行エンジン”。Terragruntはその呼び出しの“編成・共通化レイヤ”です。

以下は実務で迷いやすい論点の対比です。

• 状態の正本はTerraformバックエンド（S3、GCS、AzureRM等）
• 依存順序の実行や共通設定の差し込みはTerragruntで整理
• プランの結果や適用の副作用はTerraformの責務

ディレクトリ戦略と依存関係の表現

Terragruntでは“環境 × サービス × レイヤ（ネットワーク/データ/アプリ）”のように階層を切ると、共通化と差分の両立がしやすくなります。上位階層に共通のterragrunt.hclを置き、下位で必要最小の差分のみを記述します。

依存関係は、例えばネットワーク→データ→アプリの順で実行する設計にします。状態の正本は各モジュールのバックエンドにあり、Terragruntはその順序でterraformコマンドを呼ぶだけ、という切り分けを意識します。

• 上位に共通localsとremote_state、下位でinputsとソース指定
• 依存性は強すぎない粒度に分割（ネットワーク境界など）
• run-allは便利だが、破壊的変更時は対象を絞って適用

環境階層と依存の一例

live/
  ├─ prod/
  │   ├─ networking/
  │   │   └─ vpc/             (depends: none)
  │   ├─ data/
  │   │   └─ rds/             (depends: prod/networking/vpc)
  │   └─ app/
  │       ├─ ecs/             (depends: prod/networking/vpc, prod/data/rds)
  │       └─ alb/             (depends: prod/networking/vpc)
  └─ dev/
      ├─ networking/
      │   └─ vpc/
      └─ app/
          └─ ecs/

関係:
[vpc] --> [rds] --> [ecs]
[vpc] --> [alb]

terragrunt.hclの基本パターン（共通化と差分）

共通ファイルでリモートステートやプロバイダー設定を定義し、下位でモジュールソースとinputsのみを書くのが基本です。Terraformのバックエンド設定は、最終的に各モジュールのterraform initに反映されます。

以下はS3バックエンドを共通化し、モジュール変数を環境ごとに注入する最小パターンの例です。

• remote_stateでバックエンド設定を共通化
• terraform.sourceでモジュールの参照を一元管理
• inputsで環境固有値を注入、localsで命名規約を統一

共通terragrunt.hcl と 下位モジュールの例

# live/terragrunt.hcl（共通）
locals {
  env = basename(get_terragrunt_dir())  # prod / dev など
  name_prefix = "acme-${local.env}"
}

remote_state {
  backend = "s3"
  config = {
    bucket         = "acme-tfstate-${local.env}"
    key            = "${path_relative_to_include()}/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "acme-tf-locks"
    encrypt        = true
  }
}

# live/prod/networking/vpc/terragrunt.hcl（下位）
include "root" {
  path = find_in_parent_folders()
}

terraform {
  source = "git::https://example.com/iac-modules.git//aws/vpc?ref=v1.2.3"
}

inputs = {
  name        = "${local.name_prefix}-vpc"
  cidr_block  = "10.0.0.0/16"
}

# live/prod/app/ecs/terragrunt.hcl（依存の参照例）
dependency "vpc" {
  config_path = "../../networking/vpc"
}

terraform {
  source = "git::https://example.com/iac-modules.git//aws/ecs?ref=v1.2.3"
}

inputs = {
  cluster_name = "${local.name_prefix}-ecs"
  vpc_id       = dependency.vpc.outputs.vpc_id
}

運用ベストプラクティスと落とし穴

実務では“Terraformの原則を崩さない”ことが最優先です。ステートの正本性、ロック、計画と適用の一貫性を担保した上で、Terragruntで共通化と順序制御を加えます。

変更の影響範囲が大きい場合は、run-allで一気に適用するのではなく、影響の小さいディレクトリから順に検証します。CI/CDでは環境変数の引き回し、プラン出力の保存、承認ゲートの設計を徹底します。

• バックエンドとロックはTerraformの機能に委ねる（DynamoDBロックなど）
• providersはバージョン固定し、アップグレードは小さく刻む
• 依存を深くしすぎない（循環・巨大グラフの回避）
• planは人がレビューできる単位に分割、applyは最小権限のIDで実行
• 状態操作（mv, rm, import）は必ずテスト環境で手順を固めてから

試験対策メモ（Pro向けの着眼点）

試験ではTerragrunt固有の文法より、Terraformの基礎力が問われます。特にバックエンドの初期化、状態の移行、ワークスペース、モジュールの設計、差分の解釈（plan出力の読み解き）を優先的に押さえましょう。

Terragruntで共通化していても、本質的には各モジュールの作業ディレクトリでterraform init/plan/applyが走る点を念頭に置けば、試験の設問に対して正しい判断ができます。

• バックエンド変更時の手順（init -migrate-state等）の理解
• state mv / import / rm の安全な適用順序
• ワークスペースと変数ファイルの使い分け
• モジュールの参照（registry/VC S）とバージョン固定の流儀
• plan出力からのリスク評価（置換 vs 更新、破壊的変更）

問題で確認

よくある質問