# Cloud-Init Masterclass: Automatisierung bis ins Detail

TL;DR / Management Summary Cloud-init ist das Standardwerkzeug für die “Last-Mile” Provisionierung von VMs. Es transformiert ein generisches OS-Image in einen spezifischen Node (z.B. ein Kubernetes-Worker mit fester IP und SSH-Keys). Während Grundlagen einfach sind, liegt die Macht im Detail: Network-Config V2, das Schreiben von Dateien via write_files und die präzise Steuerung der Boot-Phasen.

# 1. Einführung & Architektur

Die Phasen des Bootvorgangs.

Cloud-init läuft in vier Hauptphasen ab. Dies zu wissen ist essenziell für das Troubleshooting.

graph TD
    A[Boot Phase: Generator] --> B[Phase: Local - Network Config]
    B --> C[Phase: Network - Fetch User Data]
    C --> D[Phase: Config - Write Files / Users]
    D --> E[Phase: Final - runcmd / Scripts]
    subgraph "Data Sources"
        F[Config Drive / NoCloud]
        G[Metadata API: AWS/OpenStack]
    end
    F --> B
    G --> C

# 2. Fortgeschrittene Konfiguration

Mehr als nur User anlegen.

# Network Config V2 (Modernes YAML)

Cloud-init kann das Netzwerk konfigurieren, noch bevor Netplan oder systemd-networkd übernehmen.

# network-config
version: 2
ethernets:
  eth0:
    addresses: [10.0.0.15/24]
    gateway4: 10.0.0.1
    nameservers:
      addresses: [8.8.8.8, 1.1.1.1]

# Dateien schreiben (write_files)

Erstellen Sie Konfigurationsdateien direkt beim Booten.

write_files:
  - path: /etc/nginx/conf.d/stub.conf
    permissions: '0644'
    owner: root:root
    content: |
      server {
          listen 80 default_server;
          location /status { stub_status; }
      }

# 3. bootcmd vs. runcmd

Das Timing entscheidet.

• bootcmd: Läuft extrem früh, noch vor der Netzwerk-Konfiguration. Ideal für Kernel-Module oder Partition-Resizing.
• runcmd: Läuft ganz am Ende. Ideal für apt install oder das Starten von Applikationen.

bootcmd:
  - [ cloud-init-per, once, myboot, echo, "Early Boot" ]

runcmd:
  - [ systemctl, restart, nginx ]

# 4. Day-2 Operations: Debugging

Warum hat mein Skript nicht ausgeführt?

Cloud-init ist sehr gesprächig, aber man muss wissen, wo man sucht.

# Logs analysieren

1. /var/log/cloud-init.log: Detaillierter Trace der internen Logik.
2. /var/log/cloud-init-output.log: Der stdout/stderr Output Ihrer Skripte (runcmd).

# Config validieren

Testen Sie die Syntax, bevor Sie die VM starten:

# Auf dem Host/Dev-Rechner
cloud-init schema --config-file user-data.yaml

# 5. Troubleshooting & “War Stories”

Praxisprobleme.

# Story 1: “Der hängende APT-Lock”

Symptom: Die VM bootet, aber runcmd bricht ab, weil apt install keinen Lock auf /var/lib/dpkg/lock bekommt. Ursache: Das OS macht im Hintergrund bereits ein apt-get update (unattended-upgrades). Lösung: Nutzen Sie den Cloud-init Wait-Befehl:

runcmd:
  - [ cloud-init, status, --wait ]
  - [ apt-get, install, -y, htop ]

# Story 2: “User-Data wird ignoriert”

Symptom: Keine Änderung an der VM nach dem Start. Ursache: Cloud-init führt die User-Data standardmäßig nur einmalig (per Instance-ID) aus. Wenn Sie die Config in Proxmox ändern, aber die Instance-ID gleich bleibt, passiert nichts. Lösung: Ändern Sie die instance-id in den Metadaten oder erzwingen Sie einen Re-Run: sudo cloud-init clean --reboot.

# 6. Fazit & Empfehlung

• Modularität: Trennen Sie OS-Config (Cloud-init) von Applikations-Config (Ansible).
• Templates: Nutzen Sie Cloud-init in Proxmox-Templates (siehe Artikel 002).
• Versionierung: Halten Sie Ihre YAML-Snippets in Git fest.

# Anhang: Cheatsheet