Was heißt Immutable Infrastructure in der Praxis, und warum ist das wichtig?

Es heißt, dass Server nach ihrer Erstellung nie verändert werden. Für jede Änderung baust du ein neues Image oder einen neuen Container, rollst frische Instanzen aus und zerstörst die alten, statt in place zu patchen. Wichtig ist das, weil es Konfigurationsdrift beseitigt, Umgebungen aus dem Source reproduzierbar macht, Rollback zum erneuten Deployment des vorherigen Artefakts macht und ein kompromittierter oder degradierter Host ersetzt statt repariert wird.

Es heißt, dass nach dem Bau nichts mehr verändert wird. Kein Einloggen per ssh, um eine Config zu fixen, kein Paketupgrade auf einer laufenden Kiste. Muss sich etwas ändern, geht die Änderung in den Source, wir backen ein neues Image oder einen neuen Container, und die Flotte wird durch Instanzen aus diesem Image ersetzt. Der Gewinn ist, dass der Zustand von Produktion vollständig durch ein Artefakt und eine Version bestimmt ist, Staging und Produktion also wirklich übereinstimmen, und ein Host, der seit drei Monaten läuft, hat keine angesammelten Handänderungen, an die sich niemand erinnert. Rollback wird zum Deployment des vorherigen Digest, das dauert Minuten und hat keine Unbekannten. Es hilft auch der Sicherheit: Patchen heißt von einer aktualisierten Base neu bauen und ausrollen, und wenn ein Host kompromittiert aussieht, terminierst du ihn, statt ihn zu säubern. Unangenehm wird alles, was State hält. Datenbanken und StatefulSets brauchen weiterhin In-place-Upgrades und sorgfältige Migrationen, und die Disziplin dort ist, den Datenlebenszyklus vom Compute-Lebenszyklus zu trennen, damit Compute wegwerfbar bleiben kann.