Google Cloud ersetzt VM-Startskripte: Extension Manager ist jetzt allgemein verfügbar
Google Cloud erklärte VM Extension Manager am 4. September 2026 für allgemein verfügbar. Die Ankündigung von Google Cloud verspricht deklarative, projektweite Richtlinien anstelle eigener Startskripte für die Verwaltung von Gasterweiterungen auf Compute-Engine-VMs.
Der am 4. September 2026 bekannt gegebene GA-Status gilt für die richtlinienbasierte Verwaltung unterstützter Erweiterungen, nicht für beliebigen Code beim VM-Start. Eine am 7. September veröffentlichte unabhängige Zusammenfassung des Produktstarts bestätigt den Status sowie Drift-Erkennung, Selbstheilung, gestufte Verteilung und Rollback als zentrale Betriebsfunktionen.
Was GA gegenüber der Vorschau bedeutet
Mit der allgemeinen Verfügbarkeit wird aus der Vorschaufunktion ein regulär verfügbares Angebot. Der zentrale Ansatz bleibt: Administratoren beschreiben den gewünschten Zustand einer Erweiterung in einer Richtlinie, während VM Extension Manager Installation, Aktualisierung und laufende Zustandskontrolle übernimmt.
Google fasst dabei mehrere Funktionen zu einem Betriebsmodell zusammen. Globale und zonale Richtlinien können passende vorhandene VMs sowie später angelegte Instanzen erfassen. Erkennt der Dienst eine Abweichung vom vorgegebenen Erweiterungszustand, soll die Selbstheilung die VM wieder in den deklarierten Zustand bringen; der Flottenstatus lässt sich zentral über Cloud Monitoring verfolgen.
Der Statuswechsel bedeutet nicht, dass jede genannte Funktion erst am 4. September eingeführt wurde. Neu ist die Freigabe des Gesamtangebots für den allgemeinen Einsatz. Für Betriebsteams sinkt damit das Produktrisiko einer Vorschau, die fachliche Grenze des Dienstes bleibt jedoch bestehen.
Startskript und Richtlinie im Vorher-nachher-Vergleich
Der im Titel versprochene Ersatz ist konkret, aber nicht vollständig: VM Extension Manager nimmt Betriebsteams den selbst geschriebenen Installations- und Aktualisierungscode für unterstützte Gasterweiterungen ab. Er ist kein allgemeiner Ersatz für frei programmierbare Startskripte.
- Installation und Aktualisierung unterstützter Erweiterungen: Statt auf jeder Ziel-VM eigenen Start-Code auszuführen, legt eine Richtlinie Erweiterung, Konfiguration, Version und Auswahlkriterien fest.
- Kontrolle des laufenden Zustands: Bei Skripten muss das Betriebsteam Prüfungen und Korrekturen selbst bauen. Der Manager überwacht verwaltete Erweiterungen und behandelt Abweichungen über sein Richtlinienmodell.
- Neue passende VMs: Eine Richtlinie gilt auch für später erstellte Instanzen, wenn diese ihre Auswahlkriterien erfüllen.
- Allgemeine Provisionierung: Eigene Pakete, Anwendungsbereitstellung, beliebige Shell-Befehle und Erweiterungen außerhalb der Unterstützungsliste bleiben Aufgabe anderer Automatisierungswege.
Für eine Migration muss deshalb nicht das Startskript als Ganzes, sondern jeder seiner Bestandteile betrachtet werden. Ein gemischtes Skript kann teilweise entfallen, wenn es beispielsweise einen unterstützten Agenten installiert; seine übrige System- oder Anwendungskonfiguration bleibt bestehen.
Globale Rollouts senken das Risiko, bleiben aber projektgebunden
Zonale Richtlinien steuern Erweiterungen in einer einzelnen Zone. Globale Richtlinien verteilen denselben gewünschten Zustand über Zonen und Regionen innerhalb eines Projekts. Für mehrzonige Änderungen nennt Google gestufte Rollouts und ein automatisches Rollback, wenn eine Rollout-Phase fehlschlägt.
Dieses Rollback schützt die Richtlinienausrollung. Es ist weder ein VM-Backup noch eine Zusage, beliebige frühere Änderungen im Gastbetriebssystem rückgängig zu machen. Veränderungen, die ein eigenes Skript oder ein Administrator außerhalb der verwalteten Erweiterung vorgenommen hat, fallen nicht unter dieses Versprechen.
Auch „global“ bezeichnet keine organisationsweite Steuerung. Die Verwaltungsgrenze bleibt das jeweilige Google-Cloud-Projekt. Wer identische Regeln über Entwicklungs-, Produktions- oder Mandantenprojekte verteilen will, benötigt weiterhin eine übergeordnete Automatisierung für das Anlegen und Abgleichen dieser Richtlinien.
Unterstützung, Betriebssysteme und Quote begrenzen die Migration
Die Compute-Engine-Produktdokumentation führt drei verwaltbare Erweiterungen auf: Ops Agent, Extension for SAP mit Google Cloud's Agent for SAP sowie Extension for Compute Workload mit Agent for Compute Workloads. Benötigte APIs müssen im Projekt der VMs aktiviert sein; eine feste Versionsbindung unterstützt der Dienst nur beim Ops Agent. Ubuntu und SUSE Linux Enterprise Server sind laut derselben Dokumentation derzeit nicht verfügbar.
Die Quote beträgt höchstens 100 VM-Erweiterungsrichtlinien pro Projekt und Zone. Für die Anzahl der VMs, die eine Richtlinie auswählen kann, nennt Google dagegen kein Limit. Das spricht für gemeinsam verwendete Richtlinien mit klaren Auswahlkriterien und gegen eine eigene Regel für jede einzelne Instanz.
Für VM Extension Manager selbst fällt laut Dokumentation keine Gebühr an; Kosten der installierten Erweiterungen können dennoch entstehen. Damit steht zum GA-Start ein verwalteter Ersatz für jene Startskripte bereit, die unterstützte Gasterweiterungen installieren und konsistent halten. Projektübergreifende Steuerung, nicht unterstützte Betriebssysteme und allgemeine Boot-Automatisierung bleiben außerhalb seines Umfangs.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.