GcpDmInfra · Warteliste
Support eingestellt (in Kraft). Normale DM-Tickets werden automatisch abgelehnt (außer Migrationsthemen oder Blocker).
Maximale Support-Verlängerung endet.
Deployment Manager wird abgeschaltet; alle zugehörigen APIs enden. Bestehende Ressourcen laufen weiter.
Seit 30. Juni 2026 können neue Nutzer die Deployment Manager V2 API nicht aktivieren oder ein erstes Deployment anlegen. Bis zur Abschaltung können Bestandskunden DM „auf eigenes Risiko“ nutzen.
Termine laut Google Cloud „Deployment Manager deprecation“ (aktualisiert 30. Sept. 2026). DM Convert ist ein Preview-Tool.
Der Support für Deployment Manager endete am 1. April 2026, die maximale Support-Verlängerung endet am 31. März 2027, und der Dienst wird nach dem 30. Juni 2027 abgeschaltet — Ihre bestehenden Ressourcen laufen weiter. Beantworten Sie 5 kurze Fragen — YAML-, Jinja- oder Python-Templates; Composite Types, Type Providers oder Actions; wo Ihre Konfigurationen liegen; ob Sie sich auf DM-Preview oder -Rollback verlassen; und Infra Manager vs. selbstverwaltetes Terraform. Sie erhalten Konvertierbarkeit, eine Liste manueller Lücken, die Reihenfolge Convert → Import → Abandon und eine Regressions-Checkliste. Niemals Anmeldedaten, Service-Account-Keys, Projekt-IDs oder Konfigurationen einfügen.
GcpDmInfra ist ein unabhängiges Tool und steht in keiner Verbindung zu Google und wird nicht von Google unterstützt. · Kein GCP-Connector. Keine Anmeldedaten.
Problem
Laut Google Cloud „Deployment Manager deprecation“ wurde der Support am 1. April 2026 eingestellt — normale DM-Tickets werden automatisch abgelehnt, außer es sind Blocker oder Themen Ihrer Migration zu Infra Manager. Die maximale Support-Verlängerung endet am 31. März 2027. Nach dem 30. Juni 2027 wird der Dienst abgeschaltet und alle zugehörigen APIs enden. Mit Deployment Manager erstellte Ressourcen funktionieren weiter. Der offizielle Weg ist DM Convert (Preview) → Terraform-Import → Infra-Manager-Import → --delete-policy ABANDON — aber Composite Types, Actions ohne deklaratives Gegenstück und Custom Type Providers werden nicht konvertiert, und die Standard-Policy DELETE löscht die zugrunde liegenden Ressourcen dauerhaft.
deployments delete mit Standard-DELETE ausführen oder mit abweichendem State entsperren--delete-policy ABANDON| Datum | Status | Bedeutung |
|---|---|---|
| 1. Apr. 2026 | In Kraft | Support eingestellt (in Kraft). Normale DM-Tickets werden automatisch abgelehnt (außer Migrationsthemen oder Blocker). |
| 30. Juni 2026 | In Kraft | Neue Nutzer können die Deployment Manager V2 API nicht aktivieren oder ein erstes Deployment anlegen (Weiterleitung zu Infra Manager). |
| 31. März 2027 | Support | Maximale Support-Verlängerung endet. |
| Nach dem 30. Juni 2027 | Abschaltung | Deployment Manager wird abgeschaltet; alle zugehörigen APIs enden. Bestehende Ressourcen laufen weiter. |
Bis zur Abschaltung können Bestandskunden DM über die Console, die Google Cloud CLI und die Deployment Manager V2 API „auf eigenes Risiko“ nutzen — ohne neue Funktionen und ohne nicht kritische Fehlerbehebungen. Mit Deployment Manager erstellte Ressourcen funktionieren weiter und lassen sich mit Standard-Google-Cloud-Tools verwalten. App-Engine-Flex-Kunden ohne DM sind nicht betroffen.
Lösung
Eine Entscheidungsebene für die Migrationsbereitschaft Deployment Manager → Infra Manager / Terraform für Plattform- und IaC-Teams, die noch Deployment Manager nutzen: Ihre DM-Nutzung × erweiterte Funktionen × Konfigurationsablage × Abhängigkeiten × Ziel → Konvertierbarkeit + manuelle Lücken + Reihenfolge + Regressions-Checkliste. Kein Ersatz für die Google-Cloud-Doku, kein GCP-Connector und nicht mit Google verbunden.
Platform-Engineering-, IaC-/Terraform- und DevOps-/SRE-Teams sowie Cloud-Architekten, die GCP-Ressourcen noch mit Google Cloud Deployment Manager verwalten — YAML-Konfigurationen mit Jinja-/Python-Templates, gcloud deployment-manager und die Deployment Manager V2 API — und noch nicht zu Infrastructure Manager (Infra Manager) oder selbstverwaltetem Terraform gewechselt sind.
Der Support endete am 1. April 2026, die maximale Support-Verlängerung endet am 31. März 2027. Nach dem 30. Juni 2027 wird der Dienst abgeschaltet. Der offizielle Weg (DM Convert als Preview → Import in den Terraform-State → Infra-Manager-Import → ABANDON) hat Lücken: Composite Types, Actions ohne deklaratives Gegenstück und Custom Type Providers werden nicht konvertiert; privates Git braucht eine Cloud-Build-Verbindung; der State liegt in Cloud Storage; Rollback wird zum manuellen Roll-forward; und die Standard-Delete-Policy von DM ist DELETE.
5 Fragen ankreuzen → Konvertierbarkeit, eine Liste manueller Lücken, die Reihenfolge DM Convert → Terraform-Import → Infra-Manager-Import → Abandon (mit offiziellen Befehlen) und eine Regressions-Checkliste. Fragt nie nach GCP-Anmeldedaten, Service-Account-Keys, Projekt-/Organisations-IDs, DM-Konfigurationen oder Code; kein GCP-Connector.
Jedes Deployment ist nach Terraform konvertiert und von Infra Manager oder selbstverwaltetem Terraform übernommen und wird vor der Abschaltung nach dem 30. Juni 2027 mit --delete-policy ABANDON sicher aus DM gelöst — statt Produktionsressourcen mit dem Standard-DELETE zu löschen oder im Juli 2027 festzustellen, dass sich die Infrastruktur mit dem alten Tool nicht mehr aktualisieren lässt.
Funktionen
Marketingpunkte aus der Produkthypothese — zur Nachfragevalidierung, kein formales Spezifikationsversprechen.
Sie sind bereits bei „auf eigenes Risiko“. Brauchen Sie Hilfe von Google bei der Migration? Vor dem 31. März 2027. Alles muss vor der Abschaltung nach dem 30. Juni 2027 konvertiert, importiert und abandoned sein.
References, dependsOn, accessControl, iamMemberBinding werden konvertiert; Composite Types und Custom Type Providers nicht; Actions nur mit deklarativem Gegenstück.
Composite Types → Terraform-Module; privates Git → Cloud-Build-Verbindung; Rollback → manueller Roll-forward; Preview → Infra-Manager-Previews; kein Backend-Block; 2 Stunden Timeout beim Anwenden.
Expanded Config → DM Convert → Terraform-Import → Infra Manager lock / import-statefile / unlock / preview → --delete-policy ABANDON.
In einem Nicht-Produktionsprojekt proben, jeden terraform plan prüfen, „No changes“ im Infra-Manager-Preview bestätigen, abandonen und dann prüfen, dass die Ressourcen noch da sind.
| Ihre DM-Nutzung | DM Convert (Terraform) |
|---|---|
| Nur YAML, Jinja-, Python-Templates | Konvertiert — DM Convert liest YAML und Jinja-/Python-Templates; die expandedConfig lässt sich aus dem Manifest eines laufenden Deployments holen |
References, dependsOn | Terraform-References, depends_on |
accessControl (authoritative) | <resource_type>_iam_policy |
iamMemberBinding (non-authoritative) | <resource_type>_iam_member |
| Composite Types | Nicht konvertiert (veraltet) → Terraform-Module selbst schreiben |
Actions: insert / get / setIamPolicy | Werden zu Resource / data / *_iam_policy · *_iam_member |
| Actions: patch / delete / list, eigene APIs | Nicht konvertiert → manuell behandeln |
| Custom Type Providers | Nicht konvertiert (über ihre APIs definierte Actions ebenfalls nicht) |
| Unsicher bei einem Ressourcentyp | Offizielle Liste mit --list_supported_types prüfen |
DM Convert ist ein Preview-Tool. Es erzeugt Terraform-Konfiguration plus eine Datei mit Terraform-Importbefehlen (--output_tf_import_file); der Terraform-State entsteht erst, wenn Sie diese Importe ausführen. Bei der Konvertierung aus einer Expanded Config sind Template-Parameter und Schleifen bereits aufgelöst — um Wiederverwendbarkeit zu behalten, schreiben Sie sie selbst als Terraform-Variablen / -Module um (aus dem offiziellen Ablauf abgeleitet; nach der Konvertierung prüfen).
| DM-Konzept | Vorgehen in Infra Manager / Terraform |
|---|---|
| Composite Types / wiederverwendbare Templates | Terraform-Module (muss ein gültiges Root-Modul sein; Infra Manager unterstützt kein Templating / keine Generierung) |
| Konfigurationen in privatem Git | Zuerst Git-Host und Repository mit Cloud Build (oder dem Developer Connect Git proxy) verbinden, dann --git-source-repo verwenden |
| DM-interner State | Infra Manager speichert ihn automatisch in Cloud Storage; für selbstverwaltetes Terraform wird ein Cloud-Storage-Bucket empfohlen; Infra-Manager-Konfigurationen dürfen keinen Backend-Block definieren |
| DM-Rollback | Manueller Roll-forward mit der Terraform-Konfiguration einer früheren Revision |
| DM-Preview | gcloud infra-manager previews create (Terraform plan) |
| Große Deployments | Erstellen / Aktualisieren bricht nach 2 Stunden ab, Preview nach 1 Stunde → Konfiguration aufteilen |
Label goog-dm | Nach dem Import zeigt terraform plan das Entfernen des Labels goog-dm (laut offiziellem Beispiel akzeptabel) |
Privates Git funktioniert mit Infra Manager, sobald Git-Host und Repository mit Cloud Build verbunden sind — GitHub, GitHub Enterprise, GitLab, GitLab Enterprise oder der Developer Connect Git proxy. Die Deprecation-Seite beschreibt das als fehlende „direkte“ Unterstützung.
gcloud deployment-manager deployments describe DEPLOYMENT_NAME --format="value(deployment.manifest)"gcloud deployment-manager manifests describe MANIFEST_NAME --deployment DEPLOYMENT_NAME --format="value(expandedConfig)"--config deployment.yaml --output_format TF --output_file … --output_tf_import_file … --deployment_name … --project_id …terraform init, die erzeugte Importdatei ausführen, dann jede Abweichung im terraform plan prüfen.gcloud infra-manager deployments apply) → gcloud infra-manager deployments lock → import-statefile + terraform.tfstate hochladen → Konfiguration hochladen → prüfen, dass State und Konfiguration übereinstimmen → unlock → gcloud infra-manager previews create zeigt No changes.Stimmen State und Konfiguration nicht überein, legt Infra Manager beim unlock Ressourcen an oder löscht sie, um dem State zu entsprechen.
gcloud deployment-manager deployments delete DEPLOYMENT_NAME --delete-policy ABANDONNiemals die Standard-Policy DELETE verwenden — sie löscht die zugrunde liegenden Ressourcen dauerhaft.
Beispiele verwenden immer die Platzhalter PROJECT_ID / DEPLOYMENT_NAME — diese Seite nimmt keine IDs entgegen. Befehle und Flags wie in den Google-Cloud-Dokus zu DM Convert, Infra-Manager-Import und Deleting deployments.
So funktioniert's
Drei Schritte. Keine Verbindung zu Google Cloud, keine Anmeldedaten.
YAML, Jinja oder Python? Composite Types, Type Providers oder Actions? Wo liegen die Konfigurationen? Abhängig von DM-Preview oder -Rollback? Infra Manager oder selbstverwaltetes Terraform?
Konvertierbarkeit, Liste manueller Lücken und Zeitplanrisiko bis 31.3. / 30.6.2027 — jeweils mit Link zur Google-Cloud-Doku.
Die offizielle Reihenfolge — DM Convert → Terraform-Import → Infra-Manager-Import → --delete-policy ABANDON — plus Regressions-Checkliste. Keine Anmeldedaten, Keys, IDs oder Konfigurationen.
Anwendungsfälle
Wenn Ihnen diese Situationen bekannt vorkommen, tragen Sie sich in die Warteliste ein und helfen Sie bei der Validierung.
Composite Types werden nicht konvertiert — Sie brauchen eine Liste selbst zu schreibender Terraform-Module und Vergleichsschritte.
Das Konvertierungsergebnis sind die aufgelösten Ressourcen — entscheiden, ob in Module / Variablen refaktoriert wird, und wegen des 2-Stunden-Timeouts von Infra Manager aufteilen.
Infra Manager braucht zuerst eine Cloud-Build-Verbindung — Sie brauchen die Checkliste der Vorbedingungen.
Umstieg auf Infra-Manager-Previews und ein Roll-forward-Runbook nötig.
Zwischen Infra Manager und selbstverwaltetem Terraform entscheiden (State in Cloud Storage, Ausführung in Cloud Build) und Convert → Import → Abandon pro Deployment in Batches planen.
Wissen, welche Actions zu Resource / data werden und welche manuell behandelt werden müssen.
Öffentliche Signale
Nur offizielle Google-Cloud-Dokumentation — öffentliche Signale, keine Empfehlungen. Keine Kundenzitate, Logos oder erfundenen Kennzahlen.
FAQ
Nein. GcpDmInfra ist unabhängig und steht in keiner Verbindung zu Google. Alle Angaben zitieren die offizielle Google-Cloud-Doku mit Link.
Laut Google-Cloud-Doku funktionieren mit Deployment Manager erstellte Ressourcen weiter und lassen sich mit Standard-Google-Cloud-Tools verwalten — nur nicht mehr mit Deployment Manager oder gcloud deployment-manager.
Am 31.3.2027 endet die maximale Support-Verlängerung. Nach dem 30.6.2027 wird der Dienst abgeschaltet und alle zugehörigen APIs enden. Der Support selbst endete am 1.4.2026.
Nein. Composite Types werden nicht konvertiert, Actions nur mit deklarativem Gegenstück, Custom Type Providers nicht. DM Convert ist außerdem ein Preview-Tool.
Ja, sobald Git-Host und Repository mit Cloud Build verbunden sind (laut Infra-Manager-Deploy-Doku). Die Deprecation-Seite beschreibt das als fehlende „direkte“ Unterstützung.
Mit --delete-policy ABANDON. Die Standard-Policy DELETE löscht die zugrunde liegenden Ressourcen dauerhaft.
Nein. Niemals fordern, halten oder speichern. Keine Verbindung zu Ihren Google-Cloud-Projekten.
Nein. Das MVP ist ein statischer Fragebogen + Listen + Reihenfolge + Warteliste.
Wartelisten-Einladungen per E-Mail in Batches. Kein gefälschtes Launch-Datum.
GcpDmInfra ist ein unabhängiges Tool und steht in keiner Verbindung zu Google und wird nicht von Google unterstützt.
Warteliste
Hinterlassen Sie Ihre geschäftliche E-Mail für Early Access und Launch-Infos zu GcpDmInfra. Nur E-Mail plus optionale Checkboxen und Auswahllisten — dieses Formular hat kein Freitextfeld.
Wir senden Early-Access-Einladungen und Launch-Updates in Batches per E-Mail (kein zugesagtes Launch-Datum). Prüfen Sie Ihr Postfach auf eine Bestätigungs-Mail, falls aktiviert. Jederzeit abmeldbar.