Trotz sorgfältiger Blast-Radius-Minimierung, segmentierter States und Lifecycle-Guardrails kann es früher oder später passieren: Ein terraform apply löscht versehentlich produktive Ressourcen - oder ein terraform destroy trifft mehr als beabsichtigt.
Was tun, wenn das Kind schon in den Brunnen gefallen ist?
Im letzten Artikel dieser Serie habe ich Ihnen erklärt, wie man den Blast Radius minimiert. In dieser Fortsetzung zeige ich bewährte Techniken zur Wiederherstellung beschädigter Terraform-States und zur Schadensbegrenzung nach einem Incident.
1. Erste Hilfe am offenen Herzen: State Surgery
Wenn Ressourcen noch physisch existieren, aber nicht mehr korrekt im Statefile referenziert werden, hilft nur noch chirurgischer Eingriff per Kommandozeile. Die sogenannte State Surgery erlaubt es, Terraform-States manuell zu bereinigen und wieder mit der Realität abzugleichen. 
⚠️ Wichtig: Dieser Ansatz erfordert tiefes Verständnis der Terraform-Logik und des realen Infrastrukturzustands. Er ist mächtig, aber auch gefährlich, wenn er unüberlegt eingesetzt wird. Erstellen Sie deshalb immer ein vollständiges Backup des aktuellen State-Files, bevor Sie manuelle Änderungen vornehmen!
Das aktuelle State können Sie mit folgendem CLI-Kommando sichern:
$> terraform state pull > state-backup-$(date +%Y%m%d-%H%M%S).json
Danach können Sie gezielt Ressourcen aus dem State entfernen, ohne die zugehörige Cloud-Ressource zu löschen. In diesem Beispiel nennen wir die betroffene Resource aws_instance.problematic_instance:
$> terraform state rm aws_instance.problematic_instance
Legen Sie jetzt in ihrem Terraform-Manifest eine neue Ressource für die wiederhergestellte Ressource an (wir benutzen hier den Namen aws_instance.recovered_instance). Dies kann eine völlig leere Ressource sein, oder ein vollständiges Copy & Paste der alten Ressource, je nachdem was genau kaputt gegangen ist.
Anschließend importieren Sie die betroffene Ressource über ihre eindeutige ID (hier als Beispiel i-1234567890abcdef0) unter dem neuen Namen zurück:
$> terraform import aws_instance.recovered_instance i-1234567890abcdef0
Alternativ kann man eine existierende Ressource in dem neuen State auch an eine neue Position verschieben. Das kann sowohl ein anderer Teil der Infrastruktur sei, aber auch ein anderes Terraform-Modul:
$> terraform state mv aws_instance.misplaced_resource aws_instance.correct_scope
2. Schrittweiser Wiederaufbau: Partial Import Strategien
In komplexen Szenarien – etwa nach einem partiellen Ausfall in einem großen State – reicht ein einfacher Import oft nicht aus. Stattdessen empfiehlt sich eine strukturierte, schrittweise Wiederherstellung mittels Partial Import Configurations (ab Terraform 1.5 verfügbar).
Ablauf
a. Betroffene Ressourcen identifizieren mittels -detailed-exitcode
$> terraform plan -detailed-exitcode
Der Befehl terraform plan -detailed-exitcode ist eine spezielle Variante des Standardbefehls terraform plan. Er liefert detailliertere Exit-Codes, was besonders in Automatisierungs- und CI/CD-Pipelines nützlich ist.
Funktionsweise:
- terraform plan zeigt normalerweise an, welche Änderungen Terraform an Ihrer Infrastruktur vornehmen würde, ohne tatsächlich etwas zu verändern.
- Mit dem Flag -detailed-exitcode ändert sich das Verhalten der Exit-Codes, sodass das Ergebnis des Plans genauer angezeigt wird:
| Exit-Code | Bedeutung |
|---|---|
| 0 | Keine Änderungen; die Infrastruktur entspricht der Konfiguration. |
| 1 | Ein Fehler ist aufgetreten (z.B. Syntaxfehler, Provider-Fehler, etc.). |
| 2 | Änderungen stehen an; der vorgeschlagene Plan würde Infrastruktur ändern. |
Merke: Ein Exitcode 2 zeigt geänderte Ressourcen an. Diese erfordern also besondere Aufmerksamkeit.
Diese Funktion wird nicht immer in einfachen Tutorials erwähnt, ist aber in Teams, die Terraform-Workflows automatisieren, weit verbreitet und sorgt für robuste und vorhersehbare Infrastrukturänderungen.
b. Import-Konfiguration definieren
Erstellen Sie jetzt eine Konfiguration für die betroffenen Ressourcen:
import {
to = aws_vpc.recovered_vpc
id = "vpc-12345678"
}
import {
to = aws_subnet.recovered_subnet[0]
id = "subnet-12345678"
}
c. Automatisierten Import und Config-Generierung mithilfe -generate-config-out durchführen
Der Befehl terraform plan -generate-config-out=<file> ist ein experimentelles Feature, das mit Terraform v1.5 eingeführt wurde. Er ermöglicht es, Terraform-Konfigurationsdateien (im HCL-Format) für Ressourcen zu generieren, die in import-Blöcken definiert sind, aber noch nicht in deiner Konfiguration existieren.
Dieses Feature ist besonders nützlich, wenn Sie bestehende Infrastruktur in Terraform importieren möchten, da es Ihnen hilft, den notwendigen Konfigurationscode auf Basis des tatsächlichen Zustands der Ressourcen zu erstellen.
$> terraform plan -generate-config-out=generated.tf
[...] $> terraform apply
Terraform macht Folgendes:
- Es untersucht die import-Blöcke in der Konfiguration.
- Für jede Ressource, die importiert werden soll und noch keine Konfiguration besitzt, generiert Terraform einen HCL-Resource-Block mit einer möglichst passenden Auswahl an Argumenten und Werten.
- Die generierte Konfiguration wird in die angegebene Datei geschrieben (in diesem Beispiel ist dies generated.tf). Sie müsxsen einen neuen Dateipfad angeben; die Verwendung einer bestehenden Datei führt zu einem Fehler.
- Nach dem Ausführen des Befehls zeigt Terraform den Plan für den Import Ihrer Ressourcen an und gibt an, wo die generierte Konfiguration gespeichert wurde.
terraform plan -generate-config-out=<file> ist ein leistungsstarkes, experimentelles Werkzeug, um Terraform-Konfigurationen aus bestehenden Ressourcen, die in import-Blöcken definiert sind, zu generieren. Das erleichtert es, nicht verwaltete Infrastruktur unter Terraform-Verwaltung zu bringen. Überprüfen und passen Sie den generierten Code immer vor der Nutzung an.
d. Realitätscheck: State Reconciliation mit -refresh-only und -refresh=true
Wenn der Terraform-State von der Realität abweicht, aber keine Ressourcen fehlen, hilft ein Abgleich des State mit der realen Infrastruktur. Dieser sogenannte Refresh kann Drift aufdecken und in manchen Fällen auch automatisch korrigieren.
# State-Refresh ohne Änderungen $> terraform apply -refresh-only # Vergleich zwischen State und tatsächlicher Infrastruktur $> terraform plan -refresh=true
Der Befehl terraform plan -refresh=true erstellt einen Ausführungsplan für deine von Terraform verwaltete Infrastruktur, mit der expliziten Anweisung, den Terraform-Status vor der Planerstellung zu aktualisieren (refresh).
Verhaltensdetails
- Standardmäßig aktualisiert Terraform beim Ausführen von terraform plan automatisch die Statusdatei, um sie mit der tatsächlichen, externen Infrastruktur zu synchronisieren, bevor Änderungen geprüft werden.
- Mit dem Flag -refresh=true weist man Terraform explizit an, diesen Aktualisierungsschritt durchzuführen. Das ist normalerweise redundant, da dies das Standardverhalten ist, stellt aber sicher, dass alle außerhalb von Terraform vorgenommenen Änderungen (z.B. manuelle Änderungen in der Cloud-Konsole) erkannt und im Plan angezeigt werden.
- Während des Refresh fragt Terraform alle verwalteten Ressourcen ab, um die Statusdatei mit deren aktuellem Zustand zu aktualisieren. Anschließend vergleicht Terraform diesen aktualisierten Status mit Ihren Konfigurationsdateien, um anzuzeigen, welche Aktionen (Hinzufügen, Ändern, Löschen) nötig wären, um die tatsächliche Infrastruktur an die gewünschte Konfiguration anzupassen.
Vergleich mit -refresh=false
| Option | Verhalten |
|---|---|
| -refresh=true | Status wird vor der Planung mit der realen Infrastruktur aktualisiert (Standardverhalten). |
| -refresh=false | Status-Aktualisierung wird übersprungen, was die Planung beschleunigen kann, aber externe Änderungen übersieht. |
e. Drift Detection im Skriptbetrieb mit -detailed-exitcode
Der Befehl terraform plan -detailed-exitcode wird verwendet, um einen Ausführungsplan in Terraform zu erstellen – mit einem besonderen Verhalten bezüglich der Rückgabewerte (Exit Codes). Diese Technik eignet sich ideal für den Einsatz in CI/CD-Pipelines oder als Vorab-Check vor einem produktiven terraform apply.
#!/bin/bash
terraform plan -detailed-exitcode
if [ $? -eq 2 ]; then
echo "Configuration drift detected – manual review required"
fi
Erklärung der Exit Codes
Wenn Sie terraform plan -detailed-exitcode ausführen, wird Terraform:
- Die geplanten Aktionen anzeigen (Hinzufügen, Ändern, Löschen), die notwendig wären, um Ihre Infrastruktur an die Konfiguration anzupassen, aber keine Änderungen vornehmen.
- Einen bestimmten Exit-Code basierend auf dem Ergebnis des Plans zurückgeben:
| Exit Code | Bedeutung |
|---|---|
| 0 | Keine Änderungen; die Infrastruktur entspricht der Konfiguration. |
| 1 | Ein Fehler ist aufgetreten (z. B. Syntaxfehler, Provider-Problem). |
| 2 | Es gibt Änderungen anzuwenden (Ressourcen werden hinzugefügt, geändert oder gelöscht). |
Fazit
Wie Sie in diesem Artikel erkennen konnten, ist ein trotz aller Vorsichtsmaßnahme über die Stränge schlagender terraform destroy nicht das Ende der Welt.
Im Gegenteil, in dem IT-Zeitalter vor Terraform war der Impact in der Regel noch viel schlimmer, da hier dann keine Werkzeuge wie sie Terraform integriert bietet zur Verfügung standen. Stattdessen hieß es früher zumeist "Jetzt sind wir erstmal offline, bauen den Service 1-2 Tage lang komplett neu von Hand auf, und danach schauen wir was eigentlich schief gelaufen ist".
Fakt ist aber auch, dass auch mithilfe von Terraform die Restaurierung kaputter Betriebszustände (States) und zerkjonfigurierter oder vernichteter Resssourcen immer noch technisch anspruchsvoll ist und Expertenwissen erfordert.
Im nächsten Teil dieser Artikelserie werden wir uns daher auch ansehen, welche Werkzeuge Terraform mitbringt, um Gefahren durch zu hohen Blast-Radius frühzeitig zu erkennen und zu vermeiden.
