Infrastructure as Code (IaC) behandelt Infrastruktur – Server, Load Balancer, Datenbanken, Netzwerkregeln – als Software. Statt dich durch eine Cloud-Konsole zu klicken oder Hardware manuell zu konfigurieren, schreibst du die gewünschte Infrastruktur in eine versionskontrollierte Textdatei (JSON, YAML, HCL oder Python), und ein Bereitstellungstool (Terraform, CloudFormation, Pulumi, Ansible) liest diese Datei und erstellt oder aktualisiert echte Ressourcen, um sie anzupassen.
IaC funktioniert, indem du deinen gewünschten Endzustand im Code deklarierst. Eine Bereitstellungs-Engine vergleicht diese Deklaration mit dem aktuellen Zustand, berechnet den Unterschied und wendet nur die notwendigen API-Aufrufe auf deinen Cloud-Provider an. Das macht Infrastruktur wiederholbar, prüfbar und leicht zu versionieren – dieselbe Datei zweimal bereitgestellt ergibt das gleiche Ergebnis.
Beispiel: Eine Terraform-Datei, die einen Web-Server deklariert, könnte so aussehen:
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
tags = {
Name = "production-server"
}
}
Das Ausführen von terraform apply erstellt exakt diese EC2-Instanz; es erneut auszuführen ändert nichts (Idempotenz).
IaC reduziert manuelle Fehler, verkürzt die Bereitstellungszeit und funktioniert gut mit Health Checks und Monitoring, um Fehlkonfigurationen früh zu erkennen. Teams kombinieren es oft mit automatisierten Tests, um Fehler in der Definitionsdatei zu finden, bevor sie in die Produktionsumgebung gehen.
WarningKonfigurationsdrift ist ein echtes Risiko: Wenn jemand eine Ressource in der Cloud-Konsole außerhalb deines IaC-Tools manuell ändert, fällt der aufgezeichnete Zustand des Tools aus der Synchronisation mit der Realität. Regelmäßige Drifterkennung und -behebung (oder eine Richtlinie, Infrastruktur immer über Code zu ändern) verhindert dies.