# Minimal Installation & Cloud-Init: Die Basis für Infrastructure as Code (IaC)

TL;DR / Management Summary Eine “Minimal Installation” reduziert das Betriebssystem auf das Wesentliche, was die Performance steigert und Sicherheitsrisiken minimiert. Cloud-Init ist der Industriestandard, um diese minimalen Instanzen beim ersten Booten automatisch zu konfigurieren (User, SSH-Keys, Netzwerk, Pakete). In Proxmox ist dies die Voraussetzung für schnelles Skalieren via Clones/Templates.

# 1. Einführung & Architektur

Der Weg vom ISO zum automatisierten Template.

# Warum Minimal?

Jedes installierte Paket, das nicht benötigt wird, ist:

1. Ein potenzieller Angriffsvektor (Sicherheitslücke).
2. Ein Ressourcenverbraucher (Disk, RAM, CPU für Updates).
3. Eine Fehlerquelle bei System-Upgrades.

# Was ist Cloud-Init?

Cloud-Init ist ein Service, der während des Boot-Vorgangs ausgeführt wird. Er liest Metadaten aus verschiedenen Quellen (in Proxmox meist ein virtuelles CD-Laufwerk) und wendet diese auf das System an.

graph LR
    A[ISO / Cloud Image] --> B[Minimal OS Install]
    B --> C[Cleanup & Template Creation]
    C --> D[Proxmox VM Clone]
    D --> E[Cloud-Init Data Injection]
    E --> F[Automated Config: SSH, Network, Users]

# 2. Minimal Installation (Handarbeit vs. Cloud-Images)

Wie kommen wir zum Basis-System?

# Option A: Cloud-Images (Empfohlen für Proxmox)

Canonical (Ubuntu) und Debian bieten fertige .qcow2 Images an. Diese enthalten bereits cloud-init und sind extrem schlank.

• Ubuntu Cloud Images: cloud-images.ubuntu.com
• Debian Cloud Images: cloud.debian.org

# Option B: Manuelle Installation via Netinst

Wenn man volle Kontrolle braucht, nutzt man das “Network Install” ISO.

• Debian: Im Installer nur “Standard System Utilities” und “SSH Server” wählen. Alles andere (Desktop, Webserver) abwählen.
• Ubuntu: “Ubuntu Server (Minimized)” im Subiquity Installer wählen.

# 3. Cloud-Init Konfiguration

Das “Gehirn” der Provisionierung.

Cloud-Init nutzt YAML-Dateien (User-Data), um Befehle auszuführen. Hier sind die wichtigsten Sektionen für einen SysAdmin:

# Beispiel: user-data Konfiguration

#cloud-config
users:
  - name: sysadmin
    groups: sudo
    shell: /bin/bash
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3Nza... admin@workstation

package_update: true
package_upgrade: true

packages:
  - qemu-guest-agent
  - htop
  - curl

runcmd:
  - systemctl start qemu-guest-agent
  - echo "System initialized at $(date)" >> /etc/motd

# 4. Proxmox Integration: Vom Image zum Template

Der automatisierte Workflow auf dem Hypervisor.

Um ein effizientes Template in Proxmox zu erstellen, nutzen wir die CLI. Das ist schneller und präziser als die GUI.

# Schritt-für-Schritt (CLI)

1. Image laden: wget https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img
2. VM erstellen: qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0
3. Disk importieren: qm importdisk 9000 jammy-server-cloudimg-amd64.img local-lvm
4. Disk an hängen: qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0
5. Cloud-Init Drive hinzufügen: qm set 9000 --ide2 local-lvm:cloudinit
6. Boot-Reihenfolge: qm set 9000 --boot c --bootdisk scsi0
7. Serial Console (Wichtig für Cloud-Init): qm set 9000 --serial0 socket --vga serial0
8. Template konvertieren: qm template 9000

# 5. Day-2 Operations: Skalierung & Fehlerbehebung

Was passiert nach dem Deployment?

# Cloud-Init Logs analysieren

Wenn die VM bootet, aber der SSH-Key nicht funktioniert oder Pakete fehlen:

# Haupt-Logdatei
tail -f /var/log/cloud-init-output.log

# Status prüfen
cloud-init status --wait

# Konfiguration erneut triggern (nur für Debugging!)
cloud-init clean
cloud-init init

# Der “QEMU Guest Agent” Faktor

Ohne den Guest Agent kann Proxmox die IP-Adresse der VM nicht in der GUI anzeigen. Stellen Sie sicher, dass er via Cloud-Init installiert wird (siehe oben).

# 6. Troubleshooting & “War Stories”

Praxiserfahrung spart Stunden.

# Story 1: “Disk-Resize schlägt fehl”

Symptom: VM wurde mit 20GB in Proxmox erstellt, das Cloud-Image hat aber intern nur 2GB. Der Rest ist ungenutzt. Ursache: Das Image erkennt die Vergrößerung der Disk nicht automatisch ohne Tool. Lösung: Installieren Sie das Paket cloud-guest-utils und nutzen Sie growpart in den Cloud-Init Scripten oder stellen Sie sicher, dass das Image cloud-init erlaubt, das Filesystem automatisch zu vergrößern (growpart: { mode: 'auto' }).

# Story 2: “Duplicate IPs nach Klonen”

Symptom: Zwei geklonte VMs haben die gleiche IP, obwohl DHCP genutzt wird. Ursache: Die /etc/machine-id ist im Template identisch. Der DHCP-Server sieht beide als den gleichen Client. Lösung: Vor der Erstellung des Templates die Machine-ID leeren:

truncate -s 0 /etc/machine-id
rm /var/lib/dbus/machine-id
ln -s /etc/machine-id /var/lib/dbus/machine-id

# 7. Fazit & Empfehlung

Ein gut gepflegtes Cloud-Init Template ist die Basis für jede moderne Infrastruktur.

• Empfehlung: Erstellen Sie monatlich neue Templates mit eingebackenen Security-Patches.
• Tools: Nutzen Sie HashiCorp Packer, um den Prozess “Image -> Template” vollständig zu automatisieren, anstatt die CLI-Befehle manuell zu tippen.

# Anhang: Cheatsheet