Warum Terraform eine State-Datei benötigt (und warum Sie sie niemals auf Ihrem Laptop speichern sollten)

Sie haben gerade terraform apply ausgeführt und erfolgreich einen Server und eine Datenbank erstellt. Alles funktioniert. Zufrieden klappen Sie Ihren Laptop zu. Morgen müssen Sie einen Load Balancer hinzufügen. Sie öffnen die Konfiguration, fügen die Ressource hinzu und führen terraform plan aus.

Terraform zeigt Ihnen einen Plan, der alles von Grund auf neu erstellen will.

Was ist passiert? Terraform hat keine Erinnerung an das, was es gestern aufgebaut hat. Es weiß nicht, dass der Server existiert. Es weiß nicht, dass die Datenbank läuft. Es hat keine Aufzeichnung der Infrastruktur, die es gerade erstellt hat.

In diesem Moment wird den meisten Teams klar, dass sie eine State-Datei brauchen.

Was eine State-Datei tatsächlich tut

Eine State-Datei ist Terraforms Arbeitsgedächtnis. Sie zeichnet jede Ressource auf, die Terraform erstellt hat, einschließlich eindeutiger IDs, der zuletzt bekannten Konfiguration und der Beziehungen zwischen Ressourcen. Wenn Sie terraform plan ausführen, fragt Terraform nicht bei Ihrem Cloud-Anbieter nach, "was existiert?" Das wäre langsam, inkonsistent und über verschiedene Anbieter hinweg unzuverlässig. Stattdessen liest es die State-Datei und vergleicht sie mit Ihrer aktuellen Konfiguration.

Betrachten Sie es als eine Quittung. Nach jedem Kauf erhalten Sie eine Quittung, die sagt, was Sie gekauft haben, wann und zu welchem Preis. Ohne diese Quittung müssten Sie Ihr ganzes Haus durchsuchen, um herauszufinden, was Sie besitzen. Bei Terraform ist es genauso. Ohne eine State-Datei müsste es Ihr gesamtes Cloud-Konto scannen, um herauszufinden, was es verwaltet. Und selbst dann könnte es nicht sicher sein, welche Ressourcen es erstellt hat und welche jemand anderes manuell erstellt hat.

Hier ist ein visueller Vergleich der beiden Arbeitsabläufe:

flowchart TD subgraph WithStateFile[Mit State-Datei] A1[State-Datei lesen] --> B1[State mit Konfiguration vergleichen] B1 --> C1[Präzisen Plan erstellen] C1 --> D1[Änderungen sicher anwenden] end subgraph WithoutStateFile[Ohne State-Datei] A2[Gesamtes Cloud-Konto scannen] --> B2[Vermuten, welche Ressourcen Terraform gehören] B2 --> C2[Unsicherer Plan: Risiko von Duplikaten] C2 --> D2[Apply könnte alles neu erstellen] end WithStateFile --> |Zuverlässig| Outcome1[Vorhersagbare Infrastruktur] WithoutStateFile --> |Riskant| Outcome2[Duplikate, Konflikte, hohe Rechnungen]

Die State-Datei enthält detaillierte Informationen zu jeder Ressource. Für einen Cloud-Server umfasst das die Server-ID, IP-Adresse, Maschinentyp, Verfügbarkeitszone und Netzwerkkonfiguration. Für eine Datenbank gehören dazu der Endpunkt, Port, Speichergröße und Backup-Einstellungen. Diese Informationen sind die Quelle der Wahrheit für den nächsten Terraform-Vorgang.

Das Laptop-Problem

Viele Entwickler speichern die State-Datei zunächst lokal. Das ist am einfachsten. Terraform erstellt eine Datei namens terraform.tfstate in Ihrem Arbeitsverzeichnis, und Sie machen weiter.

Das funktioniert, bis:

  • Ihr Laptop kaputtgeht oder gestohlen wird.
  • Sie die Datei versehentlich löschen.
  • Sie den Computer wechseln und vergessen, die Datei zu kopieren.
  • Ein Teammitglied Terraform von seinem Rechner aus ausführt und eine andere State-Datei erstellt.

Wenn die State-Datei verschwindet, verliert Terraform sein gesamtes Wissen über Ihre Infrastruktur. Es denkt, es existiert nichts. Wenn Sie terraform apply erneut ausführen, versucht es, alles von Grund auf neu zu erstellen. Sie erhalten doppelte Ressourcen, widersprüchliche Konfigurationen und eine Cloud-Rechnung, die sich plötzlich verdoppelt.

Noch schlimmer: Wenn jemand manuell eine Ressource in der Cloud-Konsole ändert, ohne die State-Datei zu aktualisieren, wird Terraform desynchronisiert. Es denkt, ein Server hat 4 GB RAM, aber der tatsächliche Server hat 8 GB. Der nächste terraform plan erzeugt einen Plan, der nicht der Realität entspricht.

Remote State: Der einzig sinnvolle Ansatz

Die Lösung ist einfach: Speichern Sie die State-Datei an einem gemeinsamen Ort, auf den alle Teammitglieder zugreifen können. Dies wird als Remote State bezeichnet.

Remote State bedeutet, dass die State-Datei in einem Speicherdienst wie Amazon S3, Azure Storage oder Google Cloud Storage lebt. Jedes Teammitglied und jede CI/CD-Pipeline liest von derselben State-Datei und schreibt in sie hinein. Dadurch wird sichergestellt, dass alle von derselben Quelle der Wahrheit ausgehen.

Die Einrichtung von Remote State erfolgt in der Regel einmalig in Ihrem Terraform-Backend-Block:

terraform {
  backend "s3" {
    bucket = "my-team-terraform-state"
    key    = "production/terraform.tfstate"
    region = "us-east-1"
  }
}

Nach der Konfiguration holt Terraform die State-Datei vor jedem Plan automatisch aus dem Remote-Speicher und aktualisiert sie nach jedem Apply. Niemand muss Dateien manuell kopieren oder sich um Versionskonflikte sorgen.

State Locking: Kollisionen verhindern

Mit Remote State können mehrere Personen gleichzeitig Terraform ausführen. Das bringt ein neues Problem mit sich: Wenn zwei Personen gleichzeitig terraform apply ausführen, kann die State-Datei beschädigt oder eine inkonsistente Infrastruktur erstellt werden.

State Locking verhindert dies. Wenn ein Prozess terraform apply startet, sperrt er die State-Datei. Andere Prozesse müssen warten, bis die Sperre aufgehoben ist. Die meisten Remote-State-Backends unterstützen Locking. S3 verwendet DynamoDB für das Locking. Azure Storage hat eine integrierte Lease-Unterstützung. Google Cloud Storage verwendet Objekt-Generierungsnummern.

Ohne Locking riskieren Sie Szenarien wie:

  • Zwei Pipelines, die gleichzeitig verschiedene Änderungen bereitstellen.
  • Ein Entwickler, der ein manuelles Apply ausführt, während eine CI/CD-Pipeline mitten in der Bereitstellung ist.
  • Teilaktualisierungen, bei denen nur die Hälfte der Änderungen aufgezeichnet wird.

State Locking ist in Teamumgebungen keine Option. Es ist eine Notwendigkeit.

Sensible Daten in State-Dateien

State-Dateien enthalten alles, was Terraform über Ihre Infrastruktur weiß. Dazu gehören sensible Informationen wie Datenbankpasswörter, API-Schlüssel und Verbindungszeichenfolgen. Terraform speichert diese Werte im Klartext in der State-Datei.

Das bedeutet, dass Ihre State-Datei ein Sicherheitsrisiko darstellt. Jeder mit Zugriff auf die State-Datei kann Ihre Geheimnisse lesen. Remote-State-Backends unterstützen in der Regel die Verschlüsselung im Ruhezustand und während der Übertragung. S3 unterstützt serverseitige Verschlüsselung mit KMS. Azure Storage unterstützt standardmäßig die Verschlüsselung im Ruhezustand. Aktivieren Sie immer die Verschlüsselung für Ihren State-Speicher.

Einige Teams trennen auch State-Dateien nach Umgebung. Entwicklung, Staging und Produktion erhalten jeweils eine eigene State-Datei, die an separaten Orten gespeichert wird. Dies verhindert, dass Änderungen in einer Umgebung eine andere beeinflussen. Es begrenzt auch den Schaden, falls eine State-Datei kompromittiert wird.

Wie State-Dateien in CI/CD funktionieren

In einer CI/CD-Pipeline benötigt die Pipeline Zugriff auf die State-Datei, um Terraform auszuführen. Die Pipeline authentifiziert sich mit Anmeldeinformationen oder IAM-Rollen beim Remote-State-Backend. Sie holt die State-Datei, führt terraform plan aus und, wenn genehmigt, terraform apply und aktualisiert die State-Datei.

Deshalb ist Remote State für die Automatisierung unerlässlich. Eine CI/CD-Pipeline, die in einem ephemeren Container läuft, kann sich nicht auf eine State-Datei auf dem Laptop eines Entwicklers verlassen. Sie benötigt einen konsistenten, zugänglichen Ort, der unabhängig von einem einzelnen Rechner existiert.

Praxis-Checkliste für die State-Datei-Verwaltung

  • State-Dateien in Remote-Speicher ablegen, nicht auf lokalen Rechnern.
  • Verschlüsselung im Ruhezustand und während der Übertragung für den Speicher-Backend aktivieren.
  • State Locking konfigurieren, um gleichzeitige Änderungen zu verhindern.
  • Separate State-Dateien für jede Umgebung verwenden.
  • Zugriff auf State-Dateien mit IAM-Richtlinien oder Zugriffskontrollen einschränken.
  • State-Dateien niemals in die Versionskontrolle einchecken.
  • State-Dateien regelmäßig sichern, besonders vor größeren Änderungen.

Was das für Ihr Team bedeutet

State-Dateien sind kein Implementierungsdetail, das Sie ignorieren können. Sie sind das Rückgrat von Terraforms Fähigkeit, Infrastruktur zuverlässig zu verwalten. Ohne eine ordnungsgemäß verwaltete State-Datei werden Ihre Terraform-Workflows unvorhersehbare Ergebnisse, doppelte Ressourcen und schwer zu debuggende Fehler produzieren.

Sobald mehr als eine Person Terraform ausführt oder Sie eine CI/CD-Pipeline hinzufügen, verschieben Sie Ihre State-Datei in den Remote-Speicher. Die Konfiguration dauert zehn Minuten und erspart Ihnen Stunden der Wiederherstellungsarbeit, wenn etwas schiefgeht.

Ihre Infrastruktur ist zu wichtig, um sie einer Datei auf Ihrem Laptop anzuvertrauen.