Terraform x Docker の実践 -- 環境ひな型の作成、Dockerfile生成と安全チェックの流れ
インフラ構築を手作業で行う時代は終わりつつある。サーバーの設定をコードで記述し、バージョン管理し、レビューし、自動適用する。これがInfrastructure as Code（IaC）の考え方。ソフトウェア開発のベストプラクティスをインフラ管理に持ち込むアプローチと言い換えてもいい。
Terraform の作業は4つのフェーズで回る。コードを書き（Write）、差分を確認し（Plan）、適用し（Apply）、不要になったら破棄する（Destroy）。Plan で変更内容を事前に確認できるのが最大の安全弁。
| フェーズ | コマンド | 実行内容 | 注意点 |
|---|---|---|---|
| Write | - | HCLファイルにリソースを宣言。Provider（AWS, GCP等）とリソースタイプを指定する | モジュール化で再利用性を高める |
| Init | terraform init | Providerプラグインのダウンロード、Backend（State保存先）の初期化 | プロジェクト初回と Provider 追加時に実行 |
| Plan | terraform plan | 現在のStateとコードの差分を計算し、追加/変更/削除されるリソースを表示 | 本番適用前に必ず確認。CI/CDで自動実行が推奨 |
| Apply | terraform apply | Planの内容をクラウドに適用。実際にリソースが作成・変更・削除される | 本番は承認フロー必須。-auto-approve は開発環境のみ |
| Destroy | terraform destroy | 管理している全リソースを削除。開発・検証環境のクリーンアップに使う | 本番環境では原則使用禁止。部分削除は targeted destroy で |
Terraform を構成する5つの概念を押さえておく。Provider がクラウドAPIとの接続口、Resource が個々のインフラ部品、Module が再利用可能なパッケージ、State が現在の状態記録、Backend がStateの保存先。
| 概念 | 役割 | 具体例 | 管理の要点 |
|---|---|---|---|
| Provider | クラウドサービスへの認証と接続 | aws, google, azurerm（3,000以上のProviderが公開） | バージョン固定（required_providers）で安定性を確保 |
| Resource | 作成・管理するインフラ部品の定義 | aws_instance, aws_s3_bucket | 命名規則をチームで統一する |
| Module | 複数Resourceをまとめた再利用単位 | VPCモジュール, ECSモジュール | Terraform Registry に公式モジュールがある |
| State | 現在のインフラ状態と設定値の記録 | terraform.tfstate | ローカル保存は避ける。リモートBackend必須 |
| Backend | Stateファイルの保存・ロック制御 | S3 + DynamoDB, Terraform Cloud | チーム開発ではロック機構が必要 |
Terraform のHCLコードをゼロから書くのは手間がかかる。AIに要件を伝えてひな型を生成させ、人間がレビューして Plan で安全確認し、Apply で適用する。このフローが現実的な使い方になる。
AIが生成するHCLコードの品質は高いが、セキュリティ周りの設定は人間の確認が必須。特にIAMポリシーの「*」（ワイルドカード）指定、セキュリティグループのインバウンドルール、S3バケットのパブリックアクセス設定は要確認。
Docker は「アプリケーションとその実行環境をパッケージにして持ち運べる」技術。Dockerfileからイメージを作り、イメージからコンテナを起動し、イメージはRegistryで共有する。この3つの関係を押さえれば、Docker の全体像が見える。
| 概念 | 役割 | ライフサイクル | ポイント |
|---|---|---|---|
| Dockerfile | イメージのビルド手順をコードで記述 | 開発者が作成 → Gitで管理 | 1行1レイヤー。命令の順序がキャッシュ効率に影響 |
| Image | コンテナのテンプレート（読み取り専用） | build → tag → push → pull | 軽量なベースイメージ（Alpine, Distroless）を推奨 |
| Container | Imageから作られた実行中のプロセス | run → stop → rm | 使い捨て前提。データはVolumeに永続化 |
| Registry | Imageの保管・配布サービス | push（アップロード）/ pull（ダウンロード） | プライベートRegistryで社内イメージを管理 |
本番環境にビルドツールやソースコードは不要。マルチステージビルドを使えば、ビルド用ステージで成果物を作り、ランタイム用ステージには成果物だけをコピーする。イメージサイズが劇的に小さくなる。
Dockerfileの生成もAIに任せられる。ただし、AIが生成するDockerfileにはセキュリティ上の問題が含まれがちで、そのまま使うのは危険。生成後にセキュリティチェックを通すフローを標準にする。
コンテナイメージの脆弱性スキャンはCI/CDパイプラインに組み込む。ビルド直後にスキャンし、Critical/High の脆弱性が見つかればデプロイを停止する。これを自動化すれば、脆弱なイメージが本番に到達することを防げる。Docker Scout はDocker Desktop に統合されたスキャン機能で、開発中のローカルスキャンにも使える。
| ツール | 特徴 | 料金 | CI/CD統合 |
|---|---|---|---|
| Trivy | Aqua Security製のOSS。高速。コンテナイメージ、ファイルシステム、IaCファイルをスキャン可能 | 無料 | GitHub Actions, GitLab CI, Jenkins 対応 |
| Docker Scout | Docker公式のセキュリティスキャン。Docker Desktop統合。SBOM生成とリアルタイム脆弱性監視 | Free / Team / Business | Docker CLI, GitHub Actions 対応 |
| Snyk Container | 商用。修正提案が優秀。ベースイメージの推奨も提示 | Free / Team / Enterprise | GitHub Actions, GitLab CI, Bitbucket 対応 |
| Grype | OSS（Anchore）。Trivyの代替。SBOM生成ツールSyftと連携 | 無料 | GitHub Actions 対応 |
開発・ステージング・本番の3環境を Terraform で管理する場合、環境ごとに設定値（インスタンスサイズ、レプリカ数等）を分離する必要がある。同じモジュールを使い、変数だけ切り替えるのが定石。
Terraform Workspaces を使う方法もあるが、環境間の差異が大きい場合はディレクトリ分離の方が見通しが良い。Workspacesは同じ構成でパラメータだけ変える場合（dev/staging が同構成など）に向いている。
Terraform でインフラを構築し、Docker でアプリをパッケージし、CI/CDで自動デプロイする。この3つを組み合わせた全体像を把握しておく。
| レイヤー | 担当ツール | 管理対象 | 自動化ポイント |
|---|---|---|---|
| インフラ | Terraform | VPC, サブネット, RDS, ECS Cluster | PRマージ時に terraform apply を自動実行 |
| アプリケーション | Docker | アプリのパッケージング、依存関係管理 | Dockerfileの変更で自動ビルド → スキャン |
| デプロイ | CI/CD (GitHub Actions等) | ビルド、テスト、スキャン、デプロイの自動化 | 環境ごとの承認フロー（dev自動, prod手動承認） |
| 監視 | CloudWatch / Datadog | メトリクス、ログ、アラート | 異常検知でSlack通知 + 自動ロールバック |