Die Inszenierung entstand durch einen Klick in das Hetzner-Panel an einem Freitagabend. Sechs Monate später weiß niemand, warum die Firewall den öffentlichen Port 6379 zulässt. Die Produktion erfolgt in Terraform – bis auf den „vorübergehend“ von Hand hinzugefügten S3-Bucket. Ergebnis: zwei Wahrheiten, ein „Terraform-Plan“, der zerstören will, was das Team noch nutzt.
Terraform verspricht Reproduzierbarkeit. Dies gilt nur, wenn der Status, die Module und die Governance denselben Anforderungen entsprechen wie der Anwendungscode.
Anbieter, Ressourcen und was wir modellieren
Europäische Anbieter (Hetzner hcloud, OVH, Scaleway, OpenStack) stellen Server, Volumes, private Netzwerke, DNS und Load Balancer zur Verfügung. Modellieren Sie, was sich häufig ändert und was nachverfolgbar sein muss:
| Ressource | Interesse Terraform | Falle |
|---|---|---|
| Server/Instanz | Größe, Bild, Region kodiert | Lebenszyklus-ignore_changes-Maskendrift |
| Firewall/Sicherheitsgruppe | Versionierte Regeln | Manuelle Regel außerhalb von TF |
| DNS | Ausrichtung bereitgestellt | TTL und Ausbreitung vergessen |
| Objektspeicher | Eimer, Lebenszyklus | IAM-Schlüssel außerhalb des verschlüsselten Zustands |
Wenn es nicht im Staat ist, ist es nicht reproduzierbar – es ist eine Schuld.
Fernbedienung, Schloss und Geheimnisse angeben
Remote-Backend (S3 + Sperre, GitLab HTTP-Backend, Terraform Cloud):
- Sperre während der Anwendung – nicht zwei gleichzeitige Anwendungen.
- Sicherung des Staates – es enthält manchmal sensible Daten.
- Verschlüsselung im Ruhezustand; minimaler Zugang.
Niemals terraform.tfstate im Klartext festschreiben. Verwenden Sie sensible Variablen („TF_VAR_“, Tresor-CI) für Host-API-Tokens.
Module: DRY ohne Blackbox
Wiederverwendbare Module (VPC + Subnetz + Bastion) werden schneller – aber ein undurchsichtiges Catch-All-Modul erschwert die Wiederholung. Explizite Variablen verfügbar machen („instance_type“, „enable_ipv6“, „backup_window“).
Versionsmodule mit Git-Tags (?ref=v1.2.0) – nicht schwebendes main. Als Team „terraform fmt“ und „validieren“ in CI vor der Planung für MR.
Richtlinien planen, anwenden und ändern
Gesunder Arbeitsablauf: MR → „Terraform-Plan“ in CI kommentiert; menschliche Überprüfung von zerstören und ersetzen; Je nach Kritikalität automatisiert oder manuell anwenden.
„prevent_destroy“ auf DB-Produkt. „-target“ ist für dokumentierte Notfälle reserviert – andernfalls inkonsistenter Zustand.
Schrittweiser Import von Legacy-Ressourcen: eine Ressource nach der anderen, grüner Plan vor der nächsten.
Multi-Cloud und europäische Hosts
Vermeiden Sie standardmäßig Multi-Cloud – ein gut kontrollierter Anbieter schlägt drei unausgegorene Konfigurationen. Legen Sie für den EU-Wohnsitz die Region fest und überprüfen Sie die zugehörigen Ressourcen (Snapshot-Region, Replikat).
Querverweis auf DSGVO-Unterverträge: Terraform garantiert keine Zuständigkeit – Sie wählen die Region im Code aus.
Der Gipfel: Infra als Code ohne Governance = getarnte Clickops
Reproduzierbar bedeutet: Jeder Ingenieur kann das Staging von Grund auf neu erstellen – nicht nur, dass die „.tf“-Datei vorhanden ist.
Entscheide dich und gehe ohne blinden Fleck voran
Konfigurieren Sie ein Remote-Backend und sperren Sie den Zugriff. Integrieren Sie „Terraform Plan“ in CI bei jeder Zusammenführungsanforderung. Versionsmodule mit Git-Tags. Planen Sie den Import von Legacy-Ressourcen einzeln. Trennen Sie den Status nach Umgebung – niemals Staging und Produktion in derselben Statusdatei.
Vergleichen Sie Anbieter über das Verzeichnis und den Vergleich. Abschlusstest: Staging aus Git zerstören und neu erstellen – Dauer und Überraschungen dokumentiert.
Häufig gestellte Fragen
Warum den Terraform-Status remote speichern?
Der lokale Status auf einem Laptop verhindert die Teamarbeit und geht bei einem Festplattenabsturz verloren. Ein Remote-Backend sperrt gleichzeitige Anwendungen und protokolliert Änderungen.
Ersetzt Terraform Ansible?
Nein – Terraform stellt die Infrastruktur bereit (Server, Netzwerk, DNS, Buckets); Ansible oder cloud-init konfiguriert das Betriebssystem und die Dienste. Die beiden ergänzen sich.
Wie vermeide ich Drift?
Regelmäßiger CI-Plan, Verbot manueller Änderungen, die nicht im Code aufgeführt sind, und dokumentierter Import für Legacy-Ressourcen.
Ist ein Arbeitsbereich pro Umgebung erforderlich?
Ja – separate staatliche Inszenierung und Produktion. Niemals derselbe Zustand für zwei kritische Umgebungen.
Nützliches Terraform kann in einem von einem Menschen überprüften Plan gelesen werden – nicht in einer Anwendung, die ohne Zeugen von einem Laptop aus gestartet wird.