cloud-init ist der De-facto-Standard, um Cloud-Instanzen beim ersten Start zu initialisieren. Wenn Sie eine Instanz starten und ihr ein user-data-Skript übergeben, ist es cloud-init, das dieses interpretiert und ausführt: Es legt Benutzer an, schreibt Dateien, installiert Pakete, hängt Datenträger ein oder startet Dienste.
Die ideale Kombination ist klar: Das Golden AMI enthält, was sich nicht ändert —Betriebssystem, Runtime, Hardening— und user-data liefert, was je Umgebung oder Instanz variiert: Konfiguration, injizierte Secrets, Rolle. So nutzen Sie ein einziges Image in vielen Kontexten.
Zwei Arten, user-data zu schreiben
user-data unterstützt mehrere Formate; die beiden häufigsten sind das Shell-Skript und cloud-config.
- Shell-Skript: beginnt mit
#!/bin/bash. Einfach und direkt für schnelle Aufgaben. - cloud-config: beginnt mit
#cloud-configund nutzt deklaratives YAML. Sauberer, lesbarer und idempotenter, um Benutzer, Pakete, Dateien und Befehle zu konfigurieren.
Beispiel für cloud-config
Ein typisches #cloud-config deklariert Abschnitte wie packages: (zu installierende
Pakete), write_files: (Konfigurationsdateien), runcmd: (abschließende Befehle) und
users: (Konten und Schlüssel). Da es deklarativ ist, lässt es sich leichter prüfen und
pflegen als ein langes Skript.
Bewährte Praktiken
- Halten Sie user-data klein: Wird es zu groß, gehört das vermutlich ins AMI gebacken.
- Idempotenz: Entwerfen Sie Befehle so, dass ein erneutes Ausführen nichts kaputt macht.
- Niemals Secrets im Klartext in user-data: Es ist über die Instanz-Metadaten lesbar. Injizieren Sie sie zur Laufzeit aus Secrets Manager, Parameter Store oder Vault.
- Schützen Sie den Metadatenzugriff: Nutzen Sie IMDSv2, um Diebstahl von Zugangsdaten über SSRF zu erschweren.
- Protokollieren und debuggen: Die cloud-init-Logs
(
/var/log/cloud-init-output.log) sind Ihr bester Freund, wenn etwas schiefgeht.
Backen oder Booten: was gehört wohin
| Gehört ins AMI (Baking) | Gehört in user-data (Booting) |
|---|---|
| Betriebssystem und Patches | Umgebungsspezifische Konfiguration |
| Runtime, Agenten und Hardening | Variablen und Parameter je Instanz |
| Stabile, schwere Software | Cluster-Registrierung und Discovery |
| Alles, was lange zu installieren dauert | Secret-Injektion zur Laufzeit |
Goldene Regel: Das Stabile und Langsame wird gebacken; das Variable und Leichte kommt beim Start.
Häufige Fehler, die Stunden kosten
- In user-data stecken, was ins Image gehört – mit langsamen, fragilen Starts als Folge.
- Secrets im Klartext in den Metadaten offenlegen.
- Annehmen, user-data laufe bei jedem Start erneut: Standardmäßig läuft es nur beim ersten.
- Die cloud-init-Logs nicht ansehen, wenn die Instanz „nicht tut, was sie soll".
Häufig gestellte Fragen
Läuft user-data bei jedem Neustart?
Standardmäßig nur beim ersten Start. Man kann cloud-init so konfigurieren, dass bestimmte Teile bei jedem Start laufen – aber bewusst und idempotent.
Ist es sicher, Passwörter in user-data zu übergeben?
Nein. user-data ist über die Instanz-Metadaten lesbar. Nutzen Sie einen Secrets-Manager und injizieren Sie zur Laufzeit; schützen Sie die Metadaten mit IMDSv2.
Funktioniert cloud-init nur in AWS?
Nein. cloud-init ist plattformübergreifend und läuft in AWS, Azure, GCP und anderen – ideal, um den Start portabel zu automatisieren.
Bei imaxe.cloud entwerfen wir Images, die sich mit cloud-init kombinieren lassen, damit ein einziges AMI Ihnen in vielen Szenarien dient.
