Infrastructure as Code (IaC) bezeichnet das Definieren und Bereitstellen von Infrastruktur wie Netzwerken, virtuellen Maschinen, Kubernetes-Clustern, Datenbanken und Cloud-Services über maschinenlesbare Dateien in der Versionsverwaltung. Tools wie Terraform, OpenTofu, Pulumi oder AWS CloudFormation gleichen diese Definition mit der Realität ab und setzen Änderungen um. Umgebungen werden so reproduzierbar, prüfbar und nachvollziehbar.
Was ist Infrastructure as Code?
Infrastructure as Code (IaC) ersetzt das Klicken durch Cloud-Konsolen und spontane Skripte durch Code, der die gewünschte Infrastruktur beschreibt. Eine VPC, eine Managed-Datenbank, eine IAM-Rolle oder ein Kubernetes-Cluster wird zu einem Textblock in einem Git-Repository. Änderungen durchlaufen denselben Workflow wie Anwendungscode: Pull Request, Review, ein automatischer Plan, der zeigt, was sich ändern wird, und ein Apply-Schritt in der CI.
Die Vorteile ergeben sich aus diesem Workflow. Umgebungen lassen sich identisch neu aufbauen, Staging und Produktion laufen nicht mehr auseinander, jede Änderung hat einen Autor und eine Historie, und wiederkehrendes manuelles Provisioning, eine klassische Form von Toil, entfällt. IaC ist außerdem ein Fundament des Platform Engineering, bei dem interne Plattformen wiederverwendbare Module statt Tickets anbieten.
Deklaratives und imperatives IaC
Es gibt zwei grundlegende Ansätze:
- Deklarativ: Sie beschreiben den gewünschten Endzustand („drei Subnetze, ein Load Balancer“), und das Tool ermittelt die nötigen Schritte. So arbeiten Terraform, OpenTofu, CloudFormation und Kubernetes-Manifeste. Wird dieselbe Definition zweimal angewendet, ändert sich beim zweiten Mal nichts. Deklaratives IaC ist also idempotent.
- Imperativ: Sie beschreiben die Schritte („Subnetz anlegen, dann Routing-Tabelle zuordnen“). Shell-Skripte und Cloud-CLIs sind imperativ, Configuration-Management-Tools wie Ansible arbeiten weitgehend prozedural und führen Tasks der Reihe nach aus.
Pulumi und das AWS CDK liegen dazwischen: Sie schreiben Code in einer Allzwecksprache mit Schleifen und Funktionen, das Ergebnis ist aber ein deklarativer Sollzustand, den eine Engine abgleicht.
Gängige Tools für Infrastructure as Code
| Tool | Sprache | Hinweise |
|---|---|---|
| Terraform | HCL | Multi-Cloud über Provider, State-Datei, plan/apply; seit 2023 unter der Business Source License |
| OpenTofu | HCL | Open-Source-Fork von Terraform unter der Linux Foundation, MPL 2.0, weitgehend kompatibel |
| Pulumi | TypeScript, Python, Go, C#, Java, YAML | Echte Programmiersprachen, Tests mit Standard-Frameworks |
| AWS CloudFormation | YAML oder JSON | AWS-nativ, Stacks mit Change Sets und eingebauter Drift Detection; das AWS CDK erzeugt es |
| Azure Bicep / ARM | Bicep, JSON | Azure-native Templates |
| Crossplane | Kubernetes-Ressourcen | Cloud-Ressourcen, verwaltet durch Kubernetes-Controller |
Beispiel: eine Terraform-Ressource
resource "aws_sqs_queue" "orders_dlq" {
name = "orders-dlq"
message_retention_seconds = 1209600 # 14 Tage
tags = { team = "payments", env = "prod" }
}terraform plan (oder tofu plan) zeigt, dass eine Queue angelegt wird. Nach dem Review erstellt apply sie und vermerkt sie in der State-Datei. Ändert später jemand die Aufbewahrungsdauer in der Konsole, meldet der nächste Plan die Abweichung.
Drift Detection
Drift ist jede Abweichung zwischen Code und tatsächlich laufender Infrastruktur, verursacht durch manuelle Hotfixes, Änderungen in der Konsole oder andere Automatisierung. Drift untergräbt das zentrale Versprechen von IaC, denn das Repository beschreibt die Realität nicht mehr. Bewährte Gegenmittel: regelmäßige Läufe von terraform plan -refresh-only oder pulumi preview in der CI, die bei Abweichungen alarmieren, Drift Detection für CloudFormation-Stacks, eingeschränkte Schreibrechte in Produktion, damit Änderungen über die Pipeline laufen, sowie GitOps-Controller, die Kubernetes-Ressourcen fortlaufend abgleichen.
Observability as Code
Dasselbe Prinzip gilt für das Monitoring. Observability as Code heißt, dass Dashboards, Alarmregeln, SLO-Definitionen, synthetische Checks und Konfigurationen des OpenTelemetry Collectors in Git liegen und über die Pipeline ausgerollt werden. Neue Services erhalten so automatisch Standard-Dashboards und -Alarme, Schwellenwerte werden wie Code reviewt, und ein gelöschtes Dashboard lässt sich aus der Historie wiederherstellen. Einheitliche Tags für jede Ressource (Service, Team, Umgebung) zahlen sich auch in der Observability aus, weil dieselben Tags zu filterbaren Attributen werden. Ein pragmatischer Einstieg: Legen Sie Alarmregeln für Prometheus oder OpenTelemetry sowie die Collector-YAML im selben Repository wie den Service ab und validieren Sie beides in der CI vor dem Rollout. So erreicht eine fehlerhafte Pipeline-Konfiguration die Produktion nie ungeprüft, und jede Änderung an einem Schwellenwert bleibt nachvollziehbar.
Best Practices und typische Fehler
- State remote speichern und sperren; State-Dateien nie committen, da sie Secrets enthalten können.
- Kleine, wiederverwendbare Module mit klaren Eingaben statt einer riesigen Konfiguration.
- Secrets aus dem Code heraushalten und auf einen Secrets Manager verweisen.
- Pläne prüfen, nicht nur Diffs; eine einzeilige Änderung kann eine Datenbank ersetzen.
- Manuelle und codierte Änderungen nicht mischen, zumindest nicht an denselben Ressourcen.
- Offene Formate bevorzugen, um Vendor-Lock-in bei Infrastruktur und Telemetrie zu begrenzen.
Wie Obseria hilft
Obseria bietet eine API und eine CLI, um Konfiguration programmatisch zu verwalten, und mit Automation definieren Sie Workflows als Code. Deployment-Ereignisse aus Ihren Pipelines lassen sich mit Metriken, Logs und Traces korrelieren. Eine Infrastrukturänderung, die einen Service verschlechtert, erscheint so direkt neben ihrer Auswirkung.
