Wie funktioniert Terraform State, und wie verwaltest du ihn im Team?

State ist Terraforms Aufzeichnung darüber, welche echten Ressourcen zu welchen Konfigurationsadressen gehören, plus gecachte Attribute für die Plan-Berechnung. Im Team muss er in einem Remote Backend mit Locking liegen, etwa S3 mit nativem Lockfile-Support oder ein Managed Backend, damit nicht zwei Applies gleichzeitig laufen. Niemals in git committen, denn er enthält Secrets im Klartext, und lieber nach Blast Radius aufteilen als eine riesige Datei zu pflegen.

State ist die Karte zwischen dem, was ich im Code geschrieben habe, und dem, was beim Provider tatsächlich existiert, geschlüsselt über die Ressourcenadresse, plus ein Attribut-Cache, damit ein Plan nicht alles frisch lesen muss. Im Team liegt er in einem Remote Backend mit Locking, damit zwei gleichzeitige Applies ihn nicht korrumpieren. Was Leute überrascht: State enthält Ressourcenattribute wortwörtlich, also stehen Datenbankpasswörter und generierte Keys im Klartext drin. Der Bucket ist deshalb verschlüsselt, versioniert und auf die Pipeline-Rolle beschränkt, nicht für alle lesbar. Beim Layout teile ich nach Blast Radius und Änderungsrate. Networking und Accounts ändern sich selten und bekommen eigenen State, jeder Service oder jede Umgebung bekommt eigenen, und sie lesen voneinander über Data Sources oder veröffentlichte Outputs statt über ein Root-Modul, das alles hält. Der praktische Grund: Eine State-Datei mit fünfhundert Ressourcen macht jeden Plan langsam und jeden Fehler riesig. Für Recovery verlasse ich mich auf Bucket-Versionierung plus state mv und import statt die Datei von Hand zu editieren.