Cloud Deployment Manager

解決する課題

Google Cloud のリソースを画面やコマンドで手作業に積み上げると、構成が属人化し再現が難しくなります。Cloud Deployment Manager は、構成を宣言的なテンプレートとして記述し、リソース群を 1 つのデプロイとしてまとめて作成・更新・削除できるようにします。

• ネットワーク・Compute・ストレージなどを一括で再現可能にプロビジョニングしたい
• 環境（本番・検証）ごとの差分をパラメータで切り替え、同じ構成を流用したい
• 手作業による構成のばらつき（ドリフト）を避け、コードとして履歴管理したい
• 既存資産が Deployment Manager に依存しており、維持・読み解きが必要

主要概念と用語

• デプロイ（Deployment）: 管理対象のリソースを束ねる単位。1 つの構成に対応し、作成・更新・削除のライフサイクルを持つ
• 構成（Configuration）: デプロイの起点となる YAML ファイル。どのリソースをどの設定で作るかを宣言する
• リソース（Resource）: 構成内で定義する個々の Google Cloud オブジェクト。type に Compute やネットワークなどの種類を指定する
• テンプレート（Template）: 構成を再利用・パラメータ化するための部品。Jinja2 や Python で動的に組み立てられる
• プロパティ（Properties）: 各リソースに渡す設定値。マシンタイプやリージョンなどを指定する
• タイプ（Type）: 作成するリソースの種別。Google Cloud の API リソースを参照する基本タイプや、テンプレートを指す合成タイプがある
• マニフェスト（Manifest）: デプロイ時に展開された最終構成のスナップショット。実際に適用された内容を確認できる
• プレビュー（Preview）: 実際に適用する前に、作成・変更されるリソースを試算する操作

仕様・制限・クォータ

• 記述言語: 構成は YAML。テンプレートは Jinja2 または Python で記述し、変数や繰り返しで動的に組み立てられる
• 対象リソース: Google Cloud の多くの API リソースを type で参照して作成できる。利用できるタイプは公式ドキュメントを参照する
• 更新の挙動: リソースによっては更新時に置換（再作成）が必要なものがあり、更新ポリシーで扱いを制御する
• プロジェクト/グローバル: デプロイはプロジェクトに紐づくグローバルなリソースとして管理される
• クォータ: デプロイ数や 1 デプロイあたりのリソース数などにプロジェクト単位の上限があり、必要に応じて引き上げ申請ができる
• 新規利用は停止済み: 2026年6月30日以降、新規利用者は Deployment Manager V2 API を有効化できず、初回デプロイも作成できない
• 停止期限: 既存利用者向けの稼働も2027年6月30日まで。DM Convert で変換できない概念を洗い出し、Terraform の状態を Infra Manager へ取り込んで移行する

内部の仕組み

横にスクロール

Deployment Manager は、構成とテンプレートをまず展開（expand）して最終的なリソース定義を確定し、それを Google Cloud の各 API 呼び出しへ変換してプロビジョニングします。確定した内容はマニフェストとして記録されます。

• 構成内のテンプレート（Jinja2／Python）を評価し、変数や条件を解決してフラットなリソース一覧に展開する
• 展開結果から各リソースの依存関係を解決し、参照（$(ref.…)）に基づいて作成順序を決める
• 各リソースを対応する Google Cloud API へ作成・更新・削除のリクエストとして送る
• 更新時は既存デプロイと新しい構成を比較し、追加・変更・削除の差分を算出する
• 操作は Cloud Audit Logs に記録され、誰がいつどのデプロイを変更したかを追跡できる

設計パターン / ベストプラクティス

• 構成は Git で管理し、変更のレビューと履歴を残す（手作業の構成変更を排除する）
• 共通部品はテンプレート化して再利用し、環境差分はプロパティ（入力）で切り替える
• 適用前に必ずプレビューで差分を確認し、想定外の削除や置換を検知する
• Python テンプレートに複雑なロジックを盛り込みすぎず、可読性と保守性を優先する
• 新規構築では後継サービス（Infrastructure Manager）や Terraform を第一候補とし、Deployment Manager は既存資産の維持に用いる

運用・監視

• デプロイの状態（適用中・完了・失敗）とマニフェストを確認し、失敗時はエラー内容から原因を追う
• 適用が失敗する場合は、API の有効化漏れや実行主体の IAM 権限不足、リソース固有の制約を疑う
• 操作は Cloud Audit Logs（Admin Activity／Data Access）に記録されるため、変更追跡と棚卸しに使う
• 構成ドリフト（手動変更による実態とのずれ）が疑われる場合は、プレビューや差分で把握する
• 不要になったデプロイは削除し、管理対象リソースをまとめて整理する

コスト

Deployment Manager 自体は構成を適用するための仕組みであり、課金の主体はデプロイによって作成された Google Cloud リソースです。Compute やネットワーク、ストレージなどの実費が、それぞれのサービスの料金に従って発生します。

セキュリティ

• デプロイの作成・更新・削除を IAM で制御し、本番デプロイを操作できる主体を限定する
• 実行に使う ID の権限が作用範囲の上限になるため、広すぎる権限を避け最小権限に保つ
• 機密値はテンプレートへ直書きせず、Secret Manager 等を参照する形にして平文の散在を避ける
• 構成・テンプレートを置く Cloud Storage バケットや Git リポジトリも保護し、改ざんを防ぐ
• 操作は Cloud Audit Logs で監査し、誰がどのデプロイを変更したかを追跡できるようにする

関連サービス・比較

移行先の中心は Infrastructure Manager です。DM Convert で YAML/Jinja/Python 構成を Terraform 構成と状態へ変換しますが、すべての概念を自動変換できるわけではないため、差分検証と状態の取り込みが必要です。

ハンズオン / CLI例

# 既存利用者が移行対象のデプロイを棚卸し
gcloud deployment-manager deployments list
gcloud deployment-manager deployments describe web-stack
gcloud deployment-manager manifests list --deployment web-stack

# 移行後の照合用に管理資源を一覧化
gcloud deployment-manager resources list --deployment web-stack

# Terraform 側へ状態を取り込んで照合した後、資源を残して DM の管理だけ外す
gcloud deployment-manager deployments delete web-stack \
  --delete-policy=ABANDON