🏗️ Terraform Lektion 3/15 ~7 Min. Einsteiger

Terraform Workflow

init, plan, apply, destroy — der Standard-Workflow.

Lernziele

Nach dieser Lektion kannst du den Terraform-Workflow aus init, plan, apply und destroy erklären und sicher anwenden. Du verstehst, warum plan vor apply Pflicht ist, was ein gespeicherter Plan bringt und wie Terraform bei einem Apply intern vorgeht. Außerdem weißt du, welche Flags und Umgebungsvariablen im Alltag und in CI relevant sind.

Das Problem: Änderungen an der Cloud ohne Sicherheitsnetz

Du hast in Lektion 2 HCL geschrieben — jetzt soll es in der Cloud landen. Der naheliegende Weg: terraform apply direkt ausführen und hoffen. Das endet regelmäßig schlecht. Terraform zeigt dir vor dem Apply nicht, was genau passiert. Ein Tippfehler in einer Variable kann einen Produktions-Bucket löschen, eine Security Group öffnen oder hunderte Ressourcen neu anlegen — und du merkst es erst, wenn die Rechnung kommt oder der Incident-Channel explodiert.

Der Terraform-Workflow existiert, um genau das zu verhindern: erst verstehen, dann ausführen. Jeder Schritt hat eine klare Aufgabe, und die Reihenfolge ist nicht optional.

Die vier Befehle — und was wirklich passiert

terraform init bereitet das Arbeitsverzeichnis vor. Terraform lädt die in required_providers deklarierten Provider herunter, richtet das Backend ein (lokal oder remote — Lektion 6) und legt das .terraform/-Verzeichnis an. Ohne init kennst du weder Provider noch State-Backend. Nach jeder Änderung an Provider-Versionen oder Backend-Konfiguration brauchst du erneut init — oft mit -upgrade, wenn du Provider aktualisieren willst.

terraform plan ist der wichtigste Schritt. Terraform liest deine Konfiguration, vergleicht sie mit dem State und fragt die Cloud-APIs ab, um den Ist-Zustand zu ermitteln. Das Ergebnis ist ein Diff: + create, ~ update in-place, -/+ destroy and recreate, - destroy. Nichts wird geändert — plan ist read-only gegenüber deiner Infrastruktur. In CI läuft fast immer nur plan; der Apply bleibt einem kontrollierten Schritt vorbehalten.

terraform apply führt den Plan aus. Interaktiv fragt Terraform nach Bestätigung (yes). In Pipelines übergibst du einen vorher gespeicherten Plan mit terraform apply plan.tfplan — dann kann sich zwischen Plan und Apply nichts mehr ändern. Das ist der Goldstandard für produktive Deployments.

terraform destroy kehrt alles um: Ressourcen, die Terraform verwaltet, werden gelöscht — in umgekehrter Abhängigkeitsreihenfolge. Gefährlich in der falschen Umgebung. Schütze Produktion mit Remote State, strikten IAM-Rechten und -var-Dateien, die nur in der richtigen Pipeline liegen.

Plan speichern: der Brückenschlag zwischen Review und Apply

In einem Team-Setup will niemand, dass der Apply-Job einen frischen Plan berechnet — der könnte anders ausfallen als der, den du im Pull Request reviewed hast. Deshalb:

terraform init
terraform plan -out=plan.tfplan -var-file=env/prod.tfvars
# Plan als CI-Artefakt hochladen, im PR reviewen
terraform apply plan.tfplan   # exakt der reviewed Plan

Der gespeicherte Plan ist binär und nicht menschenlesbar — deshalb lädst du zusätzlich terraform show -no-color plan.tfplan als Text in den PR-Kommentar. Wer nur apply ohne -out nutzt, hat keinen Beweis, dass Review und Ausführung identisch waren.

Praxis: den Workflow mit dem random-Provider durchspielen

Ohne Cloud-Account:

mkdir tf-workflow && cd tf-workflow
cat > main.tf <<'EOF'
terraform {
  required_providers {
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6"
    }
  }
}

resource "random_id" "suffix" {
  byte_length = 4
}

resource "random_pet" "server" {
  prefix    = "demo"
  separator = "-"
  keepers = {
    suffix = random_id.suffix.hex
  }
}

output "name" {
  value = random_pet.server.id
}
EOF

terraform init
terraform plan                    # nur anzeigen
terraform plan -out=plan.tfplan
terraform apply plan.tfplan
terraform plan                    # "No changes" — Idempotenz
terraform destroy

Achte auf zwei Momente: Beim ersten plan siehst du + create für beide Ressourcen. Beim zweiten plan nach dem Apply steht No changes — das ist der Beweis, dass Terraform den Zielzustand erreicht hat. Ändere danach manuell etwas im State (nicht empfohlen, aber lehrreich: terraform state rm random_pet.server und erneut plan) — dann siehst du, wie der Diff wieder auftaucht.

Nützliche Flags und Variablen

Flag / Variable	Wann
`-var-file=prod.tfvars`	Umgebungsspezifische Werte
`-target=aws_s3_bucket.x`	Nur einen Teilgraphen planen/applyen — Notfall, kein Standard
`-refresh-only`	State mit Realität abgleichen, ohne Änderungen
`-replace=aws_instance.web`	Erzwingt Neuerstellung einer Resource
`TF_LOG=DEBUG`	Provider-API-Calls debuggen
`TF_IN_AUTOMATION=true`	Unterdrückt interaktive Hinweise in CI

-target und -replace sind Werkzeuge für Ausnahmesituationen. Wer sie dauerhaft nutzt, um kaputte Abhängigkeiten zu umgehen, baut technische Schuld auf.

Typische Stolperfallen

Apply ohne Plan reviewen: In produktiven Umgebungen ist terraform apply ohne vorherigen, gespeicherten Plan ein Anti-Pattern. Mindestens: plan im PR, Apply nur aus der Pipeline mit dem Artefakt.

init vergessen nach Provider-Upgrade: Symptom: „Provider not found” oder Versionskonflikt. Fix: terraform init -upgrade.

Auto-Approve in der falschen Umgebung: terraform apply -auto-approve in CI für Produktion ohne Branch-Schutz ist ein klassischer Unfall. Trenne Plan- und Apply-Jobs, und gate Apply hinter manueller Freigabe oder protected branches.

Destroy in der falschen Workspace/Umgebung: Ein terraform destroy gegen den Prod-State löscht alles. Gegenmaßnahme: separate State-Backends pro Umgebung (Lektion 8), keine Prod-Credentials auf Entwickler-Laptops.

Interview-Vorbereitung

Die Frage „Erkläre den Terraform-Workflow” beantwortest du als Kette: init (Provider + Backend) → plan (Diff berechnen, nichts ändern) → apply (Diff ausführen) → optional destroy. Betone: Plan ist der Review-Schritt; gespeicherter Plan verbindet CI und Apply.

Follow-ups:

„Was passiert bei terraform plan, technisch?” — Config + State + Refresh der Cloud-APIs → Execution Plan.
„Warum -out?” — Plan-Artefakt fixiert, was applyen wird; verhindert Drift zwischen Review und Ausführung.
„Unterschied plan vs. apply?” — Plan ist read-only; Apply mutiert Infrastruktur.
„Was ist -refresh-only?” — State aktualisieren ohne Ressourcen zu ändern; nützlich nach manuellen Eingriffen in der Console.

Zusammenfassung

Der Terraform-Workflow folgt einer klaren Logik: init bereitet Provider und Backend vor, plan zeigt den Diff ohne etwas zu ändern, apply setzt den Zielzustand um, destroy räumt auf. In Teams speicherst du Pläne mit -out und applyest genau dieses Artefakt — so bleibt Review und Ausführung verknüpft. Nützliche Flags wie -var-file, -target und TF_IN_AUTOMATION kennst du für Alltag und CI.

In der nächsten Lektion schauen wir uns an, wie Terraform über Provider mit AWS, Azure, GCP und Kubernetes spricht.