Infrastructure as Code (IaC) bedeutet, dass Server, Netzwerke und Berechtigungen nicht durch Klicken in einer Verwaltungsoberfläche entstehen, sondern durch eine Textdatei, die beschreibt, was existieren soll. Ein Werkzeug liest diese Datei und stellt den beschriebenen Zustand her [1]. Die Datei ist damit beides zugleich: die Anleitung und die Dokumentation.
Ein Bauplan hilft, eine Konstruktion nachvollziehbar zu prüfen und erneut aufzubauen. Ähnlich beschreibt IaC den vorgesehenen Aufbau einer Cloud-Umgebung. Ob die laufende Umgebung diesem Plan entspricht und ob sie sich im Notfall wiederherstellen lässt, muss zusätzlich geprüft werden.
Dieser Artikel erklärt das Konzept und die zwei Begriffe, an denen in der Praxis alles hängt: den Zustand und die Abweichung. Produktnamen kommen erst im vorletzten Abschnitt vor.
Was das Problem war: die Umgebung, die niemand nachbauen kann
Bei manueller Bereitstellung werden Server, Firewall-Regeln und Berechtigungen einzeln eingerichtet. Ohne durchgängige Dokumentation ist später schwer nachvollziehbar, welche Einstellungen zusammengehören und warum sie gewählt wurden.
Ein typischer Fall. Ein Team betreibt eine Testumgebung und eine Produktionsumgebung. Beide wurden von Hand aufgebaut, im Abstand von einem Jahr, von verschiedenen Personen. Ein Fehler tritt nur in Produktion auf. Die Frage, worin sich die beiden Umgebungen unterscheiden, kann niemand beantworten, und genau diese Antwort wäre die halbe Fehlersuche. Ein Vergleich des Codes zeigt die beabsichtigten Unterschiede. Abweichungen der laufenden Umgebungen müssen zusätzlich erfasst werden.
Beim Wiederaufbau reduziert eine versionierte Beschreibung die Abhängigkeit von Erinnerung und manuellen Anleitungen. IaC kann die Infrastruktur neu bereitstellen. Betriebsdaten, Geheimnisse und externe Abhängigkeiten benötigen zusätzlich geeignete Sicherungen und getestete Wiederherstellungsabläufe.
Deklarativ und imperativ
Es gibt zwei Denkweisen, Infrastruktur zu beschreiben. Imperativ heißt: eine Abfolge von Befehlen. Lege einen Server an, dann öffne den Port, dann installiere das Paket. Deklarativ heißt: eine Beschreibung des Ziels. Es soll einen Server mit offenem Port und installiertem Paket geben.
Viele verbreitete Werkzeuge arbeiten deklarativ [2]. Sie gleichen die Umgebung mit dem beschriebenen Ziel ab. Entscheidend ist eine wiederholbare Ausführung ohne unerwünschte Doppeleffekte. Auch Befehlsfolgen können dafür ausgelegt werden; die Schreibweise allein garantiert dieses Verhalten nicht.
Der Zustand: wie Code und Ressourcen zusammenfinden
Wie ein Werkzeug den Zustand verwaltet, unterscheidet sich: Manche führen eine eigene State-Datei, andere nutzen den Zustand im Cloud-Dienst. Eine State-Datei verbindet die Beschreibung mit den tatsächlich vorhandenen Ressourcen [3].
Bei einem Werkzeug mit eigener State-Datei sind Zugriffsschutz, Sicherung und aktiviertes Locking wichtig. Ein Verlust kann eine Wiederherstellung oder erneute Zuordnung der Ressourcen nötig machen; unkoordinierte Schreibzugriffe können den Zustand beschädigen. Außerdem kann die Datei sensible Werte enthalten. Wie Teams damit umgehen, beschreibt Terraform im Team.
Drift: wenn die Realität abweicht
Drift entsteht, wenn jemand an der Beschreibung vorbei ändert: ein Handgriff in der Verwaltungsoberfläche, ein schneller Fix im Notfall. Die Umgebung und ihre Beschreibung erzählen dann verschiedene Geschichten.
Solche Abweichungen können unbemerkt bleiben, wenn der Code ungeprüft als aktueller Stand behandelt wird. Reguläre Änderungen sollten über den Code laufen. Notfalleingriffe werden dokumentiert und nachgeführt; ein regelmäßiger Abgleich meldet erfasste Abweichungen [4].
Was sich damit prüfen lässt, bevor etwas passiert
Ein wichtiger Prüfpunkt liegt zwischen Beschreibung und Ausführung. Eine Änderungsvorschau zeigt geplante Aktionen, etwa das Anlegen oder Ersetzen einer Ressource. Ihr Umfang hängt vom Werkzeug und den erfassten Eigenschaften ab; Tests und die Prüfung des tatsächlich ausgeführten Plans bleiben erforderlich.
Teams legen den Plan in den Merge Request: Eine zweite Person sieht, dass die Änderung eine Datenbank löschen würde, bevor sie es tut. Automatische Regeln prüfen denselben Plan auf Verstöße, etwa eine Speicherfreigabe ins offene Internet. Solche Prüfungen ergänzen die Sicherheitskontrollen im laufenden Betrieb.
Beispiel: Terraform, OpenTofu, Bicep und AWS CDK
Terraform unterstützt viele Cloud-Anbieter über Provider. OpenTofu ist ein quelloffener Fork mit verwandter Konfigurationssprache [5]; Versionen und Provider-Kompatibilität müssen beim Wechsel geprüft werden. Bicep beschreibt Azure-Ressourcen, deren Zustand Azure verwaltet. AWS CDK erzeugt CloudFormation-Vorlagen aus Programmiersprachen wie TypeScript oder Python.
Die Wahl richtet sich nach Zielplattform, benötigten Ressourcen, Teamkenntnissen und Betriebsmodell. Gemeinsame Grundsätze sind versionierter Code, geregelte Änderungen und eine Prüfung vor der Ausführung. Wie Zustand, Import und Änderungsvorschau funktionieren, unterscheidet sich je Werkzeug.
Infrastructure as Code beschreibt Infrastruktur und automatisiert ihre Bereitstellung. Versionierung und Reviews machen Änderungen nachvollziehbar. Für den Wiederaufbau bleiben Datensicherungen und erprobte Wiederherstellungsabläufe zusätzlich erforderlich.
Was Sie danach entscheiden können
- Ob eine bestehende, von Hand gebaute Umgebung nachbeschrieben oder neu aufgebaut werden sollte.
- Wie reguläre Änderungen und Notfalleingriffe nachvollziehbar bleiben und Drift erkannt wird.
- Welche Anforderungen an Plattform, Ressourcen und Team die Werkzeugwahl bestimmen.
Häufige Fragen
Ist Infrastructure as Code dasselbe wie GitOps?
Nein, aber sie bauen aufeinander auf. IaC beschreibt die Infrastruktur als Datei. GitOps macht das Repository mit diesen Dateien zur einzigen Quelle der Wahrheit und gleicht die Umgebung laufend dagegen ab.
Lohnt sich das auch für kleine Umgebungen?
Ja. Auch eine kleine Umgebung profitiert von nachvollziehbaren Einstellungen und wiederholbaren Änderungen. Dazu gehören eine verständliche Dokumentation, geregelte Zugänge und ein Wiederherstellungsplan, damit der Betrieb nicht von einer einzelnen Person abhängt.
Kann ich eine bestehende Umgebung nachträglich als Code erfassen?
Das ist häufig möglich. Importfunktionen und unterstützte Ressourcen unterscheiden sich je Werkzeug und Provider. Vor dem ersten Apply müssen die erfasste Konfiguration und die geplanten Änderungen geprüft werden, damit keine unbeabsichtigte Änderung oder Neuerstellung entsteht.
Quellen
- What is infrastructure as code (IaC)? Microsoft Learn
- What is Terraform? HashiCorp Developer
- State HashiCorp Developer
- Manage resource drift HashiCorp Developer
- OpenTofu Introduction OpenTofu
- Idempotent API and CLI operations Amazon Web Services
- Bicep: state management and change previews Microsoft Learn
- Backup and restoration Microsoft Learn