Remote Backend, Locking
State gehört in ein Remote Backend (S3, azurerm, gcs, …): gemeinsamer Stand + Locking gegen parallele Applies.
S3: natives Locking via use_lockfile = true
(seit 1.10, GA in 1.11); die DynamoDB-Argumente sind seit 1.11
deprecated.
terraform {
backend "s3" {
bucket = "tf-state-prod"
key = "network/terraform.tfstate"
region = "eu-central-1"
use_lockfile = true # natives S3-Locking
encrypt = true
}
}
State ist sensibel
Der State enthält Resource-Attribute im Klartext, auch Passwörter und Keys. Zugriff wie auf ein Secret beschränken, Verschlüsselung at rest aktivieren.
Werte aus dem State heraushalten: ephemeral Values/Resources (1.10+) und write-only Attribute (1.11+) werden nicht persistiert.
State-Kommandos, Drift
state list / state show: Inventar
inspizieren. state mv / state rm:
imperative Chirurgie, für geplantes Refactoring
besser moved/removed-Blöcke.
Drift: plan -refresh-only zeigt
Abweichungen der Realität vom State,
apply -refresh-only übernimmt sie in den State
(ohne Infrastruktur-Änderung).
plan -minimal-refresh (1.17+) refresht nur
Ressourcen mit geplanter Änderung; übrige Drift bleibt
unsichtbar. Nicht bei Provider-Upgrades nutzen.
terraform state list terraform state show aws_s3_bucket.logs terraform state mv aws_iam_role.a aws_iam_role.b terraform state rm aws_iam_role.orphan terraform plan -refresh-only # Drift-Report