Terraform im Enterprise — Infrastructure as Code Lessons Learned

Zwei Jahre, über 200 Terraform-Module, 3 Cloud-Provider. Wir teilen unsere Lessons Learned aus einem Enterprise-Terraform-Setup.

Modul-Architektur¶

Hierarchie: Root Modules (pro Umgebung, pro Projekt) rufen Shared Modules (wiederverwendbare Komponenten) auf. Shared Modules in einer privaten Terraform Registry. Versioniert, getestet, dokumentiert.

State Management¶

Azure Storage Account + State Locking. Getrennte State-Dateien pro Umgebung. Niemals manuelles terraform apply — alles läuft über CI/CD. State-Backup alle 6 Stunden.

Drift Detection¶

Jemand ändert eine Ressource manuell im Portal → Drift. Ein tägliches terraform plan in der CI erkennt Drift und sendet eine Benachrichtigung. Null Toleranz: Drift wird innerhalb von 24 Stunden behoben.

CI/CD-Pipeline¶

PR → terraform plan → Review → Merge → terraform apply. Plan-Output als PR-Kommentar — der Reviewer sieht genau, was sich ändern wird. Sentinel Policies: blockieren unsichere Änderungen (z. B. öffentlicher S3 Bucket).

IaC = Disziplin, nicht ein Tool¶

Terraform ist mächtig, aber ohne Prozesse (Review, Testing, Drift Detection) ist es nur ein anderer Weg, Infrastruktur kaputt zu machen.