Dieses Kapitel erklärt kompakt, warum Cloud-Init in modernen Server-Images als Methode zur frühen Initialisierung einen Standard für reproduzierbare configuration setzt. Die Lösung ist seit release 18.04 in vielen images vorinstalliert und automatisiert Locale, Hostname und SSH‑Keys.
Sie lernen, wie user data als content oder file an eine instance übergeben wird, damit beim start deterministische Schritte ausgeführt werden. Dabei hilft die documentation, das richtige format und die passende syntax zu wählen.
Kurze code‑examples zeigen typische Einsätze. Bash-Beispiel:
#!/bin/bash
echo "preset user" > /etc/motd
Shell-Beispiel als cloud-config alternative:
#cloud-config
users:
- name: demouser
Am Ende verstehen Sie, welche information das system beim boot nutzt und wie configuration die Lebenszyklen von Instanzen beeinflusst. Praxisnahe examples und Version-Hinweise helfen beim Start.
Warum wiederholbare Provisionierung mit Cloud-Init zählt
Wiederholbare Provisionierung sorgt dafür, dass Server bei jedem Start identisch eingerichtet werden. Das reduziert Fehlkonfigurationen und beschleunigt die Zeit bis zum produktiven Einsatz.
Die Actions laufen einmalig beim ersten Boot einer Instance; ein einfacher Reboot triggert sie nicht erneut. Bei Änderungen an kritischen Konfigurationsschlüsseln kann LXD die Instance-ID anpassen, sodass die aktualisierte Konfiguration wie beim Erststart angewendet wird.
Definierte configuration in data und content schafft eine konsistente Systembasis mit klaren default‑Werten. So bleibt die Betriebssicherheit hoch, weil manuelle Eingriffe entfallen.
Die offizielle documentation liefert Beispiele für package upgrade, das Anlegen von user und das Ausführen von runcmd. Teams profitieren von planbarer SSH‑Key‑Verwaltung und identischer Paketbasis pro instance.
Durch die strikte Trennung von Build‑images und Laufzeit‑configuration minimieren Sie Drift und sparen Zeit im Lifecycle. Images liefern die Baseline, user data definiert den Zielzustand; die Methode setzt beides deterministisch um.
Grundlagen und Voraussetzungen
Im Folgenden sehen Sie, welche Parameter eine frisch gestartete instance typischerweise automatisch erhält. Das umfasst Basiswerte, Artefakte und die erwarteten Orte im Dateisystem.
Beim first boot setzt das Initial-Skript Locale und Hostname. Es erzeugt private SSH-Schlüssel und fügt öffentliche keys in ~/.ssh/authorized_keys ein, damit sich user sicher anmelden können.
Ephemere Mountpoints werden angelegt und die configuration für Netzwerk gerendert. Je nach version wird die network-Definition auf ifupdown oder Netplan gemappt; entsprechende Dateien landen im directory /etc/network/interfaces.d oder /etc/netplan.
Unterstützte images umfassen Live-Server seit release 18.04, Cloud Images und offizielle EC2-Varianten. In LXD wählen Sie je nach source image cloud-init.* oder user.* Optionen; die documentation erklärt die Unterschiede zu älteren Serien.
Artefakte, Logs und Status liegen im directory /var/lib/cloud, was Debugging und Nachvollziehbarkeit erleichtert. Die Übergabe von file oder content erfolgt in definiertem format (#cloud-config, Script, MIME), wodurch die configuration reproduzierbar bleibt.
Ein kurzes example wäre: Paketaktualisierung, Anlage von users mit default-Gruppen, SSH-Key-Injektion und statische IP per Netplan in einer einzigen data-Datei. Achten Sie auf owner und Berechtigungen, ein falscher key-Owner verhindert oft die Anmeldung.
User-Data-Formate im Überblick: von #cloud-config bis Boothook
Hier lernen Sie die gängigen Methoden kennen, um user data in vielfältigen Formaten zuverlässig an eine instance zu liefern.
Das zentrale Format ist die cloud-config: eine YAML-Datei, die mit „#cloud-config“ beginnt. Sie erlaubt deklarative configuration für packages, users, runcmd und Netzwerke.
User-data Skripte starten als Shebang-Scripts sehr spät im Boot-Prozess und eignen sich für imperative command-Abfolgen, die sich nicht gut in YAML ausdrücken lassen.
MIME Multipart bündelt mehrere file-Typen in einer user-data (z. B. config plus Script oder Upstart-Job). Das Tool write-mime-multipart hilft beim Erstellen solcher Payloads.
Gzip-Kompression umgeht das typische Größenlimit (16.384 Byte); der Inhalt wird beim Boot automatisch entpackt und als data-artefakt abgelegt.
Include-Dateien und entfernte Quellen
Include-Einträge verweisen auf source-URLs. Inhalte werden rekursiv geladen und können gzip, multipart oder plain text sein.
Boothook, Upstart und Part-Handler
Boothooks (#cloud-boothook) laufen extrem früh beim first boot und erhalten INSTANCE_ID. Sie müssen idempotent sein.
#upstart-job legt Jobs nach /etc/init, #part-handler erlaubt Python-basierte Handler mit list_types/handle_type. Artefakte und Logs finden Sie im directory /var/lib/cloud/data, was Debugging und Nachvollziehbarkeit erleichtert.
Cloud-Init Ubuntu in der Praxis: User-Data schreiben und anwenden
Praxisnah zeigen wir, wie Sie User‑Data für verschiedene Plattformen korrekt erstellen und an eine neue instance übergeben. Die folgenden Hinweise helfen bei Launch, Prüfung und Debugging.
Ubuntu Cloud Images / EC2: User-Data beim Launch
Auf EC2 übergeben Sie user data als file oder Inline‑Text beim Launch. Beginnen Sie YAML‑Payloads mit #cloud-config, um apt_upgrade und runcmd deklarativ zu nutzen.
Scripts laufen rc.local‑like und eignen sich für imperative command‑Abfolgen. Prüfen Sie nach dem Start Logs und führen Tests für packages und locale aus.
LXD / LXC: user-data, vendor-data und network-config setzen
In LXD setzen Sie configuration per config‑Schlüssel: cloud-init.user-data, cloud-init.vendor-data und cloud-init.network-config. Bei älteren images verwenden Sie user.* keys.
YAML im Literalstil (|) reduziert Einrückungsfehler. Beispiel: lxc config set <instance_name> cloud-init.user-data – < cloud-init.yml. Danach cloud-init status –wait nutzen, um den Abschluss beim boot zu prüfen.
WSL 2: user-data vorab ablegen
Unter Windows legen Sie in C:\Users\\.cloud-init\ die Datei Ubuntu-24.04.user-data mit #cloud-config ab. Beim ersten Start (z. B. ubuntu2404.exe) wird die instance automatisch provisioniert.
Validieren Sie schema mit cloud-init schema –system und testen Sie nach dem Login packages, locale und SSH‑keys.
Konfigurationsbeispiele für wiederholbare Setups
Praktische Beispiele zeigen, wie deklarative und imperative Anweisungen eine instance in wenigen Schritten reproduzierbar konfigurieren.
Pakete aktualisieren und installieren
Aktivieren Sie package_upgrade: true und definieren Sie packages als list, etwa git und openssh-server. So führt die user data beim first boot ein Upgrade durch und installiert Basis‑packages.
Benutzer anlegen und SSH Keys injizieren
Definieren Sie users mit name, Gruppen und default Shell. Fügen Sie ssh_authorized_keys ein, damit die public keys beim Boot landen und Login möglich wird.
Befehle und Skripte ausführen
runcmd akzeptiert eine list von commands. Ein einfacher Eintrag wie – [touch, /run/cloud.init.ran] erzeugt ein Markerfile als output für Prüfschritte.
Netzwerk per Netplan / ifupdown
Liefern Sie network-config im NoCloud- oder Plattform-Format. Beim Boot wird das Ergebnis nach /etc/network/interfaces.d/50-cloud-init.cfg oder /etc/netplan/50-cloud-init.yaml gerendert.
Dateien schreiben, Services aktivieren, Quellen hinzufügen
write_files ermöglicht das Anlegen von file content, System‑Units oder Repo‑Quellen mit Besitz und Berechtigungen (root). Kombinieren Sie mehrere Schritte in einer einzigen data‑Datei für deterministische images.
Prüfen Sie die erzeugten Artefakte in /var/lib/cloud/instance (cloud-config.txt, user-data.txt). Testen Sie boot und Neustart und stimmen Sie upgrade‑Strategie auf Wartungsfenster ab.
Validieren, beobachten, debuggen: sicher zur gewünschten Konfiguration
Sorgfältige Validierung und gezieltes Monitoring sorgen dafür, dass die gewünschte configuration zuverlässig erreicht wird. Kurze Prüfschritte helfen, Probleme früh zu erkennen und die Zeit bis zur Fehlerbehebung zu verkürzen.
Status prüfen und warten
Prüfen Sie den Status mit dem command cloud-init status; die Ausgabe zeigt etwa „running“ oder „done“.
Nutzen Sie cloud-init status –wait, um bis zum Abschluss der configuration pro instance zu warten. So starten nachfolgende commands erst, wenn die Initialisierung fertig ist.
Logs und Artefakte
Kontrollieren Sie das directory /var/lib/cloud/instance auf wichtige files wie cloud-config.txt und user-data.txt. Bei MIME oder gzip finden Sie auch user-data.txt.gz oder user-data.txt.i.
Die Konsolenausgabe und Logs geben output zu syntax-, packages- oder Berechtigungsproblemen. Halten Sie details zu keys und Pfaden bereit, falls ssh-Anmeldung fehlschlägt.
First‑boot-Logik und erneutes Anwenden
Die first boot Logik entscheidet, ob configuration wiederholt ausgeführt wird. In LXD erzeugt eine neue Instance-ID ein erneutes Anwenden der data, nützlich nach config-Änderungen.
Fassen Sie Prüfungen in einer kurzen list von commands zusammen, dokumentieren Sie version und time, und nutzen Sie die documentation als Referenz für Syntax und Beispiele.
Best Practices und nächste Schritte für robuste Automatisierung
Mit klaren Regeln für vendor‑data und user‑data vermeiden Sie Drift und Konflikte. Legen Sie vendor‑data in LXD‑Profilen als Baseline ab und nutzen user‑data für instanzspezifische Anpassungen.
Definieren Sie Merge‑Strategien für keys und ssh keys, dokumentieren Pfade, owner (root) und file‑Berechtigungen. Nach jeder instance created führen Sie automatische Prüfungen aus: schema‑Validierung, apt‑Listen und installierte package prüfen oder kurze run commands ausführen.
In WSL 2 legen Sie die user‑datei vor dem Registrieren ab. Speichern Sie wiederverwendbare text‑Snippets in einem Repo und beachten license‑Hinweise externer Tools wie vcpkg. Planen Sie time für Reviews und Schlüsselrotation, und testen Änderungen in Canary‑instances.
