# Immutable Systems: Die Infrastruktur ohne Gedächtnis

TL;DR / Management Summary In einer Immutable Infrastructure wird ein Server nach der Bereitstellung nie wieder verändert. Updates bedeuten nicht apt upgrade, sondern das Ersetzen der gesamten Instanz durch ein neues Image. Dieses Konzept eliminiert Configuration Drift und erhöht die Sicherheit massiv (Read-Only Root). Unter Alpine und Arch nutzen wir OverlayFS und den Diskless Mode, um flüchtige Systeme zu bauen, die bei jedem Reboot in einen definierten Urzustand zurückkehren.

# 1. Einführung & Architektur

Pet vs. Cattle.

• Pets (Haustiere): Server werden individuell gepflegt, geupdatet und benannt. Wenn sie sterben, ist das ein Drama.
• Cattle (Nutztier): Server sind identisch und ersetzbar. Wenn einer hinkt, wird er gelöscht und neu erstellt.

# Die Architektur der Unveränderlichkeit (Mermaid)

graph TD
    A[Image: Golden Snapshot] --> B[Instance 1: Read-Only]
    A --> C[Instance 2: Read-Only]
    B --> D[OverlayFS: RAM Write Layer]
    C --> D
    D --> E[Reboot]
    E -->|RAM wiped| A
    subgraph "External State"
        F[Shared Storage: DB / Logs]
        G[Config: Cloud-Init / Metadata]
    end
    B --- F
    B --- G

# 2. Implementierung unter Alpine (Diskless)

Das System im RAM.

Alpine ist der Vorreiter für zustandslose Systeme. Das gesamte OS liegt in einer Datei (.apkovl).

# Der Boot-Vorgang

1. Kernel lädt Initramfs.
2. Das OS wird komplett in den RAM kopiert.
3. Die SD-Karte/Disk wird ungemountet.
4. Änderungen leben nur im RAM.

# 3. General Linux: OverlayFS

Die schreibbare Maske.

Für Distributionen wie Arch nutzen wir OverlayFS, um eine schreibbare Schicht (z.B. ein tmpfs) über ein schreibgeschütztes Basis-System zu legen.

# Beispiel: Read-Only Root mit Overlay

# In der initramfs-Phase
mount -t tmpfs tmpfs /mnt/upper
mount -t squashfs /dev/sda1 /mnt/lower
mount -t overlay overlay -o lowerdir=/mnt/lower,upperdir=/mnt/upper,workdir=/mnt/work /mnt/merged

Alle Schreibvorgänge landen nun in /mnt/upper (RAM). Das Originalsystem unter /mnt/lower bleibt unangetastet.

# 4. Day-2 Operations: Configuration Injection

Wie kommt die Config ins System?

Da das Image unveränderlich ist, muss die Konfiguration (IP, Hostname, API-Keys) beim Start injiziert werden.

• Methoden: Cloud-Init (Artikel 054), DHCP-Optionen oder ein Key-Value Store (etcd/consul).

# 5. Troubleshooting & “War Stories”

Wenn der RAM überläuft.

# Story 1: “Der schleichende RAM-Tod”

Symptom: Ein zustandsloser Server stürzt nach 14 Tagen Betrieb ab. Ursache: Applikations-Logs schreiben massiv nach /var/log. Da dies im RAM-Overlay liegt, wächst der RAM-Verbrauch bis zum OOM-Exit. Lösung: Mounten Sie /var/log auf einen externen Netzwerkspeicher (NFS) oder nutzen Sie ein Remote-Logging-Protokoll, damit die lokalen Daten sofort verworfen werden können.

# Story 2: “Das verlorene Update”

Symptom: Ein Admin loggt sich per SSH ein, ändert eine Konfigurationsdatei und freut sich, dass alles geht. Nach einem Sicherheits-Reboot ist die Änderung weg. Ursache: Fehlverständnis des Immutable-Konzepts. Lokale Änderungen sind flüchtig. Lösung: Änderungen müssen im Image-Build-Prozess (CI/CD) gemacht werden. Der Admin muss lernen: “Ändere niemals einen laufenden Server”.

# 6. Fazit & Empfehlung

• Sicherheit: Immutable Systems sind resistent gegen Rootkits, die sich im Dateisystem verstecken.
• Skalierbarkeit: Perfekt für Auto-Scaling Gruppen.
• Wahl: Nutzen Sie Alpine Diskless für kleine Appliances und spezialisierte Arch-Images (via Packer gebaut) für Cloud-Workloads.

# Anhang: Cheatsheet