Terraform im Team: State-Aufteilung, Blast Radius und geprüfte Pläne

Die State-Datei ist die eigentliche Grenze

Jedes terraform apply kann alles im State ändern, auf dem es arbeitet. Damit ist der State, nicht das Modul, die Einheit des Risikos. Mit einem einzigen State für eine ganze Umgebung laufen ein Tippfehler in einem DNS-Eintrag und eine Änderung an der Produktionsdatenbank durch denselben Plan — und dessen Berechnung dauert Minuten.

Nach Lebenszyklus und Blast Radius aufteilen

Gruppieren Sie Ressourcen, die sich gemeinsam ändern und gemeinsam ausfallen. Eine übliche Aufteilung trennt pro Umgebung:

• Fundament: Accounts, Netzwerke, DNS-Zonen — selten geändert.
• Daten: Datenbanken, Buckets, Queues — vorsichtig geändert und vor Löschung geschützt.
• Compute und Services: Cluster, Funktionen, Load Balancer — häufig geändert.

Jede Schicht liest die Outputs der darunterliegenden und verwaltet nie deren Ressourcen. Umgebungen teilen dieselben Module, haben aber getrennte States und Zugangsdaten, sodass ein apply in Staging die Produktion nicht berühren kann.

Remote State, Locking und Versionen

• Halten Sie den State in einem Remote-Backend mit aktiviertem Locking und Versionierung — nie in Git und nie auf einem Laptop.
• Committen Sie die Lock-Datei der Abhängigkeiten (.terraform.lock.hcl) und pinnen Sie Modulversionen, damit ein Plan heute und einer im nächsten Monat denselben Code ausführen.
• Schützen Sie zustandsbehaftete Ressourcen mit prevent_destroy und mit dem Löschschutz des Providers.

Plan bei jedem Pull Request, apply des Geprüften

Führen Sie terraform plan in der CI für jede Änderung aus und posten Sie das Ergebnis am Pull Request. Wenden Sie nach der Freigabe den gespeicherten Plan an, statt neu zu planen, damit die Produktion genau das bekommt, was die Reviewer gelesen haben; hat sich der State zwischenzeitlich geändert, lehnt Terraform den veralteten Plan ab. Die Pipeline sollte sich mit kurzlebigen Zugangsdaten über OIDC-Föderation authentifizieren, nicht mit langlebigen Schlüsseln in Secrets.

terraform init -input=false
terraform plan -input=false -lock-timeout=5m -out=tfplan
terraform show -no-color tfplan > plan.txt   # attach to the pull request

# after approval, applying the same saved plan:
terraform apply -input=false tfplan

Drift regelmäßig erkennen

Änderungen in der Konsole passieren weiterhin, meist während Incidents. Ein geplanter Job mit terraform plan -detailed-exitcode findet sie: Exit-Code 0 bedeutet keine Änderungen, 2 bedeutet, dass die echte Infrastruktur vom Code abweicht, und 1 bedeutet einen Fehler. Machen Sie aus einer 2 ein Ticket und übernehmen Sie die Änderung dann in den Code oder machen Sie sie rückgängig.

Regeln vor dem apply

Regeln wie „keine öffentlichen Buckets“ oder „jede Ressource hat ein Owner-Tag“ prüft eine Maschine besser als ein Reviewer am Ende eines langen Tages. Policy-as-Code-Werkzeuge wie Open Policy Agent über Conftest können die JSON-Form des Plans (terraform show -json) in der CI auswerten und den Merge blockieren.