この記事の最終更新日: 2025年5月14日
Infrastructure as Code (IaC) を導入すると、サーバーやネットワークなどのインフラ資産を「コード」として管理できるため、再現性・可読性・自動化が飛躍的に向上します。本記事では代表的な IaC ツール Terraform と、その運用を強力にサポートする Terragrunt を、初心者にもわかりやすく解説します。
Terraform とは？
Terraform は HashiCorp 社 が開発・公開しているオープンソースの IaC ツールです。インフラの構築・管理を人手ではなく「コード」で実施することで、作業ミスを減らし、チームでの開発・運用がスムーズになります。
Terraform では HCL（HashiCorp Configuration Language） という専用の記述言語を使って、AWS や GCP、Azure などのクラウドサービスに対するインフラの定義を行います。
主な特徴
- 宣言的構文：どう作るかではなく「こうなっていてほしい」という完成形を書くスタイル
- マルチクラウド対応：AWSやGCPなど、異なるクラウドを同じ形式で管理可能
- 状態ファイル (state)：現在のインフラ構成を
.tfstateというファイルに保持。変更が必要な部分を自動で検出 - プランニング機能：
terraform planを使うことで、実行前に何が変わるかを事前に確認可能 - モジュール機能：構成を部品化（モジュール化）して再利用しやすくできる
Point：「リソースの設計書をHCLで書く」→「Terraformが実際にクラウドに構築してくれる」という仕組みです。
Terraform の基本ワークフロー
Terraform を使う際は、以下の手順で操作します。
| ステップ | コマンド | 目的 |
|---|---|---|
| 初期化 | terraform init | 使用するクラウドやモジュールの情報を準備（初期設定） |
| 変更確認 | terraform plan | 実際に構築する前に、何が変わるかを確認（安全性向上） |
| 適用 | terraform apply | 実際にクラウドへ構成を反映（インフラの構築） |
| 状態の可視化 | terraform show | 適用済みインフラの情報を人間が見やすく表示 |
| 破棄 | terraform destroy | 作成したリソースを安全に削除 |
補足：ワークスペース (Workspace) とは？
ワークスペースは、開発環境・本番環境といった「複数のインフラ環境」を 1 つのコードベースで使い分ける機能です。
terraform workspace new dev
terraform workspace select dev
これにより、例えば dev ワークスペースでは開発用リソース、本番では prod ワークスペースを使って安全に分離できます。
Terraform の主要コンポーネント
Terraform を扱う上でよく出てくる用語について、簡単に説明します。
- Provider（プロバイダー）：クラウドと Terraform をつなぐもの。AWS や GCP を使いたい場合はそれぞれの Provider を指定します。
- Resource（リソース）：作りたいクラウドの部品（例：S3バケットやEC2）を定義します。
- Data Source（データソース）：既に存在する外部リソースの情報を参照します。例えば最新のAMI IDなどを取得可能。
- Module（モジュール）：複数のリソースをまとめて再利用する単位。大規模化に欠かせません。
- Backend（バックエンド）：Terraform の状態ファイル（state）を保存する仕組み。チームで共有するために S3 や Terraform Cloud を使用します。
Terraform ベストプラクティス（初心者向け5選）
- Remote Backend（リモートバックエンド）を活用：state ファイルを安全に共有・管理
- バージョン固定：プロジェクトで使用する Terraform のバージョンを統一（トラブル防止）
- 公式モジュールを活用：
terraform-aws-modulesなど、信頼できる既存モジュールで効率化 - CI/CD パイプラインと統合：GitHub Actions などを使って自動構築・テストを導入
- Git 管理：コードの変更履歴を Git で追跡し、レビューやロールバックを容易に
Terragrunt とは？
Terraform は非常に強力ですが、実際の運用ではこんな悩みが生まれがちです：
- 複数の環境（dev/stg/prod）で同じようなコードをコピペしている
- state ファイルの保存先を毎回手動で書いている
- 複数のモジュールの順序関係が分かりにくい
そこで登場するのが Terragrunt（テラグラント） です。 Terraform をより効率よく、安全に運用するための「補助ツール」であり、Terraform を内部で使っています（実行時に terraform を呼び出す）。
Terragrunt を使うと、共通設定の集約やモジュール管理の効率化、環境の切り替えが簡単になります。
Terragrunt の仕組みとメリット
Terragrunt は terragrunt.hcl というファイルを使って、Terraform の設定をラップ（包み込む）する形で運用します。
主な仕組み
- include：共通設定を親ディレクトリから継承（重複コードを排除）
- inputs：Terraform の変数に値を渡す
- remote_state：バックエンド（state保存先）の設定も共通化可能
メリットまとめ
- コードの再利用性が向上：同じ構成を複数の環境で使い回せる
- 設定の一元管理が可能：stateや変数などを1か所で管理
- 大規模構成に対応しやすい：複数のリソースをまたぐ構成でも整理しやすい
- 一括操作が可能：複数の環境をまとめて一気に plan や apply できる
Terragrunt 実践ディレクトリ構成例
Terragrunt を用いる際は、以下のようなディレクトリ構成で管理するとわかりやすく、保守性も高まります。
infra-live/
├── terragrunt.hcl # 共通設定（backend など）
├── dev/
│ └── s3/terragrunt.hcl # dev 環境の S3 バケット定義
└── prod/
└── s3/terragrunt.hcl # 本番環境の S3 バケット定義
infra-modules/
└── s3/main.tf # 実際の Terraform モジュール
このように、「環境ごとの構成」は
infra-live/に、「共通モジュール」はinfra-modules/に分けるのが一般的です。
Terraform と Terragrunt の使い分け
| 特徴 | Terraform 単体 | Terraform + Terragrunt |
|---|---|---|
| 学習コスト | やや低い | やや高い（記述が複雑） |
| 小規模プロジェクト向け | ◎ | ○（少し過剰な場合あり） |
| 大規模プロジェクト向け | △（管理が煩雑になりがち） | ◎（共通化でスッキリ） |
| 自動化との相性 | ◎ | ◎（run-allなど便利機能あり） |
まとめ
Terraform と Terragrunt は、クラウド時代に欠かせないインフラ自動化のためのツールです。
- Terraform は「インフラをコードで管理」する中心的な存在
- Terragrunt は Terraform の運用を大幅に楽にしてくれる補助ツール
最初は Terraform だけで十分ですが、環境の数が増えたり、構成が複雑になってきたら Terragrunt の導入を検討してみてください。
今後学ぶべきポイント
- HCLの構文ルールとベストプラクティス
- Terraformモジュールの作り方・使い方
- Terragruntでの環境分離や依存管理の実践方法
- CI/CDとの連携方法（GitHub ActionsやGitLab CIなど）
- Terraform CloudやS3 + DynamoDBによるバックエンド構成
この記事は 2025 年 4 月時点の情報をもとに執筆しています。
大阪のエンジニアが書いているブログ。
コメント