Der Terraform-Code beschreibt eine EC2-Instanz – doch welche von hundert echten Instanzen gehört dazu? Ohne das Gedächtnis des State bleibt das Raten.

Wer den State nicht kennt, verliert die Zuordnung zwischen Code und Cloud – und erstellt bei jedem Lauf Duplikate. Wer ihn versteht, weiß, warum terraform plan überhaupt weiß, was zu ändern ist.

Der Code beschreibt nur, wie eine Ressource aussehen soll, etwa eine EC2-Instanz mit einer bestimmten Größe – welches konkrete Objekt in der Cloud daraus entstanden ist, hält allein der State fest.

Ein Beispiel: Der Code definiert eine Ressource namens webserver. Beim Erstellen vergibt die Cloud eine zufällige ID, etwa eine Nummer, und der State speichert genau diese ID neben dem Ressourcennamen aus dem Code. Bei jedem terraform plan vergleicht Terraform die Konfiguration im Code, den Stand im State und die realen Ressourcen – aus den Unterschieden leitet es den Änderungsplan ab.

Verwechselt wird der State gern mit dem Code selbst – dabei ist der Code der Bauplan, die Cloud das Haus, und der State die Karte, die verzeichnet, welches Haus aus welchem Plan gebaut wurde. Ein S3-Bucket, der außerhalb von Terraform erstellt wurde, bleibt unsichtbar, bis er importiert wird.

Die State-Datei wird nie von Hand bearbeitet oder gelöscht. Verliert man sie, erstellt Terraform bei einem apply alles neu – die alten Ressourcen laufen weiter und kosten Geld. Deshalb gehört der State in ein Backend, also einen zentralen, gemeinsam genutzten Speicherort, mit Versionierung und Zugriffskontrolle; im Team stellt Locking sicher, dass nur ein Lauf den State verändert. Da der State Passwörter im Klartext enthalten kann, gilt: nie eine zweite, abweichende Kopie pflegen.

Terraform weiß ohne ihn nicht, was ihm gehört.

📌 State = Gedächtnis · Dreiwege-Vergleich bei plan · Remote mit Locking

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