Glossar
Infrastructure as Code
Auch: IaC · Terraform
Infrastruktur wird als versionierter Code beschrieben statt in einer Weboberfläche zusammengeklickt.
Der Gewinn ist Nachvollziehbarkeit: Jede Änderung an der Umgebung hat einen Autor, einen Zeitpunkt und eine Begründung im Verlauf. Und sie lässt sich in einer zweiten Umgebung identisch wiederholen.
Der zweite Gewinn zeigt sich im Ernstfall. Eine Umgebung, die aus Code entsteht, kann neu aufgebaut werden. Eine zusammengeklickte muss rekonstruiert werden, und das gelingt nur der Person, die sie gebaut hat.
Der dritte, im Alltag wichtigste Gewinn ist die Vorschau. Ein Plan zeigt vor der Ausführung, was angelegt, geändert und gelöscht wird. Damit wird eine Infrastrukturänderung überprüfbar wie ein Codeänderungsvorschlag, und die Zeile „wird zerstört und neu erstellt" bei einer Produktionsdatenbank fällt jemandem auf, bevor sie ausgeführt wird, statt danach.
Der Zustandsspeicher ist der Teil, der am meisten Ärger macht. Das Werkzeug führt Buch darüber, welche Ressource in der Welt zu welchem Codeabschnitt gehört. Liegt diese Datei auf einem Laptop, ist sie beim nächsten Personalwechsel weg und die Umgebung nur noch von Hand zu bedienen. Sie gehört in einen gemeinsamen Speicher mit Versionierung und Sperre, damit nicht zwei Leute gleichzeitig anwenden.
Aus dem Zustandsspeicher folgt auch eine Sicherheitsfrage, die oft übersehen wird: Er enthält Werte, die durch die Konfiguration geflossen sind, unter Umständen auch Zugangsdaten. Er gehört verschlüsselt, mit engen Rechten, und Geheimnisse gehören nicht in Variablendateien, sondern in einen Geheimnisspeicher, aus dem zur Laufzeit gelesen wird.
Ein eigenes Thema ist die Abweichung zwischen Code und Wirklichkeit. Jemand ändert im Notfall etwas in der Konsole, danach beschreibt der Code eine Umgebung, die es so nicht gibt. Beim nächsten Anwenden wird die Handarbeit stillschweigend überschrieben, im schlechtesten Fall mitten am Tag. Dagegen hilft ein regelmäßiger Abgleich, der Abweichungen meldet, und die Regel, dass eine Notfalländerung innerhalb eines Tages in den Code nachgezogen oder zurückgenommen wird.
Was den Umgang mit gewachsenen Umgebungen betrifft: Der Weg führt über Import, nicht über Neuanlage. Bestehende Ressourcen werden in den Zustand übernommen, sodass der Code den Ist-Zustand beschreibt und der Plan „keine Änderungen" meldet. Erst wenn das erreicht ist, wird verändert. Wer stattdessen parallel neu baut, betreibt für die Dauer der Umstellung zwei Umgebungen und muss den Verkehr umziehen.
Woran Sie es erkennen
- Teile der Umgebung wurden in der Konsole angelegt.
- Test- und Produktionsumgebung unterscheiden sich, ohne dass klar ist wie.
- Ein Wiederaufbau nach Totalverlust wäre Rekonstruktion aus Erinnerung.
- Die Zustandsdatei liegt lokal oder niemand weiß, wo sie liegt.
- Nach einer Notfalländerung in der Konsole wurde der Code nie nachgezogen.
Nicht zu verwechseln mit
- Konfigurationsmanagement
- Ansible, Chef, Puppet konfigurieren Systeme von innen. IaC legt die Ressourcen an, auf denen sie laufen. Die beiden ergänzen sich, ersetzen sich nicht.
- CloudFormation und CDK
- AWS-eigene Varianten desselben Prinzips. CDK erzeugt Vorlagen aus Programmcode. Die Wahl ist meist eine Frage von Anbieterbindung und Teamerfahrung, nicht des Konzepts.
- GitOps
- Ein Betriebsmodell, bei dem ein Abgleichprozess den Ist-Zustand laufend an das Repository angleicht. Setzt IaC voraus und geht darüber hinaus.
Wann es trägt
- Es gibt mehr als eine Umgebung, die gleich aussehen soll.
- Mehr als eine Person ändert Infrastruktur.
- Ein Wiederaufbau nach Totalverlust muss möglich sein.
- Änderungen an der Infrastruktur sollen überprüfbar sein.
Wann nicht
- Für ein kurzlebiges Experiment mit einer Handvoll Ressourcen.
- Halb: ein Teil im Code, ein Teil von Hand ist schlechter als konsequent von Hand.
Wie man rangeht
- Zustandsspeicher zuerst klärenGemeinsamer Speicher mit Versionierung, Verschlüsselung und Sperre. Eine Zustandsdatei auf einem Laptop ist der häufigste Grund, warum das Vorhaben endet.
- Bestehendes importieren statt nachbauenZiel ist ein Plan, der „keine Änderungen" meldet. Erst wenn der Code den Ist-Zustand beschreibt, wird verändert.
- Beim Netz und den Rechten anfangenDort dauert die Wiederherstellung am längsten und dort sind Handänderungen am gefährlichsten.
- Plan vor jedem Anwenden lesen lassenDer Plan gehört in den Änderungsvorschlag, damit ein zweites Paar Augen die Zeilen mit „wird zerstört" sieht.
- Umgebungen trennen, Module teilenGetrennte Zustände je Umgebung, gemeinsame Bausteine. Ein Zustand für alles bedeutet, dass ein Fehler in der Entwicklung die Produktion anfassen kann.
- Geheimnisse auslagernNicht in Variablendateien, sondern in einen Geheimnisspeicher. Werte, die durch die Konfiguration fließen, landen im Zustand.
- Abweichung regelmäßig prüfenEin geplanter Lauf, der nur den Plan erzeugt und Unterschiede meldet. Sonst überschreibt das nächste Anwenden eine Notfalländerung unbemerkt.
Häufig gefragt
Wie hole ich eine bestehende Umgebung in Code nach?
Bereichsweise und mit Import statt Neuanlage. Terraform kann bestehende Ressourcen übernehmen, sodass der Code den Ist-Zustand beschreibt, ohne etwas neu zu bauen. Beginnen Sie beim Netzwerk und den Rechten, weil dort die Wiederherstellung am längsten dauert.
Was tun, wenn jemand in der Konsole etwas geändert hat?
Innerhalb eines Tages entscheiden: nachziehen oder zurücknehmen. Ein regelmäßiger Lauf, der nur den Plan erzeugt, macht solche Abweichungen sichtbar, bevor sie beim nächsten Anwenden stillschweigend überschrieben werden. Für echte Notfälle ist die Konsole legitim, unbemerkt bleiben darf die Änderung nicht.
Terraform oder CDK?
Terraform, wenn mehrere Anbieter oder Fremddienste mit im Spiel sind und das Team einen deklarativen Ansatz bevorzugt. CDK, wenn ausschließlich AWS genutzt wird und das Team lieber in einer Programmiersprache arbeitet. Wichtiger als die Wahl ist, dass es eine gibt: Zwei Werkzeuge auf derselben Umgebung erzeugen genau die Abweichungen, die man vermeiden wollte.
Wie verhindert man, dass die Pipeline zu viel darf?
Über eine eigene Rolle je Umgebung mit eng geschnittenen Rechten und eine Freigabe vor dem Anwenden in Produktion. Der Plan läuft ohne Freigabe, das Anwenden nicht. So bleibt der Nutzen der Automatisierung erhalten, ohne dass ein fehlerhafter Änderungsvorschlag direkt produktiv wirkt.