Google Cloud ersetzt VM-Startskripte – Richtlinien reparieren Abweichungen selbst
Google Cloud hat den VM Extension Manager am 4. September 2026 als allgemein verfügbar hervorgehoben. Seine Richtlinien ersetzen eigene Startskripte bei der Verwaltung unterstützter Compute-Engine-Gasterweiterungen und gleichen Abweichungen vom gewünschten Zustand automatisch aus; die Google-Cloud-Wochenübersicht nennt außerdem gestaffelte Rollouts und automatische Rücknahmen bei fehlgeschlagenen Rollouts.
Die technische Freigabe erfolgte bereits am 14. August 2026, wie eine am 20. August veröffentlichte unabhängige Zusammenfassung der Cloud-Updates festhält. Der 4. September ist damit das Datum der hervorgehobenen Produktmeldung, nicht der erste Tag der allgemeinen Verfügbarkeit. Für Administratoren bleibt die entscheidende Einschränkung dieselbe: Der Manager ersetzt nur jene Startskripte, deren Aufgabe in seinen eng umrissenen Erweiterungskatalog passt.
Richtlinien halten den Erweiterungszustand dauerhaft fest
Der VM Extension Manager verwaltet optionale Plug-ins des Compute-Engine-Gast-Agenten. Eine Richtlinie legt fest, welche Erweiterung auf ausgewählten bestehenden und künftigen VMs installiert sein soll; die Auswahl kann unter anderem über VM-Labels erfolgen. Anders als ein Skript, das beim Start Befehle ausführt, beschreibt die Richtlinie einen fortdauernd gewünschten Zustand.
Darin liegt die Grundlage für das Versprechen im Titel. Wird die verwaltete Erweiterung entfernt oder weicht ihr Zustand von der Richtlinie ab, soll die kontinuierliche Drift-Erkennung die Abweichung feststellen und die Selbstheilung den deklarierten Zustand wiederherstellen. Das ist keine Reparatur beliebiger VM-Probleme: Betriebssystem, Anwendungscode, Benutzerkonten und Software außerhalb der unterstützten Erweiterungen werden dadurch nicht automatisch korrigiert.
Globale Richtlinien können Änderungen in Wellen über mehrere Zonen verteilen. Google bewirbt für fehlgeschlagene Rollouts eine automatische Rücknahme, veröffentlicht in der kurzen Produktmeldung jedoch weder konkrete Fehlerschwellen noch eine Garantie, dass dadurch jede lokale Störung vollständig behoben wird. Selbstheilung einer abweichenden VM und Rollback einer Richtlinienänderung sind daher zwei unterschiedliche Mechanismen.
Startskript, Extension Manager oder Konfigurationsmanagement?
Der zugespitzte Ersatz von Startskripten trifft nur auf deren Erweiterungsanteil zu. Installiert ein Skript beispielsweise eine unterstützte Monitoring-Erweiterung und hält deren vorgegebene Konfiguration bereit, kann eine Richtlinie diese Verantwortung übernehmen. Startet es dagegen eine Anwendung, legt lokale Benutzer an oder richtet beliebige Pakete und Dienste ein, bleibt diese Logik außerhalb des Extension Managers.
- VM Extension Manager: geeignet für Installation, Aktualisierung, Entfernung und Zustandskontrolle ausdrücklich unterstützter Gasterweiterungen über eine Compute-Engine-Flotte.
- Startskript: weiterhin passend für VM-spezifische Befehle, die beim Booten ausgeführt werden müssen und nicht durch eine unterstützte Erweiterung abgedeckt sind.
- Konfigurationsmanagement oder OS-Richtlinien: sinnvoll für umfassendere Betriebssystemzustände, Dateien, Pakete, Konten, Dienste und bedingte Abläufe.
- Vorgefertigtes Image: die bessere Wahl, wenn Software reproduzierbar schon vor dem ersten Start auf dem Boot-Datenträger liegen muss.
Die Migrationsfrage lautet deshalb nicht, ob eine VM ein Startskript besitzt, sondern welche Aufgaben dieses Skript erfüllt. Ein gemischtes Skript muss aufgeteilt werden: Nur die Verwaltung kompatibler Erweiterungen wandert in eine Extension-Richtlinie. Der übrige Teil braucht weiterhin ein separates Automatisierungsverfahren.
Drei Erweiterungen, Projektebene und ein festes Richtlinienlimit
Die am 26. August aktualisierte Produktdokumentation zum VM Extension Manager nennt drei unterstützte Erweiterungen — Ops Agent, Extension for SAP und Extension for Compute Workload —, schließt Ubuntu und SUSE Linux Enterprise Server aus, begrenzt Richtlinien auf die Projektebene und erlaubt höchstens 100 Richtlinien je Projekt und Zone; die Zahl der von einer Richtlinie ausgewählten VMs ist dagegen nicht begrenzt.
Die jeweilige Erweiterung bestimmt zusätzlich, welche Betriebssysteme tatsächlich unterstützt werden. Auch die erforderlichen APIs müssen im Projekt der VMs aktiviert sein. Eine formal gültige Richtlinie kann deshalb bei der Installation scheitern, wenn die API- oder Betriebssystemvoraussetzungen fehlen.
Versions-Pinning steht nur für den Ops Agent zur Verfügung. Der Manager selbst verursacht laut Dokumentation keine separate Gebühr, installierte Erweiterungen können jedoch kostenpflichtige Dienste oder Telemetrie nutzen. Beim Löschen einer Richtlinie entfernt der Manager die durch sie installierten Erweiterungen; vor einer Migration ist deshalb zu klären, ob noch eine andere Richtlinie denselben Zielzustand vorgibt.
Der Migrationsnutzen ist real, aber schmaler als der Titel klingt
Für eine vorhandene Flotte ist der größte Gewinn nicht die erstmalige Installation, sondern die zentrale Durchsetzung danach. Bestehende und neu hinzukommende VMs können über dieselben Auswahlkriterien erfasst werden, ohne dass Administratoren jede Instanz einzeln verbinden oder ein Installationsskript dauerhaft pflegen müssen. Cloud Logging und Cloud Monitoring liefern dabei eine zentrale Sicht auf Richtlinienzustände und Flottengesundheit.
Eine kontrollierte Ablösung beginnt mit der Trennung der Verantwortlichkeiten im vorhandenen Startskript. Zuerst werden nur Abschnitte identifiziert, die eine der drei unterstützten Erweiterungen installieren oder verwalten. Danach lässt sich die Richtlinie auf eine begrenzte, kompatible VM-Gruppe anwenden; der entsprechende Skriptabschnitt sollte erst entfallen, wenn der gewünschte Zustand dort erreicht wird, damit nicht zwei Verfahren dieselbe Erweiterung steuern.
Allgemein verfügbar ist somit eine Flottensteuerung für einen klar begrenzten Katalog von Google-Erweiterungen, kein universeller Ersatz für Boot-Automatisierung. Bestätigt sind deklarative zonale und globale Richtlinien, Drift-Erkennung, Selbstheilung sowie gestaffelte Rollouts mit automatischer Rücknahme bei Fehlern. Für Ubuntu, SLES, beliebige Gastsoftware und Richtlinien oberhalb einzelner Projekte bleibt andere Automatisierung erforderlich; detaillierte öffentliche Schwellenwerte für das automatische Rollback fehlen weiterhin.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.