Die meisten denken, der Terraform-Code enthalte ihre Infrastruktur komplett. Dabei beschreibt er nur das Ziel – die Zuordnung zu echten Cloud-Ressourcen steckt woanders.

Deshalb zählt der State: Ohne ihn weiß Terraform nicht, welche Objekte in der Cloud ihm gehören. Ein versehentlich gelöschter State bedeutet doppelte Ressourcen und laufende Kosten.

📦 Der State ist die Karte, die verzeichnet, welches Haus aus welchem Bauplan gebaut wurde. Der Code ist der Plan, die Cloud das Haus. Der State, eine JSON-Datei, speichert für jede Ressource ihre ID in der Cloud und ihre Attribute. Bei jedem terraform plan vergleicht Terraform drei Dinge: Code, State und die echte Cloud. Erst die Unterschiede ergeben den Änderungsplan.

🔑 Der Code kann die Zuordnung allein nicht leisten, weil die Cloud bei der Erstellung oft zufällige IDs vergibt. Etwa eine EC2-Instanz: Im Code steht ihre gewünschte Größe, aber nicht, welches konkrete Objekt daraus entstand. Der State hält genau diese erzeugte ID neben dem Ressourcennamen aus dem Code fest. Ohne State meldet terraform plan für jede Ressource „create“.

📈 Der State wird nie von Hand bearbeitet, gelöscht oder doppelt gepflegt. Er kann vertrauliche Werte wie erzeugte Passwörter im Klartext enthalten. Im Team bewährt sich ein Backend, also ein zentraler Ablageort mit Locking: Immer nur ein Lauf verändert den State. Versionierung des Backends erhält ältere Fassungen für die Rückkehr nach Fehlern.

Der State heißt nicht die Konfiguration, sondern das Gedächtnis: Er dokumentiert den Ist-Zustand, während der Code das Ziel beschreibt.

📌 State als Zuordnungskarte · Backend mit Locking · plan vergleicht drei Dinge

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