Provisioning-Agents für den ersten Windows-Start in der Cloud: EC2Launch v2, Azure VM Agent und cloudbase-init

Worum es geht

Cloud-Anbieter bieten für neue Windows-Instanzen eine Möglichkeit, beim ersten Start Konfigurationen auszuführen. Diese wird als Textblock (Skript oder strukturierte Konfiguration) beim Erstellen der Instanz mitgegeben und von einem Agenten gelesen, der bereits im Image enthalten ist.

AWS: Der Agent EC2Launch v2, von AWS dokumentiert als Software, die "to perform tasks during EC2 Windows instance launch" dient, führt die User Data der Instanz aus (PowerShell-/Batch-Skripte oder YAML-Aufgabenlisten). Er ist der Standard-Agent der AWS-AMIs für Windows Server 2022 und 2025; AWS veröffentlicht ihn auch in AMIs für 2016/2019. Ältere AMIs für 2016/2019 verwenden EC2Launch v1, AMIs vor 2016 verwenden EC2Config. Bei eigenen AMIs Sysprep über EC2Launch v2 ausführen (über dessen Einstellungswerkzeug oder mit EC2Launch.exe sysprep), damit neben Windows auch der Zustand des Agenten zurückgesetzt wird.

Azure: Der Azure Windows VM Agent (im Task-Manager als Prozess WindowsAzureGuestAgent.exe sichtbar) führt VM-Erweiterungen aus und ist optional; für den Start genügt der separate Provisioning-Agent. Unter Windows werden Azure-Custom Data nach %SystemDrive%\AzureData\CustomData.bin geschrieben, "aber nicht verarbeitet". Sie werden daher nur ausgeführt, wenn das Image Code enthält, der sie liest, oder wenn stattdessen die Custom Script Extension verwendet wird. User Data sind über den Instance Metadata Service während der gesamten Lebensdauer der VM abrufbar. Unter Linux verarbeitet cloud-init Custom Data standardmässig, während der Linux VM Agent (waagent) dies nur tut, wenn in einem benutzerdefinierten Image Provisioning.ExecuteCustomData aktiviert ist.

Andere Clouds und lokale Private Clouds: Viele Windows-Cloud-Images ausserhalb von AWS und Azure liefern stattdessen cloudbase-init aus, einen Open-Source-Agenten. Seine Dokumentation beschreibt ein User-Data-Format #cloud-config als "Cloud-config YAML configuration as supported by cloud-init, excluding Linux specific content". Damit gibt es eine gemeinsame Konfigurationsschnittstelle über ansonsten unterschiedliche Cloud-Plattformen hinweg.

Warum es wichtig ist

Wenn eine Windows-Instanz ohne die erwartete Konfiguration startet, hängt die Behebung davon ab, zu wissen, welcher dieser Agenten vorhanden ist und wo er protokolliert. Denn bei keinem von ihnen führt ein fehlgeschlagenes User-Data-Skript zuverlässig zu einem fehlgeschlagenen Start.

So wird es angewendet

• Auf AWS: %ProgramData%\Amazon\EC2Launch\log\agent.log auf Status und Fehler des Agenten prüfen, gemäss der AWS-Anleitung zur Fehlerbehebung bei EC2Launch v2.
• Auf Azure unter Windows: sicherstellen, dass der Prozess WindowsAzureGuestAgent.exe läuft, und anschliessend die Agent- und Erweiterungs-Logs unter C:\WindowsAzure\Logs prüfen (WaAppAgent.log, Plugins\).
• Auf Azure unter Linux: /var/log/waagent.log (waagent) und bei cloud-init-Images zusätzlich /var/log/cloud-init.log und cloud-init-output.log prüfen.
• Auf cloudbase-init-Images: im konfigurierten Log-Verzeichnis (über die Option log_dir in der eigenen Konfigurationsdatei von cloudbase-init festgelegt) nach Fehlern bei der Ausführung der User Data suchen.
• Auf Azure Custom Data für eine Nutzlast verwenden, die einmalig bei der Provisionierung verarbeitet wird, und User Data, wenn sie abrufbar und ohne Reimaging änderbar bleiben müssen. Die Custom Data einer einzelnen VM lassen sich nach der Erstellung nicht mehr ändern.

Stolpersteine

• Annehmen, ein Windows-Image verhalte sich wie ein Linux-Image mit cloud-init: Agent, Log-Pfade und unterstützte User-Data-Formate unterscheiden sich je nach Plattform und danach, welchen Agenten das jeweilige Image mitbringt.
• Eine fehlende Logdatei als "es wurde nichts übergeben" deuten statt als "der Agent ist nicht installiert oder nicht der erwartete": Zuerst klären, welcher Agent (falls überhaupt) vorhanden ist, bevor man schliesst, die User Data seien leer gewesen.
• Erwarten, dass eine Windows-VM auf Azure Custom Data von selbst ausführt, oder einen erfolgreichen Provisionierungsstatus unter Linux als Beweis dafür werten, dass das Custom-Data-Skript funktioniert hat: Laut Microsoft lassen Skriptfehler die Provisionierung nicht fehlschlagen.