Infrastructure as Code
Infrastruktur in Dateien beschreiben und automatisch anlegen
Die Idee und ihr Nutzen
Ein Projektteam einer Versicherung braucht für einen neuen Dienst eine Testumgebung: ein eigenes Netz, drei Server, eine Datenbank und einen Lastverteiler. Auf jedem der drei Server läuft ein Exemplar desselben Dienstes, und der Lastverteiler verteilt die Anfragen auf diese drei Exemplare. Statt all das über Bedienoberflächen von Hand einzurichten, beschreibt das Projektteam die gewünschte Umgebung in Textdateien, etwa mit der Angabe „drei Server mit je vier Prozessorkernen“. Ein Werkzeug legt die Umgebung danach automatisch an. Eine zweite Person kann die Textdateien wie Programmcode prüfen, bevor das Werkzeug die Umgebung anlegt. Jede Fassung der Textdateien bleibt gespeichert, und mit anderen Werten entsteht aus denselben Textdateien auch die Umgebung für den echten Betrieb. Dieses Vorgehen heißt Infrastructure as Code, kurz IaC, auf Deutsch Infrastruktur als Code.
Wie funktioniert es?
Das Projektteam wählt aus der Versionsverwaltung eine gemeinsame Vorlage für Netz, drei Server, Datenbank und Lastverteiler. Die Versionsverwaltung ist eine Ablage, die jede Fassung einer Datei mit Datum und Verfasser speichert. Ein verbreitetes Beispiel ist Git. In die Vorlage setzt das Projektteam die Werte für seine Testumgebung ein: Projektname, kleinere Server, eigene Netzadressen. Die fertige Beschreibung legt das Projektteam in der Versionsverwaltung ab. Das IaC-Werkzeug liest die Beschreibung und fragt beim Cloud-Anbieter ab, was dort tatsächlich existiert. Der Cloud-Anbieter ist ein Unternehmen, das Server, Netze und Datenbanken zur Miete bereitstellt. Aus dem Vergleich erstellt das IaC-Werkzeug den Plan „14 neu, 0 ändern, 0 löschen“: 14 Bestandteile werden neu angelegt, nichts wird geändert oder gelöscht. Es sind 14 und nicht nur sechs, weil zu Netz, drei Servern, Datenbank und Lastverteiler noch Teile wie die Zugriffsregeln gehören. Diesen Plan legt das IaC-Werkzeug dem Betriebsteam vor, das für Sicherheit und Betrieb verantwortlich ist. Ein Mitarbeiter des Betriebsteams prüft den Plan und gibt ihn frei. Erst dann legt das IaC-Werkzeug die 14 Bestandteile beim Cloud-Anbieter an, was etwa zehn Minuten dauert. Sechs Monate später ist das Projekt beendet, und die Testumgebung soll entfernt werden. Vorher prüft das Projektteam, welche Daten aus der Testdatenbank noch gebraucht werden. Außerdem prüft das Projektteam, ob jemand zwischendurch von Hand zusätzliche Bestandteile angelegt hat. Solche Bestandteile kennt das IaC-Werkzeug nicht und würde sie deshalb nicht entfernen. Das Projektteam sichert die benötigten Daten und räumt die von Hand angelegten Bestandteile gesondert auf. Danach entfernt das IaC-Werkzeug alle Bestandteile, die es verwaltet.
Zur Infrastruktur gehören Server, Netze, Datenbanken, Speicher und Zugriffsregeln. Die Beschreibungsdateien legen fest, welche Bestandteile es am Ende geben soll. Ein Beispiel ist „drei Server mit je vier Prozessorkernen, eine Datenbank, ein Lastverteiler“. Meist legen die Dateien diesen gewünschten Endzustand fest und nicht die Handgriffe dorthin. Was dafür zu tun ist, ermittelt das IaC-Werkzeug selbst. Anders als ein Skript, das Schritt für Schritt Befehle an den Cloud-Anbieter schickt, zeigt das IaC-Werkzeug deshalb vorher einen Plan und erkennt Abweichungen.
Das Projektteam schreibt die Beschreibungsdateien. Weil die Versionsverwaltung jede Fassung speichert, kann eine zweite Person jede Änderung prüfen, bevor das IaC-Werkzeug sie anwendet. Das IaC-Werkzeug ermittelt die Unterschiede zum tatsächlichen Zustand und setzt sie über die Programmierschnittstellen des Cloud-Anbieters um. Programmierschnittstellen sind Aufrufe, mit denen sich beim Cloud-Anbieter alle Bestandteile ohne Bedienoberfläche anlegen und ändern lassen. Welche Bestandteile das IaC-Werkzeug verwaltet, speichert es in einer eigenen Zustandsdatei. Das Betriebsteam prüft vor jeder Änderung den Plan und gibt ihn frei. Diese Prüfung durch eine zweite Person erzwingen die Dateien nicht von selbst. Die Versicherung muss deshalb festlegen, dass das IaC-Werkzeug einen Plan erst nach der Freigabe durch das Betriebsteam anwendet. Mit denselben Beschreibungen und anderen Werten entstehen die Testumgebung, die Abnahmeumgebung für die Fachabteilung und die Produktion nach demselben Bauplan. Die Produktion ist der echte Betrieb. Ganz gleich sind diese Umgebungen damit nicht, denn die eingesetzten Werte unterscheiden sich. Passwörter und andere Zugangsdaten gehören nicht in die Beschreibungsdateien, weil viele Menschen die Beschreibungsdateien lesen. Die Dateien verweisen nur auf einen getrennten Speicher für solche Geheimnisse.
Ändert jemand an der Beschreibung vorbei etwas von Hand, fällt das beim nächsten Planen als Abweichung auf, sofern das IaC-Werkzeug den betroffenen Bestandteil kennt. Beim nächsten Anwenden setzt das IaC-Werkzeug den beschriebenen Zustand wieder durch und überschreibt damit die Handänderung. Bestandteile, die jemand ganz von Hand angelegt hat, kennt das IaC-Werkzeug dagegen nicht, und es entfernt sie auch nicht, wenn die Umgebung gelöscht wird.
Infrastructure as Code: Testumgebung anlegen und sauber entfernen
Wann ist es sinnvoll und wann nicht?
Infrastructure as Code lohnt sich
- Für einen Dienst gibt es mehrere Umgebungen. Richten Mitarbeiter Server, Netze, Datenbanken und Zugriffsregeln von Hand über die Bedienoberfläche des Cloud-Anbieters ein, sieht jede Umgebung ein wenig anders aus, weil jemand eine Einstellung anders gesetzt oder vergessen hat. Ein Fehler, der nur in der Produktion auftritt, lässt sich dann im Test nicht nachstellen. Entstehen alle Umgebungen nach demselben Bauplan, unterscheiden sie sich nur in den eingesetzten Werten. Der Fehler lässt sich dann im Test nachstellen, sofern er nicht von diesen Werten abhängt.
- Änderungen müssen nachvollziehbar sein. Als Unternehmen einer regulierten Branche muss die Versicherung nachweisen können, wer welche Änderung an der Infrastruktur vorgenommen und freigegeben hat. Ohne Infrastructure as Code ist nicht nachvollziehbar, wer wann eine Regel geändert hat. Ein Beispiel ist die Regel, welche Rechner die Datenbank erreichen dürfen. Mit Infrastructure as Code liegt jede Änderung mit Datum und Verfasser in der Versionsverwaltung, und der Plan zeigt vor dem Anwenden, was geschehen wird.
- Eine Umgebung muss nach einem Totalausfall wieder aufgebaut werden können. Ohne Beschreibung weiß dann niemand mehr genau, wie die Umgebung aufgebaut war. Der Wiederaufbau dauert Tage und ergibt eine Umgebung, die sich anders verhält als die alte. Mit Infrastructure as Code legt das IaC-Werkzeug die Umgebung aus den Dateien neu an, statt dass Mitarbeiter sie aus der Erinnerung nachbilden.
- Die Infrastruktur läuft bei einem Cloud-Anbieter, bei dem sich alle Bestandteile über Programmierschnittstellen anlegen lassen. Das Projektteam erhält seine Testumgebung mit 14 Bestandteilen dann in etwa zehn Minuten, statt sie über Tage von Hand einzurichten.
Infrastructure as Code ist nicht das Richtige
- Ein Altsystem lässt sich nur über Bedienoberflächen oder von Hand einrichten. Ein IaC-Werkzeug kann ein solches Altsystem nicht anlegen, weil das Altsystem keine Programmierschnittstellen hat. Das Betriebsteam richtet das Altsystem dann nach einer schriftlichen Anleitung mit Prüfliste ein und hält jede Änderung mit Datum und Verfasser fest.
- Es geht um Einstellungen innerhalb laufender Programme, die sich häufig ändern, ohne dass eine neue Umgebung nötig ist. Ein Beispiel sind Grenzwerte einer Fachanwendung. Mit Infrastructure as Code müsste das Team der Fachanwendung für jeden geänderten Grenzwert die Beschreibung ändern, und das Betriebsteam müsste jedes Mal einen Plan prüfen und freigeben. Stattdessen legt das Team der Fachanwendung solche Einstellungen in einem Configuration Server ab, einem Dienst, der die Einstellungen der Programme verwaltet. Die Programme übernehmen geänderte Werte im laufenden Betrieb. Für eine Änderung der Grenzwerte erstellt das IaC-Werkzeug keinen Plan, und das Betriebsteam muss nichts freigeben.
- Eine Infrastruktur wird nur einmal aufgebaut, selten geändert und muss nach einem Ausfall nicht in kurzer Zeit wieder entstehen. Das IaC-Werkzeug würde die Beschreibungsdateien dann ein einziges Mal anwenden. Stattdessen richtet das Betriebsteam die Infrastruktur nach einer Anleitung mit Prüfliste ein. Das Betriebsteam muss keine Beschreibungsdateien schreiben und pflegen und kein IaC-Werkzeug mit Zustandsdatei betreiben.
Nachteile und typische Fehler
Die Beschreibungen sind Code. Das Projektteam muss sie bei jeder Änderung der Umgebung anpassen und testen, und es braucht Mitarbeiter, die die Sprache des IaC-Werkzeugs beherrschen. Das IaC-Werkzeug selbst muss betrieben werden, und seine Zustandsdatei muss sicher aufbewahrt werden. Geht die Zustandsdatei verloren, weiß das IaC-Werkzeug nicht mehr, welche Bestandteile es verwaltet. Wechselt die Versicherung später das Werkzeug, muss sie die Beschreibungen in der Sprache des neuen Werkzeugs neu schreiben. Alle Beteiligten müssen außerdem auf schnelle Handänderungen verzichten. Weil ein Fehler in der Beschreibung beim Anwenden viele Bestandteile auf einmal treffen kann, sind ein gut lesbarer Plan, ein Schutz für kritische Bestandteile wie die Datenbank und eine Freigabe vor dem Anwenden unverzichtbar.
Typische Fehler und woran man sie erkennt:
- Fehler in der Beschreibung: Ein Mitarbeiter des Projektteams benennt die Datenbank in der Beschreibung um. Das IaC-Werkzeug erkennt die bestehende Datenbank unter dem neuen Namen nicht wieder und plant, die alte Datenbank zu löschen und eine neue anzulegen. Gibt das Betriebsteam diesen Plan frei, sind die Daten der alten Datenbank verloren. Erkennbar ist das im Plan an „löschen“ oder „ersetzen“ bei einem Bestandteil, der Daten enthält.
- Überschriebene Handänderung: Ein Mitarbeiter des Betriebsteams vergrößert während einer Störung einen Server von Hand über die Bedienoberfläche des Cloud-Anbieters und passt die Beschreibung nicht an. Beim nächsten Anwenden setzt das IaC-Werkzeug den Server wieder auf die beschriebene Größe zurück. Erkennbar ist das an Einstellungen, die nach einem Anwenden wieder verschwunden sind.
- Zugangsdaten in den Dateien: Ein Mitarbeiter des Projektteams schreibt das Passwort der Testdatenbank direkt in die Beschreibung und legt die Beschreibung in der Versionsverwaltung ab. Jeder, der die Beschreibung lesen darf, kann nun auch das Passwort lesen. Löscht das Projektteam das Passwort später aus der Beschreibung, bleibt es in den älteren Fassungen erhalten. Erkennbar ist das an Passwörtern in älteren Fassungen der Beschreibungsdateien.
- Vergessene Bestandteile: Von Hand angelegte Bestandteile bleiben nach dem Entfernen der Umgebung bestehen, weil das IaC-Werkzeug sie nicht kennt. Erkennbar ist das an Rechnungen des Cloud-Anbieters für Bestandteile eines beendeten Projekts.
- Ungelesener Plan: Das Betriebsteam gibt Pläne frei, ohne sie zu lesen. Sieht ein Plan vor, die Datenbank zu löschen, löscht das IaC-Werkzeug die Datenbank dann tatsächlich. Erkennbar ist das an Freigaben langer Pläne innerhalb weniger Sekunden.
Weiterführend
Verwandte Ansätze
- Immutable Infrastructure: ersetzt Server bei jeder Änderung durch neue, statt sie zu verändern, und nutzt dafür solche Beschreibungen.
- Disaster Recovery: Pläne für den Verlust eines Standorts. Eine beschriebene Umgebung lässt sich im Ernstfall automatisch und jedes Mal gleich neu aufbauen.
- Secrets Management: verwahrt Passwörter und Schlüssel getrennt, auf die die Beschreibungen nur verweisen.
Werkzeuge und Umsetzungen
- OpenTofu: beschreibt Infrastruktur bei vielen Cloud-Anbietern in einer eigenen Sprache und legt sie an. OpenTofu ist eine Abspaltung des Werkzeugs Terraform, das seit 2023 nicht mehr unter einer Open-Source-Lizenz steht.
- Ansible: richtet Server und Software nach Beschreibungen ein, ohne dass auf den Servern ein zusätzliches Programm laufen muss.
- Pulumi: beschreibt Infrastruktur in verbreiteten Programmiersprachen wie Python oder TypeScript statt in einer eigenen Sprache.
- Crossplane: verwaltet Bestandteile bei Cloud-Anbietern über Kubernetes, eine verbreitete Plattform zum Betrieb von Anwendungen auf vielen Servern.
Quellen
- Martin Fowler: InfrastructureAsCode: kurze Begriffsklärung mit den Grundsätzen, Beschreibungsdateien zu verwenden, alles zu versionieren und keine Änderungen von Hand an Servern vorzunehmen.
- OpenTofu: Command: plan: offizielle Dokumentation; beschreibt, wie das Werkzeug den Ist-Zustand liest, mit der Beschreibung vergleicht und Änderungen vorschlägt, ohne sie auszuführen.