Terraform State: was er speichert, weshalb er gesperrt wird und wie sich Drift zeigt

Worum es geht

Die State-Dokumentation (zitiert) beschreibt den primären Zweck von State als das Speichern von Bindungen zwischen Objekten in einem entfernten System und Ressourceninstanzen, die in der Konfiguration deklariert sind: Wenn Terraform ein entferntes Objekt erstellt, hält es die Identität dieses Objekts gegen die Ressourcenadresse fest, damit spätere Änderungen dasselbe Objekt aktualisieren oder löschen. State ist eine JSON-Textdatei; standardmässig liegt sie lokal als terraform.tfstate, und die Dokumentation rät davon ab, sie in der Versionsverwaltung oder in einem Speicher ohne Sperrung und Zugriffskontrolle abzulegen, weil das zu Datenverlust führen oder in der State-Datei gespeicherte Geheimnisse offenlegen kann.

Sperrung (zitiert): Sofern das Backend es unterstützt, sperrt Terraform den State stillschweigend für jede Operation, die ihn schreiben könnte, und verweigert die Fortsetzung, wenn die Sperre nicht erlangt werden kann. force-unlock existiert für eine Sperre, die ein abgestürzter Lauf hinterlassen hat, und verlangt als Absicherung die Sperr-ID.

Warum es wichtig ist

Wenden zwei Personen oder zwei Pipelines gleichzeitig ohne Sperre an, kann jede einen State schreiben, der die Ressourcen der anderen auslässt; der nächste Plan schlägt dann vor, reale Infrastruktur neu zu erstellen oder zu zerstören. Drift, eine in einer Konsole oder durch ein anderes Werkzeug vorgenommene Änderung, ist an sich kein Fehler, bleibt aber bis zum nächsten Plan unsichtbar, und die Plan-Dokumentation (zitiert) warnt, dass routinemässiges Anwenden mit -target zu unentdeckter Konfigurationsdrift führt.

So wird es angewendet

• Ein Remote-Backend mit Sperrung und Versionierung verwenden (Objektspeicher plus Sperrmechanismus, oder ein gehostetes Backend) und den Lesezugriff ebenso streng einschränken wie den Schreibzugriff, da der State Attributwerte wie generierte Passwörter enthält.
• terraform plan -refresh-only regelmässig ausführen, um Drift aufzulisten, ohne Konfigurationsänderungen vorzuschlagen, und je Befund entscheiden, ob die Änderung in den Code übernommen oder rückgängig gemacht wird.
• Pläne mit -out in der CI erzeugen und nach dem Review genau diesen gespeicherten Plan anwenden; -detailed-exitcode verwenden, um eine Prüfung fehlschlagen zu lassen, wenn eine Abweichung besteht.
• Einen State pro Blast Radius führen: Umgebungen trennen und langlebige Grundlagen (Netzwerke, Identität) von häufig geänderten Diensten trennen.
• Ressourcen mit moved-Blöcken verschieben oder umbenennen, statt den State von Hand zu bearbeiten.

Stolpersteine

Ein terraform import oder state rm ändert Bindungen, ohne die Infrastruktur zu berühren, sodass der nächste Plan überraschend aussehen kann. Provider-Upgrades können State-Schemas umschreiben. Die zitierte State-Seite warnt, dass die State-Datei Geheimnisse enthalten kann; eine Variable als sensitive zu markieren verbirgt sie aus der Ausgabe, nicht aus der Datei.