Immutable Infrastructure
Server ersetzen statt ändern
Die Idee und ihr Nutzen
Der Schadendienst einer Versicherung läuft auf 40 Servern, auf jedem Server ein Exemplar desselben Programms. Der Schadendienst verwendet eine Programmbibliothek, also fertigen Programmcode, und in dieser Programmbibliothek wird eine Sicherheitslücke bekannt. Statt die Bibliothek auf jedem der 40 Server einzeln zu aktualisieren, lässt das zuständige Team ein neues Abbild bauen. Ein Abbild ist ein fertiges Paket aus Betriebssystem, Software und Einstellungen, aus dem sich Server starten lassen. Aus dem neuen Abbild startet das Team neue Server und löscht die alten. Auf jedem Server läuft damit genau die Version der Bibliothek, die in dem Abbild steckt, aus dem der Server gestartet wurde. Dieses Vorgehen heißt Immutable Infrastructure, auf Deutsch unveränderliche Infrastruktur, weil laufende Server nie verändert, sondern nur ersetzt werden.
Wie funktioniert es?
Am Dienstagmorgen wird die Sicherheitslücke bekannt. Das Team, das den Schadendienst betreibt, trägt die korrigierte Version der Bibliothek in die Beschreibung der Server ein. Die Beschreibung ist eine Textdatei, die festlegt, welches Betriebssystem, welche Software und welche Einstellungen jeder Server enthält. Der automatische Bau, ein eigenes Programm, erzeugt aus der Beschreibung das Abbild v2 und testet es. Die Tests laufen ohne Fehler. Der automatische Bau legt v2 neben v1 in der Abbildablage ab, dem Speicher für alle Abbilder. Das Team startet aus v2 die ersten fünf neuen Server. Mit fünf Servern beginnt das Team, damit ein unentdeckter Fehler in v2 nur einen kleinen Teil der Anfragen trifft. Sobald die neuen Server bereit sind, melden sie das dem Lastverteiler, dem Programm, das die Anfragen auf die Server verteilt. Der Lastverteiler schickt den neuen Servern daraufhin Anfragen. Erst danach nimmt das Team fünf alte Server mit v1 aus der Verteilung und löscht sie. Das Team wiederholt den Austausch in Schritten, bis nach einer Stunde alle 40 Server aus v2 laufen. Die Schadendaten liegen die ganze Zeit in einer getrennten Datenbank und sind vom Austausch nicht betroffen. In einer Liste ist für jeden Server festgehalten, aus welchem Abbild er gestartet wurde. Eine Woche später fragt die Revision, die interne Prüfabteilung der Versicherung, ob die Lücke überall geschlossen ist. Ein Blick in diese Liste genügt: Alle 40 Server laufen mit v2.
Ein Abbild kann für eine ganze virtuelle Maschine gebaut sein, also für einen per Software nachgebildeten Rechner. Es kann auch ein Containerabbild sein, ein kleineres, abgeschlossenes Paket aus einem Programm und allem, was es zum Laufen braucht. Jedes Abbild erhält eine Versionsnummer wie v2 und wird automatisch getestet. Das Team ändert nur die Beschreibung, nie einen laufenden Server. Oft verhindert das Team Änderungen an laufenden Servern sogar technisch. Dann kann sich zum Beispiel niemand auf den Servern anmelden. Server zu ersetzen statt zu ändern ist möglich, weil sich die Server per Software automatisch erzeugen und wieder löschen lassen. Es sind keine einzelnen Geräte, die jemand von Hand einrichtet. Daten, die erhalten bleiben müssen, liegen nicht auf den austauschbaren Servern, sondern in einem getrennt verwalteten Speicher wie der Datenbank des Schadendienstes.
Meldet sich ein neuer Server nicht als bereit, schickt der Lastverteiler ihm keine Anfragen, und die alten Server bleiben in der Verteilung. Zeigt v2 nach dem Austausch einen Fehler, startet das Team wieder Server aus dem alten Abbild v1. Das gelingt aber nur, wenn v1 mit den Daten zurechtkommt, die v2 inzwischen gespeichert hat.
Immutable Infrastructure: Server ersetzen statt reparieren
Wann ist es sinnvoll und wann nicht?
Immutable Infrastructure lohnt sich
- Ein Dienst läuft auf vielen gleichartigen Servern, die ohne dieses Vorgehen über Jahre von Hand gepflegt werden. Auf einem Server wird eine Sicherheitsaktualisierung eingespielt. Auf einem anderen wird eine Einstellung geändert. Auf einem dritten baut jemand nachts im Notfall eine Korrektur ein. Nach einiger Zeit ist jeder Server ein Einzelstück, und niemand weiß mehr genau, was darauf installiert ist. Mit Immutable Infrastructure starten alle Server aus demselben Abbild, und die Beschreibung legt fest, was darauf installiert ist.
- Bei von Hand gepflegten Servern tritt ein Fehler manchmal nur auf einzelnen Servern auf, und niemand findet den Unterschied. Mit Immutable Infrastructure sind alle Server aus demselben Abbild gestartet. Ein solcher Unterschied kann dann nicht entstehen, solange niemand die Server am Verfahren vorbei von Hand ändert.
- Nachvollziehbarkeit ist gefordert. Prüfer wie die Revision wollen wissen, welche Software auf welchem Server läuft. Ohne dieses Vorgehen weiß ein Team bei einer Sicherheitslücke nicht sicher, ob die Lücke auf allen Servern geschlossen wurde. Mit Immutable Infrastructure steht jede Änderung in einer neuen Fassung der Beschreibung, und die Liste zeigt, aus welchem Abbild jeder Server gestartet wurde.
- Ein ausgefallener Server soll schnell ersetzt werden. Bei von Hand gepflegten Servern dauert es lange, einen gleichwertigen Ersatz einzurichten, weil sich ein Server nicht mehr genau gleich aufbauen lässt. Mit Immutable Infrastructure startet das Team aus dem aktuellen Abbild einen gleichwertigen Ersatz.
- Die Server sind Container oder virtuelle Maschinen, die sich automatisch erzeugen lassen. Die Programme speichern zwischen zwei Anfragen nichts bei sich selbst und können deshalb jederzeit ersetzt werden. Ändert das Team solche Server trotzdem von Hand, werden sie zu Einzelstücken, obwohl ein gleichwertiger Ersatz nur einen Start aus dem Abbild bräuchte.
Immutable Infrastructure ist nicht das Richtige
- Ein Server speichert selbst große Datenbestände. Ein Beispiel ist der Server, auf dem die Datenbank des Schadendienstes läuft. Für jeden Austausch müssten alle Schadendaten auf den neuen Server umziehen. Dann bringt das Team den Server mit einem Werkzeug zur Konfigurationsverwaltung auf den beschriebenen Stand, ohne ihn auszutauschen. Das Werkzeug prüft auf jedem Server, ob Software und Einstellungen der Beschreibung entsprechen, und korrigiert Abweichungen. Die Daten bleiben dabei auf dem Server und müssen nicht umziehen. Änderungen, die am Werkzeug vorbei von Hand gemacht werden, können aber trotzdem zu Abweichungen führen.
- Bau, Test und Austausch sind nicht automatisiert. Jede noch so kleine Änderung würde dann bedeuten, ein Abbild von Hand zu bauen und zu testen und alle 40 Server von Hand zu ersetzen. Solange das so ist, aktualisiert das Team die laufenden Server mit einem Werkzeug zur Konfigurationsverwaltung und ändert dafür nur die Beschreibung.
- Ein Gerät lässt sich nicht per Software neu erzeugen. Ein Beispiel ist ein Rechner mit fest eingebauter Spezialhardware. Einen solchen Rechner aktualisiert das Team direkt auf dem Rechner, ebenfalls mit einem Werkzeug zur Konfigurationsverwaltung. So entspricht auch dieser Rechner der Beschreibung, ohne dass er ersetzt werden muss.
Nachteile und typische Fehler
Jede noch so kleine Änderung erfordert ein neues Abbild und einen Austausch der Server. Das Team muss dafür eine Automatisierung aufbauen und betreiben: den Bau, die Tests, die Abbildablage und den schrittweisen Austausch. Während des Austauschs laufen alte und neue Version nebeneinander, und beide müssen mit derselben Datenbank zurechtkommen. Die Fehlersuche ändert sich: Niemand kann sich auf einem Server umsehen und dort etwas ausprobieren. Stattdessen untersucht das Team Protokolle und Messwerte, die die Server nach außen melden. Der Ansatz macht ein Abbild nicht fehlerfrei. Er bewirkt nur, dass alle Server aus demselben Abbild denselben Inhalt haben und dass in der Beschreibung steht, welcher Inhalt das ist.
Typische Fehler und woran man sie erkennt:
- Veraltetes Abbild: Das Team baut das Abbild nur neu, wenn sich am eigenen Programm etwas ändert. Dann fehlen die Sicherheitsaktualisierungen für Betriebssystem und Bibliotheken. Erkennbar ist das an Abbildern, deren Bauzeitpunkt Monate zurückliegt.
- Daten auf dem Server: Ein Programm legt doch Daten auf dem austauschbaren Server ab, etwa hochgeladene Dateien. Diese Daten gehen beim Löschen des Servers verloren. Erkennbar ist das an fehlenden Dateien nach einem Austausch.
- Gescheiterte Rückkehr: Nach einem Fehler in v2 startet das Team wieder Server aus v1, doch v1 kommt mit Daten nicht zurecht, die v2 gespeichert hat. Erkennbar ist das an Fehlern beim Lesen von Datensätzen, die v2 angelegt hat.
- Heimliche Änderung: Die Anmeldung an den Servern ist nicht gesperrt. Ein Mitarbeiter meldet sich im Notfall auf einem Server an und korrigiert dort etwas. Die Liste, aus welchem Abbild jeder Server stammt, beschreibt diesen Server danach nicht mehr richtig. Erkennbar ist das an Servern, die sich anders verhalten als andere Server aus demselben Abbild.
Weiterführend
Verwandte Ansätze
- Infrastructure as Code: beschreibt Server, Netze und Einstellungen in Dateien. Immutable Infrastructure nutzt solche Beschreibungen, baut daraus aber stets neue Server, statt bestehende zu ändern. Auch Werkzeuge zur Konfigurationsverwaltung arbeiten mit solchen Beschreibungen.
- Blue Green Deployment und Rolling Deployment: zwei Arten, alte Server durch neue zu ersetzen, entweder alle auf einmal oder schrittweise.
- Stateless Services: Programme, die zwischen Anfragen nichts bei sich speichern und sich deshalb jederzeit ersetzen lassen.
- Twelve Factor App: Sammlung von Regeln für Programme im Netz, die unter anderem Bauen, Freigeben und Betreiben strikt trennt und damit gut zu diesem Vorgehen passt.
Werkzeuge und Umsetzungen
- Docker und Buildah: bauen Containerabbilder aus einer Beschreibungsdatei.
- Kubernetes: verbreitete Plattform zum Betrieb von Anwendungen auf vielen Servern. Kubernetes ersetzt Container bei einer neuen Version, statt sie zu verändern.
- Flatcar Container Linux: Betriebssystem, dessen Systemteil nicht verändert werden kann und bei Aktualisierungen als Ganzes ausgetauscht wird.
- Talos Linux: Betriebssystem für Kubernetes, auf dem man sich nicht anmelden kann. Talos Linux wird nur über eine Programmierschnittstelle verwaltet.
- NixOS: Linux-Betriebssystem, dessen gesamter Zustand aus einer Beschreibung erzeugt wird.
Quellen
- Kief Morris: Immutable Server: Beitrag von 2013 auf martinfowler.com, der beschreibt, warum laufende Server nicht verändert, sondern aus einem neuen Abbild ersetzt werden und warum Daten dafür außerhalb der Server liegen müssen.
- Chad Fowler: Trash Your Servers and Burn Your Code: Aufsatz von 2013, der den Gedanken unveränderlicher Installationen bekannt machte, die automatisch gebaut und bei jeder Änderung ersetzt werden.
- AWS: REL08-BP04 Deploy using immutable infrastructure: nennt Vorteile wie die Rückkehr zur alten Version und die gesperrte Anmeldung an den Servern und beschreibt das schrittweise Umleiten von Anfragen auf neue Server.