GcpDmInfra · ウェイトリスト

2027年6月30日までに Google Cloud Deployment Manager から移行——DM Convert で変換できないものと、安全なインポート/abandon の手順を把握

  1. サポート終了(発効済み)。通常の DM チケットは自動的に却下(移行関連・ブロッカーを除く)。

  2. サポート延長の最長期限。

  3. Deployment Manager はサービス終了、関連 API はすべて停止。既存リソースは引き続き稼働。

2026年6月30日以降、新規ユーザーは Deployment Manager V2 API の有効化や最初のデプロイ作成ができません。終了までは既存顧客は「自己責任」で DM を利用可能。

日付は Google Cloud「Deployment Manager deprecation」(2026年9月30日更新)に基づく。DM Convert はプレビュー版ツールです。

Deployment Manager のサポートは 2026年4月1日に終了し、サポート延長の最長期限は 2027年3月31日、サービスは 2027年6月30日以降に終了します——既存リソースは引き続き稼働します。5 つの質問に答えるだけ——YAML/Jinja/Python templates のどれか、composite types・type providers・Actions を使っているか、構成の保存場所、DM の preview や rollback に依存しているか、移行先は Infra Manager か自前の Terraform か。変換可否、手作業が必要な項目、Convert → import → abandon の順序、回帰チェックリストを取得。認証情報、サービスアカウントキー、プロジェクト ID、構成ファイルを貼る必要はありません。

GcpDmInfra は独立したツールであり、Google とは提携・承認関係にありません。 · GCP コネクタではない。認証情報不要。

課題

3 つの日付:2026/4/1 · 2027/3/31 · 2027/6/30

Google Cloud「Deployment Manager deprecation」によると、サポートは 2026年4月1日に終了しました(通常の DM チケットは、ブロッカーまたは Infra Manager への移行に関するもの以外は自動的に却下)。サポート延長の最長期限は 2027年3月31日です。2027年6月30日以降はサービス終了となり、関連 API はすべて停止します。Deployment Manager で作成したリソースは引き続き稼働します。公式の移行パスは DM Convert(プレビュー版)→ Terraform import → Infra Manager import → --delete-policy ABANDON ですが、composite types、宣言的な等価物のない Actions、custom type providers は変換されません。また既定の削除ポリシー DELETE は基盤リソースを完全に削除します。

Before

  • deprecation・DM Convert・Infra Manager の import/deploy ドキュメントを行き来
  • 2027/3/31 に DM が止まる、またはリソースが削除されると誤解
  • 既定の DELETE で deployments delete を実行、または state と構成が不一致のまま unlock

After — GcpDmInfra で

  • 5 問で自分に関係する変換ギャップと手順だけ
  • 4/1 サポート終了・3/31 延長終了・6/30 以降サービス終了を明確に区別、リソースは稼働継続
  • 先にインポートし preview で No changes を確認、その後 --delete-policy ABANDON

公式タイムライン(Google Cloud「Deployment Manager deprecation」)

日付状態意味
2026年4月1日発効済みサポート終了(発効済み)。通常の DM チケットは自動的に却下(移行関連・ブロッカーを除く)。
2026年6月30日発効済み新規ユーザーは Deployment Manager V2 API の有効化や最初のデプロイ作成ができません(Infra Manager へ誘導)。
2027年3月31日サポートサポート延長の最長期限。
2027年6月30日以降サービス終了Deployment Manager はサービス終了、関連 API はすべて停止。既存リソースは引き続き稼働。

サービス終了までは、既存顧客は console、Google Cloud CLI、Deployment Manager V2 API で DM を「自己責任」で利用できます(新機能なし、重要でない修正なし)。Deployment Manager で作成したリソースは引き続き稼働し、通常の Google Cloud ツールで管理できます。DM を使っていない App Engine Flex のお客様は影響を受けません。

ソリューション

GcpDmInfra ができること

Deployment Manager を使い続けているプラットフォーム/IaC チーム向けの、DM → Infra Manager/Terraform 移行準備の意思決定レイヤー:DM の使い方 × 高度な機能 × 構成の保存場所 × 依存 × 移行先 → 変換可否 + 手作業項目 + 順序 + 回帰チェックリスト。Google Cloud ドキュメントの代替でも GCP コネクタでもなく、Google とは提携関係にありません。

WHO

Google Cloud Deployment Manager(YAML 構成+Jinja/Python templates、gcloud deployment-manager、Deployment Manager V2 API)で GCP リソースを管理し続けている、プラットフォームエンジニアリング・IaC/Terraform・DevOps/SRE チームとクラウドアーキテクト。Infrastructure Manager(Infra Manager)や自前管理の Terraform へまだ移行していない方。

PROBLEM

サポートは 2026年4月1日に終了し、サポート延長の最長期限は 2027年3月31日。2027年6月30日以降はサービス終了。公式パス(DM Convert〈プレビュー版〉→ Terraform state へのインポート → Infra Manager import → ABANDON)には穴があります:composite types、宣言的な等価物のない Actions、custom type providers は変換されない。プライベート Git には Cloud Build 接続が必要、state は Cloud Storage に保存、rollback は手動の roll forward に。そして DM の既定の削除ポリシーは DELETE です。

SOLUTION

5 問にチェック → 変換可否、手作業が必要な項目、DM Convert → Terraform import → Infra Manager import → abandon の順序(公式コマンド付き)、回帰チェックリスト。GCP の認証情報、サービスアカウントキー、プロジェクト/組織 ID、DM 構成、コードは一切求めません。GCP コネクタではありません。

RESULT

すべてのデプロイを Terraform に変換して Infra Manager または自前の Terraform に引き継ぎ、2027年6月30日以降のサービス終了前に --delete-policy ABANDON で DM の管理から安全に外す——既定の DELETE で本番リソースを消したり、2027年7月になって旧ツールでインフラを更新できないと気付いたりしないために。

機能

機能

プロダクト仮説に基づくマーケティング上のポイントです(需要検証用であり、正式な仕様の約束ではありません)。

タイムラインとサポートリスク

すでに「自己責任」の状態です。移行に Google の支援が必要なら 2027年3月31日まで。変換・インポート・abandon はすべて 2027年6月30日以降のサービス終了前に完了させる必要があります。

変換可否

references、dependsOn、accessControl、iamMemberBinding は変換される。composite types と custom type providers は変換されない。Actions は宣言的な等価物があるものだけ変換。

手作業が必要な項目

composite types → Terraform modules、プライベート Git → Cloud Build 接続、rollback → 手動の roll forward、preview → Infra Manager previews、backend block は定義不可、適用のタイムアウトは 2 時間。

Convert → import → abandon の順序

expanded config → DM Convert → Terraform import → Infra Manager lock/import-statefile/unlock/preview → --delete-policy ABANDON。

回帰チェックリスト

非本番プロジェクトでリハーサル、すべての terraform plan を確認、Infra Manager preview で No changes を確認、abandon 後にリソースが残っていることを確認。

変換可否(Google Cloud「Using DM Convert」に基づく)

DM の使い方DM Convert(Terraform)
YAML のみ、Jinja、Python templates変換される(DM Convert は YAML と Jinja/Python templates を読み込む。稼働中デプロイの manifest から expandedConfig を取得可能)
References、dependsOnTerraform references、depends_on
accessControl(authoritative)<resource_type>_iam_policy
iamMemberBinding(non-authoritative)<resource_type>_iam_member
Composite types変換されない(非推奨)→ Terraform modules を手書き
Actions:insert/get/setIamPolicyresource/data/*_iam_policy·*_iam_member に変換
Actions:patch/delete/list、カスタム API変換されない → 手作業で対応
Custom type providers変換されない(その API で定義された Actions も変換されない)
リソースタイプが不明--list_supported_types で公式のサポート一覧を確認

DM Convert はプレビュー版です。出力は Terraform 構成と Terraform のインポートコマンドファイル(--output_tf_import_file)で、state はそのインポートを実行したときに Terraform が生成します。expanded config から変換する場合、template のパラメータやループは展開済みです——再利用性を保つには Terraform variables/modules に自分で書き直してください(公式手順からの推論です。変換後に確認してください)。

手作業が必要な項目——DM の概念 → Infra Manager/Terraform

DM の概念Infra Manager/Terraform での対応
Composite types/再利用 templatesTerraform modules(有効な root module であること。Infra Manager は templating/generation 非対応)
プライベート Git の構成先に Git ホストとリポジトリを Cloud Build(または Developer Connect Git proxy)に接続し、その後 --git-source-repo を使う
DM 内部の stateInfra Manager は Cloud Storage に自動保存。自前の Terraform では Cloud Storage bucket を推奨。Infra Manager の構成では backend block を定義できない
DM rollback以前の revision の Terraform 構成で手動 roll forward
DM previewgcloud infra-manager previews create(Terraform plan)
大規模デプロイ作成/更新のタイムアウトは 2 時間、preview は 1 時間 → 構成を分割
goog-dm ラベルインポート後の terraform plan に goog-dm ラベルの削除が表示される(公式例では許容)

Git ホストとリポジトリを Cloud Build に接続すれば、プライベート Git は Infra Manager で利用できます(GitHub、GitHub Enterprise、GitLab、GitLab Enterprise、または Developer Connect Git proxy)。deprecation ページでは「直接」のサポートがないと記載されています。

Convert → import → abandon の順序(公式コマンド)

  1. まず進行中のデプロイを reconcile する。
  2. expanded config を取得:gcloud deployment-manager deployments describe DEPLOYMENT_NAME --format="value(deployment.manifest)"gcloud deployment-manager manifests describe MANIFEST_NAME --deployment DEPLOYMENT_NAME --format="value(expandedConfig)"
  3. DM Convert image(プレビュー版)を実行——Terraform 構成+インポートコマンドファイル:--config deployment.yaml --output_format TF --output_file … --output_tf_import_file … --deployment_name … --project_id …
  4. terraform init、生成されたインポートファイルを実行し、terraform plan で差分を 1 つずつ確認。
  5. (移行先が Infra Manager の場合)placeholder deployment を作成(gcloud infra-manager deployments apply)→ gcloud infra-manager deployments lock → import-statefile+terraform.tfstate をアップロード → 構成をアップロード → state と構成の一致を確認 → unlock → gcloud infra-manager previews create で No changes を確認。

    state と構成が一致しないと、unlock 時に Infra Manager は state に合わせてリソースを作成または削除します。

  6. 最後に DM デプロイだけを削除し、リソースは残す:gcloud deployment-manager deployments delete DEPLOYMENT_NAME --delete-policy ABANDON

    既定の DELETE ポリシーは絶対に使わないでください——基盤リソースを完全に削除します。

例では常に PROJECT_ID/DEPLOYMENT_NAME のプレースホルダーを使用し、このページは ID を一切受け付けません。コマンドとフラグは Google Cloud の DM Convert、Infra Manager import、Deleting deployments ドキュメントの表記どおりです。

ウェイトリストに登録

仕組み

仕組み

3 ステップ。Google Cloud への接続も認証情報も不要。

  1. 1

    5 つの質問に答える

    YAML/Jinja/Python?composite types・type providers・Actions?構成の保存場所は?DM の preview や rollback に依存?Infra Manager か自前の Terraform か?

  2. 2

    変換できるもの・できないものを確認

    変換可否、手作業が必要な項目、2027/3/31・6/30 までのタイムラインリスク。すべて Google Cloud ドキュメントへのリンク付き。

  3. 3

    変換・インポート・abandon・再テスト

    公式の順序——DM Convert → Terraform import → Infra Manager import → --delete-policy ABANDON——と回帰チェックリスト。認証情報・キー・ID・構成不要。

ユースケース

こんなチーム向け

思い当たる状況があれば、ウェイトリストに登録して検証にご協力ください。

Jinja templates+composite types でネットワーク基盤を構築

composite types は変換されない——手書きする Terraform modules の一覧と比較手順が必要。

Python templates で大量のリソースを動的に生成

変換結果は展開後のリソース——modules/variables にリファクタするかを決め、Infra Manager の 2 時間タイムアウトに合わせて分割が必要。

構成がプライベート GitHub/GitLab にある

Infra Manager には先に Cloud Build 接続が必要——前提手順のチェックリストが必要。

DM preview で変更をレビューし、rollback で障害対応しているチーム

Infra Manager previews と roll forward の runbook への切り替えが必要。

多数のプロジェクト、数十のデプロイ

Infra Manager か自前の Terraform(state は Cloud Storage、実行は Cloud Build)かを決め、デプロイごとの Convert → import → abandon をバッチで計画する必要。

Actions や custom type providers を使っている

どの Actions が resource/data に変換され、どれを手作業で対応すべきかを知る必要。

FAQ

よくある質問

GcpDmInfra は Google 公式ツールですか?

いいえ。独立したツールで、Google とは提携・承認関係にありません。情報はすべて Google Cloud 公式ドキュメントをリンク付きで引用しています。

2027年6月30日以降、リソースは削除されますか?

公式ドキュメントによれば、Deployment Manager で作成したリソースは引き続き稼働し、通常の Google Cloud ツールで管理できます。ただし Deployment Manager や gcloud deployment-manager では管理できなくなります。

2027年3月31日と6月30日の違いは?

3/31 はサポート延長の最長期限、6/30 以降はサービス終了で関連 API がすべて停止します。サポート自体は 2026年4月1日に終了しています。

DM Convert ですべて変換できますか?

いいえ。composite types は変換されず、Actions は宣言的な等価物があるものだけ、custom type providers は変換されません。また DM Convert はプレビュー版です。

構成がプライベート Git にあります。Infra Manager を使えますか?

はい。Git ホストとリポジトリを Cloud Build に接続すれば利用できます(Infra Manager の deploy ドキュメント)。deprecation ページでは「直接」のサポートがないと記載されています。

リソースを残して DM デプロイだけ削除するには?

--delete-policy ABANDON を使います。既定の DELETE ポリシーは基盤リソースを完全に削除します。

認証情報、サービスアカウントキー、プロジェクト ID、構成を求めますか?

いいえ。求めず、保持せず、保存しません。Google Cloud プロジェクトにも接続しません。

DM Convert、インポート、abandon を代行してくれますか?

いいえ。MVP は静的なチェック+リスト+順序+ウェイトリストです。

Early Access はいつ?

ウェイトリストからメールで順次ご案内。偽の公開日は出しません。

GcpDmInfra は独立したツールであり、Google とは提携・承認関係にありません。

ウェイトリストに登録

ウェイトリスト

ウェイトリストに登録

仕事用メールを残して、GcpDmInfra の Early Access とローンチ通知を受け取ってください。メール以外はチェックボックスとプルダウンのみで、自由入力欄は一切ありません。

構成形式 (任意・複数可)
高度な DM 機能 (任意・複数可)
DM preview/rollback への依存 (任意・複数可)

ウェイトリスト/Early Access/ローンチ通知のみに使用。GCP の認証情報、サービスアカウントキー、プロジェクト/フォルダ/組織 ID、DM 構成や templates、Terraform 構成や state、コードは貼らないでください。いつでも解除可能。