IaCの全体像｜TerraformとAnsibleの役割分担

なぜIaCか

クラウドのダッシュボードやサーバーのターミナルで直接設定を変更すると、「今の本番が実際どういう状態か」がコードから読み取れなくなります。IaC（Infrastructure as Code）は、インフラの状態をコードとして書き、変更をGitの差分としてレビューしてから適用する考え方です。この手引のDBマイグレーションでAIに直接ALTER TABLEを打たせない、と説明しているのと同じ発想を、インフラ全体に広げたものと捉えられます。

壊れたときに作り直せる

VPSが壊れた、CloudflareのD1データベースを誤って消してしまった、といった事態でも、コードが残っていればterraform applyやansible-playbookを再実行するだけで同じ状態を作り直せます。手順がダッシュボードの操作記憶だけに頼っていると、障害時の復旧そのものが属人的な作業になります。

環境ごとの差分を管理できる

検証用と本番用で、同じTerraformモジュールに違う変数を渡すだけで構成をそろえられます。「検証環境だけ設定が違って、本番で初めて気づく」という事故を減らせます。

後から読んで分かる

半年後の自分や、後から加わった人が、ダッシュボードを1画面ずつ遡って確認する必要がなくなります。コードとコミット履歴が、そのまま「なぜこの設定になっているか」の記録になります。

Terraformはクラウドの「箱」を管理する

Terraformが担当するのは、クラウドサービス側にある入れ物です。中身（アプリのコードやコンテナイメージ）はCI側が別に差し替えます。

Cloudflare

D1データベース、R2バケット、DNSレコード、SSL/TLSなどのゾーン設定をcloudflareプロバイダーで管理します。詳細はCloudflare Workers編を参照。

Google Cloud

Cloud Runサービス、Artifact Registry、サービスアカウントとIAM、Secret Managerをgoogleプロバイダーで管理します。詳細はCloud Run編を参照。

どちらも、Terraform自身の状態ファイル（tfstate）は、それぞれのクラウドの非公開オブジェクトストレージに置きます。CloudflareならR2（S3互換のバックエンド経由）、Google CloudならGCS（標準のgcsバックエンド）です。stateにはリソースIDやシークレットの参照が含まれるため、公開設定は構造的に防ぎ、バージョニングを有効にしておきます。

Ansibleは自前VPSの「中身」を管理する

自前VPSでは、Terraformの出番はサーバーを1台立てるところまでで、そこから先――Caddyのインストールと設定、PostgreSQLのセットアップ、アプリ本体の配置、systemdサービスの起動――はAnsibleが担当します。詳細はデプロイの基礎を参照。

国内VPSでTerraformを使わない理由：国内の安価なVPSは、CloudflareやGoogle Cloudほどterraform対応が進んでいません。公式Terraformプロバイダーを出し始めた事業者もありますが、まだベータ版で対応機種も限定的な段階です。そのためこの手引では、VPS本体の契約・構築は手動またはVPS事業者のAPIで行い、サーバー内部だけをAnsibleで一貫管理する構成にしています。

監視もコードで管理する

アラートやアップタイムチェックをダッシュボードからポチポチ設定すると、誰が何のために設定したか分からなくなり、担当者が変わった瞬間に放置されがちです。監視設定もTerraformで管理すれば、他のインフラと同じレビュー・適用の流れに乗せられます。

Google Cloudでは、稼働監視（アップタイムチェック）とアラートポリシーを組み合わせます。

resource "google_monitoring_uptime_check_config" "app" {
  display_name = "my-app health"
  timeout      = "10s"

  http_check {
    path = "/healthz"
    port = 443
    use_ssl = true
  }

  monitored_resource {
    type = "uptime_url"
    labels = {
      host = "app.example.com"
    }
  }
}

resource "google_monitoring_alert_policy" "app_down" {
  display_name = "my-app is down"
  combiner      = "OR"

  conditions {
    display_name = "uptime check failed"
    condition_threshold {
      filter          = "metric.type=\"monitoring.googleapis.com/uptime_check/check_passed\""
      comparison      = "COMPARISON_LT"
      threshold_value = 1
      duration        = "60s"
    }
  }

  notification_channels = [google_monitoring_notification_channel.email.id]
}

Cloudflareでは、SSL証明書の失効やセキュリティイベントなどの通知先をcloudflare_notification_policyで管理します。

resource "cloudflare_notification_policy" "ssl_events" {
  account_id  = var.cloudflare_account_id
  name        = "SSL certificate events"
  description = "SSL証明書関連イベントの通知"
  alert_type  = "universal_ssl_event_type"
  enabled     = true

  mechanisms = {
    email = [{ id = var.notify_email_id }]
  }
}

監視対象や通知先が増えるたびにコードへ1つ追記するだけで済み、「このアラート、誰がいつ設定したのか分からない」という状態を避けられます。

これはGoogle CloudやCloudflareのようなマネージドサービスに監視の仕組みが用意されている場合の話です。自前VPSにはそうした仕組みがないため、Prometheus・Grafana・Alertmanagerを自分で立てます。

Prometheus：VPS上のnode_exporterなどからCPU・メモリ・ディスクの指標を定期的に収集します。
Grafana：Prometheusのデータをダッシュボードとして可視化します。Caddyの基礎で紹介しているリバースプロキシの背後に置き、認証をかけてから公開します。
Alertmanager：Prometheusのアラートルールに応じて、メールやチャットへ通知を振り分けます。

この3つのインストールと設定も、他のミドルウェアと同じくAnsibleのPlaybookに含めます。クラウドの監視がTerraformの中で完結するのに対し、自前VPSでは監視自体もサーバーの一部として構築し、Ansibleで管理する対象に入る、という違いです。

役割分担の全体図

Terraform（Cloudflare）：D1、R2、DNS、ゾーン設定。tfstateはR2（非公開）
Terraform（Google Cloud）：Cloud Run、Artifact Registry、IAM、Secret Manager。tfstateはGCS（非公開・バージョニング有効）
Ansible：VPS内部のミドルウェア（Caddy、PostgreSQL）、アプリの配置、systemdサービス
Terraform（監視）：アップタイムチェック、アラートポリシー、通知先。Google Cloud・Cloudflareどちらもコードで管理
Ansible（自前VPSの監視）：Prometheus・Grafana・AlertmanagerのインストールもPlaybookに含める
CI（GitHub Actions）：アプリのビルドとコンテナイメージ・成果物の差し替え。TerraformやAnsibleの適用とは別ジョブに分ける

共通しているのは、どのツールも「人が手元で直接いじらない」という前提です。変更はコードとしてレビューし、適用はCI経由で行うことで、公開先がCloudflareでもGoogle Cloudでも自前VPSでも、同じ規律で運用できます。

IaCの導入から相談したい方へ

Terraform・Ansibleを使った構成の設計から、実際の構築・運用まで対応します。

運用について相談する