Terraform-Module — Best Practices für Enterprise

Wir haben mit einer einzigen großen main.tf begonnen. Heute haben wir eine Bibliothek von über 30 Modulen, CI/CD für Infrastruktur und automatisiertes Testing. Wir teilen die Muster, die für uns funktionieren.

Repository-Struktur¶

terraform/
  modules/          # shared modules
    vpc/
    eks-cluster/
    rds/
    s3-bucket/
  environments/     # per-environment configuration
    dev/
    staging/
    production/
  global/           # shared resources (IAM, DNS)

Modul-Design-Prinzipien¶

• Single Responsibility: Ein Modul macht eine Sache gut
• Explizite Inputs/Outputs: Keine hartcodierten Werte
• Vernünftige Defaults: Funktioniert out of the box, anpassbar
• Versionierung: Git-Tags, Semantic Versioning
• Dokumentation: README mit Beispielen für jedes Modul

Infrastruktur-Testing¶

Terratest (Go-Framework): Erstellt reale Infrastruktur in einem Test-Account, überprüft die Funktion und zerstört sie wieder. Langsam, aber zuverlässig. Läuft in der CI-Pipeline beim Merge in main.

State Management¶

Separater State pro Umgebung. S3-Backend mit DynamoDB-Locking. State-Verschlüsselung at Rest. Minimaler Zugang zum State — nur CI/CD-Pipeline und Senior Engineers.

Sentinel/OPA-Policies¶

Terraform plan durchläuft einen Policy-Check: keine öffentlichen S3-Buckets, obligatorische Verschlüsselung, obligatorische Tags. Automatische Durchsetzung in der CI-Pipeline — Plans, die gegen Policies verstoßen, kommen nicht durch.

Terraform im Enterprise erfordert Disziplin¶

Module, Testing, Policies, Code Review — Terraform-Infrastruktur verdient die gleiche Sorgfalt wie Anwendungscode. Denn ein Fehler in Terraform kann die Produktion löschen.