Die meisten Einsteiger halten die State-Datei für ein nebensächliches Nebenprodukt von Terraform. Wer sie löscht, verliert damit das Gedächtnis über die eigene Cloud.

Viele denken, Terraform finde die realen Ressourcen sowieso in der Cloud. Das klingt plausibel, denn Instanzen und Netzwerke sind sichtbar in der Konsole.

Tatsächlich vergleicht Terraform bei jedem Lauf drei Dinge: den Soll-Zustand aus den .tf-Dateien, den Ist-Zustand aus dem State und den realen Zustand in der Cloud. Der State ist Terraforms Gedächtnis; er speichert für jede Ressource, was beim letzten apply, dem Befehl, der Änderungen ausführt, existierte. Ohne ihn weiß Terraform nicht, welche echte Instanz zu welcher Konfigurationszeile gehört.

Der Irrtum entsteht, weil die Ressourcen nach dem Löschen der Datei weiterlaufen. Erst der nächste apply zeigt die Folge: Neue, doppelte Ressourcen entstehen.

In der Konfiguration steht eine EC2-Instanz namens web-server. Nach dem apply landet die Instanz-ID der erzeugten Cloud-Instanz im State. Genau diese ID erlaubt Terraform später, dieselbe Instanz zu aktualisieren, statt eine neue zu bauen.

Woran man es erkennt: terraform plan meldet plötzlich, dass Ressourcen neu erstellt werden sollen, obwohl die Konfiguration unverändert ist. Nach dem darauffolgenden apply zeigt die Konsole dann doppelte Instanzen.

In Teams gehört der State in ein Remote-Backend wie S3, also eine zentrale Ablage, auf die alle zugreifen; Locking über DynamoDB oder S3-Lock-Dateien verhindert gleichzeitige Änderungen. Der State kann Klartext-Passwörter enthalten und ist ein Geheimnis.

State heißt nicht nebensächliches Nebenprodukt, sondern das Gedächtnis, das Konfiguration und reale Ressourcen verbindet. Verlorener State bedeutet: Die Cloud bleibt bestehen, aber Terraform kann sie nicht mehr zuordnen.

📌 State-Datei · Remote-Backend · Locking

📚 Cloud von Grund auf · Tag 5 von 30
#Terraform #iac #aws