Immutable Infrastructure

1. Backen (Bake): Du erstellst mit Packer (von HashiCorp) ein "Golden Image" (AMI für AWS, VHD für Azure). Darin ist das OS und deine App fertig installiert.
2. Deployen: Du startest 10 Instanzen von diesem Image (Auto Scaling Group / Terraform).
3. Update: App v2 kommt?
   • Baue neues Image v2.
   • Starte 10 neue v2-Server.
   • Lösche die 10 alten v1-Server.
4. Kein SSH: Niemand darf sich einloggen. Debugging nur über zentralisierte Logs.

1. Security Benefits

Wenn niemand schreiben darf, kann sich auch kein Hacker einnisten ("Persistence"). Ein Rootkit oder Malware würde beim nächsten Re-Deploy (oft alle 24h) verschwinden. Noch besser: Read-Only Filesystems. Angreifer können nichtmal Tools (wget) runterladen.

2. Testing & Rollback

Bei Mutable Infrastructure: "Ich habe den Patch auf Prod installiert, jetzt geht nichts mehr. Wie war der Zustand davor?" -> Panik. Bei Immutable: "v2 ist kaputt? Okay, schalte den Load Balancer zurück auf v1 (die Server stehen ja noch da)." -> Sofortiger Rollback. Du testest das Image im Staging. Wenn das Image auf Staging geht, geht es exakt so auf Prod (Bit-Identisch).

3. Stateful Services?

Immutable Infrastructure funktioniert super für Stateless Apps (Webserver). Für Datenbanken ist es schwer. Du kannst nicht einfach den DB-Server löschen (Daten weg!). Lösung: Trenne Compute (Server) von Storage (Disk/EBS). Beim DB-Update:

1. Fahre DB runter.
2. Löse Disk (Volume) vom alten Server.
3. Lösche alten Server.
4. Starte neuen Server mit neuer DB-Version.
5. Mounte alte Disk. Trotzdem: Für Datenbanken wird oft noch "Mutable" Management (Ansible) bevorzugt.

The Baking Pipeline (Packer & Ansible)

Das Erschaffen der Immutable Images (das "Baking") ist nicht profan, sondern ein eigener CI-Prozess. Oft bedienen sich DevOps-Ingenieure hier einer Tool-Kombination aus HashiCorp Packer und Ansible. Packer fährt kurzzeitig eine nackte VM hoch, holt sich ein minimales OS-Template (z.B. Ubuntu) aus dem isolierten Subnetz und übergibt dann die Kontrolle an Ansible. Ansible installiert agentenlos SSH-Härtungen, Logs-Shipper (Fluentd) und Abhängigkeiten. Ist das Provisioning fehlerfrei durchgeführt, macht Packer einen Shutdown der VM, friert das Block-Device als AWS AMI (Amazon Machine Image) ein und löscht die Reste. Ab diesem Moment ist das Image versiegelt.

OS Hardening & Read-Only Root Filesystems (Roofs)

Ein extremes High-Security-Setup kombiniert Immutable Infrastructure mit einem Roofs (Read-Only Root Filesystem). Auf Kernel-Ebene wird das / Verzeichnis der Instanz unveränderbar gemountet (mount -o ro). Selbst ein Hacker, der als root im System einwandert (Privilege Escalation), kann keinen bösartigen Cronjob in /etc/crontab installieren oder /bin/bash durch eine Backdoor überschreiben. Applikations-Daten oder Caches werden strikt in separierte temporäre Mounts (/tmp als im RAM liegendes tmpfs) oder dedizierte externe Block-Storages (/var/lib/mysql) ausgelagert. Das Betriebssystem selbst ist betongleich und schimmelresistent.

Chaos Engineering (Chaos Monkey)

Netflix hat das Paradigma der Immutable Infrastructure zum Extrem getrieben: Die Simian Army (Chaos Monkey). Wenn jeder Server jederzeit gefahrlos terminiert und durch Neu-Spawns aus dem Image Pool ersetzt werden kann (da stateless und immutable), testet man das Vertrauen ins System durch absichtliche Sabotage. Ein Skript loggt sich zur Mittagszeit per API in die Cloud ein und erschießt zufällige Produktions-Server. Das zwingt die Auto-Scaling-Groups und Load-Balancer dazu, perfekt kalibriert zu bleiben. Wäre auch nur ein einziger Server "Mutable" konfiguriert worden (mit lokalen manuellen Änderungen), würde dieses Chaos das System zerstören. Im Idealfall merkt der Kunde jedoch keine Unterbrechung.