Konfiguration und State sehen auf den ersten Blick wie zwei Beschreibungen derselben Infrastruktur aus. Dabei sagt die eine nur, wie etwas aussehen soll – die andere, was wirklich existiert.

Die Verwechslung liegt nahe, weil beide Dateien dieselben Ressourcen nennen. Wer nur die Konfiguration liest, glaubt deshalb, Terraform brauche nichts weiter.

Die Konfiguration ist der Bauplan. In HCL, der Sprache von Terraform, wird dort beschrieben, welche Ressourcen gewünscht sind und mit welchen Einstellungen. Steht darin eine VPC (das private Netz in der Cloud), legt der Code Name und IP-Adressbereich fest, etwa als Adressbereich mit Netzpräfix. Die Konfiguration sagt aber nicht, welches echte Netz die Cloud daraus gebaut hat.

Der State ist das Gedächtnis. Er ist im Kern eine kleine Datenbank, in der Terraform für jede Ressource die konkrete Kennung speichert, die die Cloud vergeben hat, samt den aktuellen Attributen. Für die Beispiel-VPC merkt er sich ihre ID, den Adressbereich und die zugehörigen Subnetze. Aus der Differenz zwischen Konfiguration und State berechnet terraform plan die Änderungen.

Ohne State hält Terraform die VPC für nicht vorhanden und würde bei apply alles neu anlegen, obwohl die echten Objekte längst laufen. Der State ist deshalb kein Anhängsel, sondern Voraussetzung für jeden sauberen Plan.

Faustregel: Den State zentral in einem Remote-Backend, also einer zentralen Ablage wie S3, ablegen, nie lokal in Git, und per State-Locking schützen, das zwei gleichzeitige Läufe am selben State verhindert. Drift durch manuelle Konsolenänderungen macht terraform plan sichtbar. Sensible Werte im State wie ein Geheimnis behandeln.

Der State heißt nicht Kopie der Konfiguration, sondern Zuordnung zwischen Wunsch und Wirklichkeit – fehlt sie, baut Terraform doppelt.

📌 Terraform State · Konfiguration vs. Realität · Remote-Backend

📚 Cloud von Grund auf · Tag 6 von 30
#Terraform #iac #devops