Terraform State (.tfstate)

Lokal (Standard): Die Datei liegt auf deinem Laptop. Problem: Wenn dein Kollege terraform apply macht, hat er deinen State nicht. Er macht alles kaputt. Lösung: Remote State. Speichere den State in der Cloud (S3 Bucket, Azure Blob, Terraform Cloud).

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/app.tfstate"
  }
}

Jetzt greifen alle auf dieselbe, zentrale Wahrheit zu.

1. State Locking (DynamoDB)

Wenn zwei Admins gleichzeitig terraform apply machen? Der State wird korrupt (Race Condition). Remote Backends unterstützen Locking. Bei AWS S3 nutzt man oft eine DynamoDB Table dazu. Terraform schreibt beim Start: "LOCKED by User A". User B bekommt: Error acquiring the state lock. Er muss warten. Essenziell für Teams.

2. Sensitive Data

Geheimnis: Der State ist Klartext. Wenn du db_password = var.pass setzt, steht das Passwort lesbar im terraform.tfstate. Auch wenn du es im Code verschlüsselst oder per Env Var übergibst. Der State speichert das Resultat. Best Practice:

1. State Bucket verschlüsseln (S3 SSEC).
2. Zugriff auf den Bucket streng limiteren (nur CI/CD User).
3. Vermeide Output von Secrets (sensitive = true hilft im CLI, aber im State steht es trotzdem).

3. State Manipulation (mv, rm)

Du hast eine Ressource umbenannt (aws_instance.old -> aws_instance.new). Terraform will den alten löschen und neu bauen (Destroy/Create). Das willst du nicht (Datenverlust!). Nutze terraform state mv aws_instance.old aws_instance.new. Das editiert den State File chirurgisch, ohne die echte Cloud anzufassen. Terraform "vergisst" den alten Namen und "lernt" den neuen.

Dependency DAG (Directed Acyclic Graph)

Der State speichert nicht nur Werte, sondern vor allem die Abhängigkeits-Kanten. Terraform Core baut aus der Kombination deines Codes und dem State einen Graphen (DAG). Wenn Ressource B die IP von Ressource A braucht (vpc_id = aws_vpc.main.id), zeichnet TF einen Pfeil von A nach B im State. Beim Apply berechnet der Graph Walker den kritischen Pfad. Er weiß: "A und C hängen von nichts ab, die bau ich parallel (Async). B hängt von A ab, B muss warten." Fällt A mit einem Rollback (Error) um, storniert der Graph bedingungslos alle davon abhängenden Graphen-Kinder (wie B) sofort im State.

Workspaces (Environments im selben File)

Dev-Ops hassen es, Code zu duplizieren (Ordnerstruktur für dev/staging/prod). Mit Terraform Workspaces kannst du ein Git-Verzeichnis mit .tf-Dateien haben. Du tippst terraform workspace new staging. Terraform legt intern einen gekapselten, vollständig getrennten State an. Über die Variable terraform.workspace machst du Logic-Switches: count = terraform.workspace == "prod" ? 5 : 1. Das Problem: Wenn der State korrumpiert (Locking crasht) oder Variablen kollidieren, sind Workspaces oft extrem gefährlich, da der Blast-Radius nicht physisch getrennt ist (das berüchtigte "I applied Production in Staging!"). Heute präferiert man reine Ordnerstrukturen oder Terragrunt vor Workspaces.

Disaster-Recovery eines State-Loss

Was passiert, wenn der S3-Bucket deines States gelöscht wird? Ohne State denkt Terraform: "Das VPC und die 1000 EC2s fehlen, ich bau sie nochmal!" (Ergebnis: Cloud Account Limit Reached & IPs kaputt). Die Rettungsaktion (Import Hell): Du musst für zwingend JEDE physische Ressource manuell terraform import auf die K8s/AWS Ziel-IDs via CLI abfeuern, um den JSON-Baum des alten .tfstate Pixel für Pixel blind zu rekonstruieren. Tools wie terraformer helfen dabei. Besser: Setze im S3/Blob zwingend Versioned Buckets – wenn der State überschrieben oder korrumpiert wird (z.B. Migration V0.13 auf V1.x fehlgeschlagen), rollt man den S3 State einfach auf gestern zurück und rettet 100 Stunden Arbeit.