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通知 + 自動ロールバック |