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 デプロイあたりのリソース数などにプロジェクト単位の上限があり、必要に応じて引き上げ申請ができる
• 新規開発の位置づけ: 後継の Infrastructure 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 です。エンジンと記述言語が異なり、新規採用では後継側が案内されます。

ハンズオン / CLI例

# 必要な API を有効化
gcloud services enable deploymentmanager.googleapis.com

# 構成ファイル（YAML）からデプロイを作成
gcloud deployment-manager deployments create web-stack \
  --config config.yaml

# 適用前に変更内容をプレビューしてから反映する
gcloud deployment-manager deployments update web-stack \
  --config config.yaml \
  --preview
gcloud deployment-manager deployments update web-stack

# デプロイの状態と展開後のマニフェストを確認
gcloud deployment-manager deployments describe web-stack
gcloud deployment-manager manifests list --deployment web-stack

# デプロイが管理するリソースの一覧を確認
gcloud deployment-manager resources list --deployment web-stack

# 不要になったデプロイを削除（管理対象リソースもまとめて破棄される）
gcloud deployment-manager deployments delete web-stack