Die IT-Infrastruktur befindet sich in einem stetigen Wandel, und jede einzelne Änderung kann ihre eigenen Probleme mit sich bringen.
Nicht umsonst gibt es Sprichwörter wie "Never change a running system", auch wenn diese nicht ganz ernst gemeint sind.
Um das Risiko zu reduzieren, haben sich Pre-Production- und Testumgebungen durchgesetzt. Doch wenn diese Infrastruktur manuell bereitgestellt werden soll, ergibt sich ein weiteres Problem:
Wenn jede Maschine manuell konfiguriert wird, steigen Pflegeaufwand, Kosten und benötigte Zeit proportional. Um menschliche Fehlerquellen zu reduzieren und die Transparenz zu erhöhen, müssen all diese Änderungen gut dokumentiert werden.
Doch trotz allem gibt es am Ende immer den einen Server, der sich warum auch immer anders verhält als die anderen. Ein Blick in die moderne Softwareentwicklung kann hier helfen, da diese Probleme dort bereits vor langer Zeit erkannt und gelöst wurden.
Was ist Infrastructure as Code?
Um die Lehren der Softwareentwicklung auf die Infrastruktur zu übertragen, benötigt es eine zentrale Sache: maschinenlesbaren Code. Und genau das ist der Kerngedanke hinter Infrastructure as Code, kurz IaC: Die gesamte Infrastruktur wird in Code beschrieben.
Im Gegensatz zu Handbüchern und Anleitungen ist dieser Code versionierbar, reproduzierbar und automatisierbar. Er dient zugleich als präzise und detaillierte Dokumentation und ersetzt damit die Art von Dokumenten, die am häufigsten veraltet oder fehlerbehaftet sind. So bleibt dieser stets aktuell.
Die Versionierung zeigt, wie sich die Infrastruktur im Laufe der Zeit verändert hat. Gerade bei fehlerhaften Updates ist das hilfreich und unterstützt dabei, den Ursprung eines Problems schnell und sicher identifizieren zu können. Die Reproduzierbarkeit erhöht die Aussagekraft verschiedener Testumgebungen. Und da diese ebenfalls in Code existieren, werden auch kleine Unterschiede zwischen ihnen offensichtlicher.
Und dank der Automatisierung des Deployments kann der Aufwand deutlich reduziert werden. Das spart langfristig Zeit und Geld. Auch durch die Änderung des Blickwinkels ergeben sich Vorteile: Bei Fragen schaut man kurz in den Code, statt den aktuellen Zustand auf einer Maschine zu debuggen.
Eine einfache Textsuche liefert oft schon die Antwort. Es wird nun nicht mehr die Konfiguration einer Maschine zur Verifikation von Änderungen betrachtet, sondern die geplanten Änderungen im Code und wird dadurch zu einem einfachen Code Review.
Womit kann Infrastructure as Code umgesetzt werden?
Bisher wurde IaC nur als abstraktes Konzept beschrieben. Doch wie sieht eine Umsetzung konkret aus?
Auch wenn einfache Shell-Skripte im weiteren Sinne ebenfalls als IaC durchgehen könnten, gibt es für die meisten Anwendungsfälle spezialisierte Tools. Generell lassen sich IaC-Werkzeuge in zwei grundlegende Konzepte unterteilen.
Imperative IaC
Die erste Gruppe bilden imperative IaC-Tools.
Hier wird die exakte Abfolge der Schritte beschrieben, die notwendig sind, um einen gewünschten Zustand zu erreichen. Das entspricht einem detaillierten Handbuch für Maschinen: Was zu tun ist, wann und wie.
Bekannte Vertreter dieses Ansatzes sind:
- Ansible: Arbeitet über SSH und eignet sich besonders für Konfigurationsmanagement. Es beschreibt, welche Pakete installiert, welche Dateien kopiert und welche Dienste gestartet werden sollen.
- Shell- oder PowerShell-Skripte: Einfach, aber unflexibel. Sie eignen sich für kleinere Automatisierungen und stoßen bereits bei ansatzweise komplexerer Infrastruktur schnell an Grenzen.
Die Arbeit mit imperativer IaC fällt Administratoren, die aus einem manuellen Alltag kommen, oft leichter, da sie dem gewohnten Prozessdenken entspricht.
Allerdings ist die Nachverfolgbarkeit des Zielzustands schwieriger, und unbeabsichtigte Abweichungen können bestehen bleiben. Beispielsweise führt das reine Entfernen der Installationsschritte für Pakete und Dateien nicht zu deren Deinstallation. Das muss explizit geschehen.
Deklarative IaC
Im Gegensatz dazu beschreibt deklarative IaC nicht die Schritte, sondern den gewünschten Endzustand der Infrastruktur.
Das Tool selbst berechnet, wie es diesen Zustand herstellt oder anpasst. Dadurch werden Änderungen reproduzierbarer und weniger fehleranfällig.
Zu den bekanntesten Tools gehören:
- OpenTofu oder Terraform: Plattformunabhängige Beschreibung von Cloud-Ressourcen. Terraform legt z. B. Netzwerke, virtuelle Maschinen oder Datenbanken an und verwaltet deren Lebenszyklus.
- Cluster API (CAPI): Eine Erweiterung für Kubernetes, die den Lebenszyklus ganzer Cluster beschreibt – ebenfalls deklarativ.
- Kubernetes-Manifeste: Auch Kubernetes selbst ist ein Beispiel für deklaratives IaC – es sorgt dafür, dass der gewünschte Zustand automatisch hergestellt wird. Ein solcher Zustand kann etwa sein, dass eine Anwendung mit einer bestimmten Anzahl an Replikas läuft.
Der deklarative Ansatz reduziert manuelle Eingriffe, da das System selbst erkennt, welche Änderungen notwendig sind. So entsteht ein selbstheilender Effekt: Wenn eine Ressource verloren geht, wird sie automatisch neu erstellt.
Weiterentwicklungen
Mit der Weiterentwicklung von IaC entstanden neue Paradigmen und Werkzeuge, die den Ansatz noch weiter automatisieren.
GitOps
GitOps überträgt das Prinzip von IaC vollständig in den Softwareentwicklungsprozess.
Die Infrastruktur wird nicht nur als Code beschrieben, sondern auch über Git-Repositories gesteuert und somit auch versioniert. Jede Änderung erfolgt als Commit und wird automatisch ausgerollt, sobald sie in den Haupt-Branch übernommen wurde.
Tools wie Flux oder ArgoCD überwachen die Git-Repositories kontinuierlich und gleichen den beschriebenen Zustand mit der tatsächlichen Infrastruktur ab.
Weicht etwas ab, korrigieren sie es automatisch. Damit entsteht ein vollständig versionskontrollierter, auditierbarer und reproduzierbarer Infrastruktur-Lifecycle.
GitOps bringt zudem organisatorische Vorteile: Entwickler, Operations und Security arbeiten auf derselben Basis. Änderungen sind nachvollziehbar, Rollbacks simpel, und Deployments werden zu einem automatisierten Routineprozess.
Environment as Code
Ein weiterer Trend ist Environment as Code.
Während IaC die Infrastruktur und ihre einzelnen Komponenten beschreibt, geht Environment as Code einen Schritt weiter und definiert komplette Umgebungen.
Das Ziel ist es, automatisiert neue Umgebungen bereitzustellen und bei Bedarf wieder abzureißen. So können Teams für Tests, Feature-Branches oder Pull Requests isolierte Testumgebungen automatisch erstellen.
Das steigert die Qualität und Effizienz von Reviews deutlich.
FinOps
Im Rahmen von FinOps werden die Prinzipien von IaC mit dem Kostenmanagement von Cloud-Ressourcen verknüpft.
IaC und GitOps fokussieren sich auf die technische Automatisierung und lassen die Kosten oft außer Acht – gerade wenn Environment as Code hinzukommt, wird Kostentransparenz immer wichtiger.
Genau das adressiert FinOps und liefert einen betriebswirtschaftlichen Einblick. Tools wie Infracost helfen, Kostenentwicklungen sichtbar zu machen.
So lässt sich früh erkennen, ob sich eine neue Umgebung wirtschaftlich lohnt oder welche Komponenten die größten Kostenverursacher sind.
Grenzen und Ausblick
Trotz aller Vorteile ist IaC kein Allheilmittel.
Fehlkonfigurationen im Code wirken sich schnell auf ganze Umgebungen aus, und die Lernkurve für komplexe Toolchains kann hoch sein. Zudem erfordert IaC diszipliniertes Arbeiten mit Versionierung, Testing und Sicherheitsmechanismen.
Der Trend geht jedoch klar in Richtung Policy as Code und plattformübergreifende Automatisierung. IaC wird zunehmend Teil größerer DevOps-Ökosysteme, in denen Infrastruktur, Applikation und Compliance in einem durchgängigen Workflow zusammenlaufen.
Zukünftig werden KI-gestützte Systeme helfen, Änderungen vorzuschlagen oder zu validieren, bevor sie umgesetzt werden.
IaC bei metalstack.cloud
Bei metal-stack und metalstack.cloud setzen wir konsequent auf Infrastructure as Code. Für das Deployment der Plattform-Infrastruktur kommt Ansible zum Einsatz. Die Cluster- und Firewall-Ressourcen selbst werden in Kubernetes-Manifesten deklariert.
Für unsere metalstack.cloud-Kund:innen bieten wir zusätzlich die Möglichkeit, ihre Infrastruktur über OpenTofu oder Terraform mit unserem Provider zu verwalten. Für den Einstieg gibt es einen Developer Guide zur Erstellung eines Clusters.
In metal-stack selbst unterstützen wir außerdem Cluster API mit einem eigenen Provider.
Da Websites im Vergleich zu einem gesamten Rechenzentrum schnell und kosteneffizient bereitgestellt werden können, setzen wir für Pull Requests auf automatisch erzeugte, temporäre Umgebungen.
Diese Review-Umgebungen werden automatisiert erstellt und nach Abschluss des Pull Requests wieder entfernt: ein klassisches Beispiel für Environment as Code.
Bei unseren Kund:innen und internen Projekten fördern wir GitOps-Prinzipien durch die Integration von Flux und ArgoCD.
Fazit
Infrastructure as Code verändert die Art, wie wir Infrastruktur verstehen und betreiben. Anstelle manueller Eingriffe steht nun maschinenlesbarer Code, der Versionierung, Automatisierung und Wiederholbarkeit ermöglicht.
Egal, ob mit Ansible, OpenTofu, Cluster API, Flux oder ArgoCD – der entscheidende Schritt ist die Abkehr von Handarbeit hin zu reproduzierbarer, überprüfbarer und nachvollziehbarer Infrastruktur.
IaC ist keine Modeerscheinung, sondern ein fester Bestandteil moderner Software- und Cloud-Architekturen – und ein unverzichtbares Werkzeug für Teams, die schnell, sicher und konsistent arbeiten wollen.
