Infrastructure as Code und Immutable Infrastructure

Was Infrastructure as Code ist

Infrastructure as Code (IaC) bedeutet, Netzwerke, virtuelle Maschinen, Cluster, Datenbanken, Queues, DNS-Einträge, Berechtigungen und jedes andere Stück Infrastruktur in Textdateien unter Versionsverwaltung zu definieren und Tools die realen Ressourcen aus diesen Dateien erstellen und ändern zu lassen. Statt dass sich jemand durch eine Cloud-Konsole klickt, ist eine Änderung ein Commit: in einem Pull Request geprüft, in einer Pipeline getestet, automatisch angewendet und für immer festgehalten.

Die Idee ist älter als die Public Cloud. Mark Burgess’ CFEngine (1993) verwaltete Unix-Maschinen anhand deklarativer Richtlinien; Puppet (2005), Chef (2009) und Ansible (2012) brachten das Konfigurationsmanagement in den Mainstream. Die Cloud machte es unverzichtbar, weil die Infrastruktur selbst über APIs verfügbar wurde: AWS CloudFormation (2011) und HashiCorps Terraform (2014) beschreiben ganze Umgebungen, nicht nur die Software auf Servern. Kief Morris’ Buch Infrastructure as Code, inzwischen in der dritten Auflage (2025), ist die Standarddarstellung der Praxis und ihrer Prinzipien.

Die Vorteile sind die des Software-Engineerings, angewandt auf Infrastruktur. Umgebungen werden reproduzierbar: Staging lässt sich aus denselben Definitionen bauen wie die Produktion, und eine Region lässt sich nach einer Katastrophe aus Code statt aus dem Gedächtnis neu aufbauen. Änderungen werden überprüfbar und auditierbar, was Aufsichtsbehörden und Sicherheitsteams schätzen. Wissen steckt nicht mehr nur im Kopf eines einzelnen Engineers. Und das Tempo steigt, weil das Erstellen einer Umgebung für einen neuen Service der Essenslieferplattform zu einem Pull Request wird statt zu einem Ticket, das zwei Wochen wartet.

Deklarativ oder imperativ

Ein imperativer Ansatz listet die Schritte auf: ein Netzwerk erstellen, dann ein Subnetz, dann eine Datenbank, dann diesen Port öffnen. Wer das Skript zweimal ausführt, versucht alles zweimal zu erstellen. Ein deklarativer Ansatz beschreibt den Endzustand, den gewünschten Zustand aus Abschnitt 10.2: ein Netzwerk mit diesen Subnetzen, eine Datenbank dieser Größe, eine Firewall, die diesen Port erlaubt. Das Tool vergleicht die Beschreibung mit dem, was existiert, und ermittelt die Schritte, sodass ein zweites Anwenden nichts mehr ändert. Diese Eigenschaft, die Idempotenz, macht Infrastrukturcode sicher für wiederholte und automatisierte Ausführung.

Die meisten ausgereiften Tools sind im Kern deklarativ, unterscheiden sich aber in der Sprache, in der die Deklaration geschrieben wird, und darin, wer festhält, was existiert. Die Tabelle fasst die wichtigsten Familien zusammen.

Die Tools und der Fork OpenTofu

Terraform wurde zum meistgenutzten Multi-Cloud-Tool, weil eine Sprache und ein Workflow Tausende von Providern abdecken: AWS, Azure, Google Cloud, Cloudflare, Kubernetes, GitHub, Monitoring-Dienste und mehr. Am 10. August 2023 stellte HashiCorp Terraform von der Open-Source-Lizenz Mozilla Public License 2.0 auf die Business Source License 1.1 um, die interne und kommerzielle Nutzung erlaubt, aber verbietet, es in Produkten anzubieten, die mit HashiCorps eigenen konkurrieren. Version 1.5.7 war das letzte Release unter der alten Lizenz.

Die Antwort der Community war ein Fork. Innerhalb weniger Tage erschien ein Manifest, das eine Rückkehr zu Open Source forderte; im September 2023 nahm die Linux Foundation den Fork als OpenTofu auf; sein erstes stabiles Release, 1.6.0, folgte im Januar 2024; und 2025 wurde es als Sandbox-Projekt in die CNCF aufgenommen. IBM schloss die Übernahme von HashiCorp im Februar 2025 ab. Die beiden Tools bleiben in Sprache und Providern weitgehend kompatibel, entwickeln sich aber bei den Funktionen auseinander: OpenTofu hat zum Beispiel eine clientseitige Verschlüsselung des State ergänzt, während Terraforms kommerzielle Plattform eigene Fähigkeiten hinzugefügt hat. Für Architektinnen und Architekten erinnert die Episode daran, dass Lizenz und Governance eines Tools Teil seines Risikoprofils sind und dass offene Standards und eine glaubwürdige Alternative dieses Risiko beherrschbar halten.

Unter den Tools für eine einzelne Cloud werden AWS CloudFormation (2011) und Microsofts Bicep (2020 eingeführt, kompiliert zu Azure-Resource-Manager-Templates) vom Anbieter betrieben, der festhält, was existiert, sodass kein State-File zu verwalten ist, um den Preis der Bindung an eine Cloud. Pulumi (2018) und das AWS CDK lassen Entwickler Infrastruktur in Universalsprachen schreiben; Crossplane erweitert Kubernetes, um Cloud-Ressourcen per Abgleich zu verwalten. Die richtige Wahl hängt davon ab, welche Clouds Sie nutzen, von den Fähigkeiten Ihres Teams, der Reife der benötigten Provider, der Lizenzpolitik und dem, was der Rest der Organisation bereits einsetzt; Einheitlichkeit über Teams hinweg ist meist mehr wert als die Vorzüge eines einzelnen Tools im Detail.

terraform {
  required_version = ">= 1.6"
  backend "gcs" {                 # remote state; this backend locks natively
    bucket = "fd-infra-state"
    prefix = "orders/prod"
  }
}

variable "environment" { type = string }

module "orders_db" {
  source      = "git::https://git.example.com/modules/postgres.git?ref=v3.2.0"
  name        = "orders-${var.environment}"
  size        = var.environment == "prod" ? "large" : "small"
  high_avail  = var.environment == "prod"   # standby in a second zone
  backup_days = 14
}

output "orders_db_host" {
  value = module.orders_db.host
}

Das Ausführen von tofu plan (oder terraform plan) zeigt, was sich ändern würde, bevor irgendetwas passiert. Der Plan ist das wichtigste Artefakt im Workflow: Reviewer lesen ihn im Pull Request neben dem Code, und genau er wird angewendet.

  # module.orders_db.google_sql_database_instance.this will be updated in-place
  ~ resource "google_sql_database_instance" "this" {
      ~ settings {
          ~ tier = "db-custom-2-8192" -> "db-custom-4-16384"
        }
    }

Plan: 0 to add, 1 to change, 0 to destroy.

State, Locking und Drift

Deklarative Tools müssen wissen, welche realen Ressourcen zu welchen Definitionen gehören. Terraform und OpenTofu halten das im State fest: einer Datei, die jede Ressource im Code der Kennung des realen Objekts zuordnet, mit ihren zuletzt bekannten Attributen. Die Planung vergleicht drei Dinge: den Code (was existieren soll), den State (was das Tool erstellt hat) und die reale Infrastruktur, gelesen über die API des Providers (was tatsächlich existiert).

Der State braucht Sorgfalt, weil er kritisch und sensibel ist. Er muss remote gespeichert werden (in Object Storage oder einem verwalteten Dienst), nicht auf einem Laptop, damit das ganze Team und die Pipeline dieselbe Version teilen. Er muss während Änderungen gesperrt sein, damit sich zwei Applies nicht überlagern und ihn beschädigen. Er muss gesichert und versioniert werden, weil ein verlorenes State-File das Tool ohne Kenntnis der Ressourcen lässt, die es erstellt hat. Und er ist ein Secret: Der State enthält oft Datenbankpasswörter und Schlüssel im Klartext, also muss der Zugriff darauf beschränkt und er im Ruhezustand verschlüsselt sein (OpenTofu kann ihn auch clientseitig verschlüsseln).

Drift ist jede Abweichung zwischen Code und Realität, meist durch hastige manuelle Änderungen, durch ein anderes Tool, das dieselbe Ressource anfasst, oder durch einen teilweisen Fehlschlag beim Apply. Drift ist gefährlich, weil der nächste Apply stillschweigend eine Änderung zurücknehmen kann, auf die sich jemand verlassen hat, oder in der Produktion an einer Abweichung scheitert, von der niemand wusste. Teams erkennen sie, indem sie regelmäßig (zum Beispiel nächtlich) einen Plan ausführen und bei jeder vorgeschlagenen Änderung alarmieren, und verhindern sie, indem sie Schreibzugriff in der Konsole auf ein protokolliertes Break-Glass-Verfahren beschränken.

Der State bestimmt auch den Blast Radius. Ein riesiger State für ein ganzes Unternehmen bedeutet, dass jeder Plan langsam ist, jeder Apply alles riskiert und ein einziger Lock jedes Team blockiert. Den State nach Komponente und Umgebung aufzuteilen (Netzwerk, gemeinsamer Cluster, die Ressourcen jedes Service; Produktion getrennt von Staging) hält Pläne schnell und Ausfälle begrenzt, um den Preis, Ausgaben wie Netzwerkkennungen zwischen States weiterzugeben. Refactoring wird unterstützt: moved-Blöcke benennen Ressourcen um, ohne sie zu zerstören, und import übernimmt bestehende, von Hand erstellte Ressourcen in die Verwaltung.

Module und Umgebungen

Ein Modul ist eine wiederverwendbare Einheit von Infrastrukturcode mit Eingaben und Ausgaben: eine PostgreSQL-Datenbank mit Backups und Monitoring, das Netzwerk und der Load Balancer eines Service, ein Standard-Namespace in Kubernetes mit seinen Quotas und Policies. Ein gutes Modul wendet das Information Hiding aus Kapitel 3 an: eine kleine Schnittstelle (Name, Größe, Hochverfügbarkeit ja oder nein) vor den vielen providerspezifischen Details, die ein Service-Team nicht kennen müssen sollte. Module werden wie Bibliotheken versioniert und veröffentlicht, und Umgebungen verweisen auf eine bestimmte Version, wie das ref=v3.2.0 im Beispiel, sodass eine Moduländerung die Produktion erst erreicht, wenn jemand bewusst aktualisiert.

Umgebungen sollten aus denselben Modulen mit unterschiedlichen Eingaben gebaut werden, nicht aus kopiertem Code. Ein gängiger Aufbau ist ein Verzeichnis (oder Repository) pro Umgebung und Komponente, jeweils mit eigenem State, das gemeinsame, versionierte Module aufruft; eine Änderung wird befördert, indem man Modulversion oder Eingaben zuerst im Staging, dann in der Produktion aktualisiert. Per Copy-and-paste erstellte Umgebungen laufen innerhalb von Monaten auseinander, bis Staging nichts mehr über die Produktion aussagt. Workspaces, die einer Konfiguration mehrere States geben, eignen sich besser für kurzlebige Kopien wie Testumgebungen pro Branch als für langlebige Produktions- und Staging-Umgebungen.

Hüten Sie sich vor Überabstraktion. Ein Modul mit vierzig booleschen Eingaben, das jedem Team dienen will, ist so schwer zu ändern wie der Code, den es ersetzt hat. Besser sind wenige meinungsstarke Module, die die Standards der Organisation abbilden; genau das bietet ein Plattformteam in Abschnitt 10.7 als Golden Path an.

Immutable Infrastructure oder Konfigurationsmanagement

Tools für Konfigurationsmanagement halten langlebige Server in einem beschriebenen Zustand: Ansible verbindet sich per SSH und pusht Änderungen ohne Agent; Chef und Puppet betreiben Agenten, die ihre Konfiguration abrufen und regelmäßig darauf konvergieren. Das funktioniert, aber jeder Server sammelt Historie an: Pakete, die während eines Incidents installiert wurden, von Hand bearbeitete Dateien, halb angewendete Updates. Martin Fowler nannte das Ergebnis einen Snowflake Server, einzigartig und nicht reproduzierbar, und schlug als Heilmittel den Phoenix Server vor, der regelmäßig niedergebrannt und von Grund auf neu aufgebaut wird.

Immutable Infrastructure, ein Begriff, den Chad Fowler 2013 bekannt machte, führt das Heilmittel zu Ende: einen laufenden Server nie ändern. Jede Änderung, ob ein Anwendungsrelease oder ein Betriebssystem-Patch, erfolgt durch den Bau eines neuen Images (eines Container-Images oder eines Maschinen-Images mit einem Tool wie Packer), seinen Test und das Ersetzen der alten Instanzen, typischerweise per Rolling- oder Blue-Green-Deployment. Container auf Kubernetes sind standardmäßig unveränderlich. Die Vorteile sind keine Drift, identische Instanzen, mühelos wiederholbare Umgebungen und Rollback durch erneutes Deployment des vorherigen Images; die Kosten sind eine Image-Pipeline, der Bedarf an entsorgbaren, zustandslosen Prozessen (Abschnitt 10.3) und eine längere Durchlaufzeit für eine einzelne dringende Änderung.

Konfigurationsmanagement ist nicht verschwunden. Es bleibt das richtige Werkzeug für Landschaften, die sich nicht als Ganzes ersetzen lassen: On-Premises-Server, Netzwerkausrüstung, Datenbanken auf dedizierter Hardware und die Basis-Images selbst, die oft gebaut werden, indem Ansible innerhalb des Image-Builds läuft. Die architektonische Regel lautet, Veränderlichkeit so weit nach unten und so früh wie möglich zu verlagern: beim Bau der Images konfigurieren und dann das Laufende als schreibgeschützt behandeln.

GitOps

GitOps wendet den Reconciliation Loop aus Abschnitt 10.2 auf ganze Umgebungen an. Den Begriff prägte 2017 Alexis Richardson von Weaveworks, dem Unternehmen hinter dem Tool Flux. Das Projekt OpenGitOps, eine Arbeitsgruppe der CNCF, definiert vier Prinzipien: Der gewünschte Zustand ist deklarativ; er ist versioniert und unveränderlich, mit vollständiger Historie; er wird von Software-Agenten automatisch abgerufen; und er wird fortlaufend abgeglichen, wobei Agenten den tatsächlichen Zustand beobachten und den gewünschten anwenden. Die beiden führenden Agenten, Argo CD und Flux, sind graduierte CNCF-Projekte; Flux wurde nach der Schließung von Weaveworks 2024 als Community-Projekt fortgeführt.

Das Pull-Modell hat einen Sicherheitsvorteil gegenüber einer Pipeline, die Änderungen in den Cluster pusht: Das CI-System braucht keine Zugangsdaten für die Produktion, weil der Agent im Cluster selbst abruft, was er ausführen soll. Git wird zum Audit-Log und zur Schnittstelle für Änderungen, auch im Betrieb: Einen Service zu skalieren oder zurückzurollen ist ein geprüfter Commit oder ein Revert. Drift wird automatisch korrigiert, sodass ein manuelles kubectl edit nur bis zur nächsten Synchronisierung hält.

GitOps bringt eigene Entwurfsfragen mit. Secrets dürfen nicht im Klartext in Git liegen; Teams verschlüsseln sie (SOPS, Sealed Secrets) oder speichern Referenzen, die der External Secrets Operator aus einem Secrets Manager auflöst. Die Beförderung zwischen Umgebungen braucht eine Konvention, etwa ein Verzeichnis pro Umgebung mit Pull Requests, die einen neuen Image-Digest von Staging in die Produktion kopieren. Die automatische Drift-Korrektur muss in manchen Notfällen bewusst pausiert werden, und die Struktur des Repositorys muss die Zuständigkeiten abbilden, damit Teams ihre eigenen Services ändern können, ohne die anderer anzufassen. GitOps ist für Kubernetes am natürlichsten, aber dieselben Prinzipien gelten für Cloud-Infrastruktur über Crossplane oder über Pipelines, die Infrastrukturcode aus gemergten Commits planen und anwenden.

Policy as Code

Policy as Code drückt Regeln über Infrastruktur als maschinell prüfbaren Code aus statt als Wiki-Seite: Storage-Buckets dürfen nicht öffentlich sein, Datenbanken müssen verschlüsselt und gesichert sein, jede Ressource muss ein Tag für Verantwortliche und Kostenstelle tragen, nur zugelassene Regionen dürfen genutzt werden, Container dürfen nicht als Root laufen, Produktions-Images müssen aus der Registry des Unternehmens stammen. Die Prüfungen laufen an mehreren Stellen: auf dem Plan im Pull Request (Open Policy Agent mit Conftest, Checkov, HashiCorp Sentinel in seinen kommerziellen Produkten), bei der Zulassung in einen Kubernetes-Cluster (OPA Gatekeeper, Kyverno) und fortlaufend gegen laufende Ressourcen (Policy-Dienste der Cloud-Anbieter).

Policy as Code macht Governance von einem Review-Meeting zu einer schnellen, einheitlichen Leitplanke, die sich im Pull Request selbst erklärt. Sie funktioniert am besten, wenn Policies wenige, klar begründet, versioniert und wie jeder Code getestet sind, wenn sie im Warnmodus beginnen, bevor sie blockieren, und wenn es ein protokolliertes Ausnahmeverfahren gibt. Kapitel 11 behandelt, wie solche automatisierten Prüfungen in die Architektur-Governance passen (Architektur-Governance in agilen Organisationen).