Wo sollten Sie Ihren Infrastruktur-Status speichern? Ein praktischer Leitfaden

Sie haben gerade eine Terraform-Konfiguration geschrieben, die ein paar Server und eine Datenbank bereitstellt. Sie führen terraform apply auf Ihrem Laptop aus, und alles funktioniert. Ihr Kollege, der einen Load Balancer hinzufügen muss, führt dieselbe Konfiguration auf seinem Rechner aus. Plötzlich verschwindet die Datenbank. Nicht weil der Code falsch war, sondern weil die lokale Statusdatei Ihres Kollegen nicht wusste, dass die Datenbank bereits existierte.

Dieses Szenario ist nicht hypothetisch. Es passiert täglich in Teams, die den Infrastruktur-Status als lokale Datei auf dem Rechner jedes Entwicklers speichern. Das Problem ist einfach: Wenn mehrere Personen dieselbe Infrastruktur verwalten, wird der lokale Status jeder Person schnell veraltet. Ressourcen werden überschrieben, dupliziert oder versehentlich zerstört. Die Lösung ist ebenso einfach: Speichern Sie den Status an einem gemeinsamen, sicheren Ort, auf den alle Teammitglieder zugreifen können.

Was ist Status und warum ist er wichtig?

Status ist die Aufzeichnung von allem, was Ihr Infrastruktur-Tool erstellt hat. Er enthält Ressourcen-IDs, IP-Adressen, Konfigurationswerte und manchmal sogar Passwörter oder API-Schlüssel, die als Klartext gespeichert sind. Wenn Sie terraform plan ausführen, liest das Tool den aktuellen Status, um zu verstehen, was bereits existiert und was geändert werden muss. Ohne genauen Status kann das Tool nicht wissen, ob eine Ressource erstellt, aktualisiert oder in Ruhe gelassen werden soll.

Wenn der Status verloren geht oder beschädigt wird, verliert das Tool den Überblick über Ihre Infrastruktur. Sie haben verwaiste Ressourcen, die Geld kosten, aber nicht mehr verwaltet werden. Oder schlimmer noch, Sie erstellen versehentlich Ressourcen neu, die bereits liefen, was zu Ausfallzeiten führt.

Die lokale Dateifalle

Die einfachste Möglichkeit, Status zu speichern, ist als Datei auf Ihrem eigenen Rechner. Für Lern- oder persönliche Projekte funktioniert das gut. Sie sind die einzige Person, die die Infrastruktur bearbeitet, also gibt es keine Konflikte.

Aber sobald eine zweite Person hinzukommt, bricht der lokale Status zusammen. Hier ist, was passiert:

  • Sie erstellen einen Server. Ihre Statusdatei zeichnet ihn auf.
  • Ihr Kollege führt dieselbe Konfiguration aus. Seine Statusdatei ist leer, also versucht das Tool, einen weiteren Server mit demselben Namen zu erstellen.
  • Der Cloud-Anbieter lehnt das Duplikat ab, oder schlimmer noch, das Tool überschreibt den vorhandenen Server, weil es nicht weiß, dass er existiert.

Selbst wenn Sie die Statusdatei über die Versionsverwaltung teilen, bekommen Sie Merge-Konflikte. Zwei Personen können nicht gleichzeitig dieselbe Statusdatei bearbeiten, ohne die Änderungen des jeweils anderen zu überschreiben. Aus diesem Grund müssen Teams, die Infrastruktur gemeinsam verwalten, ein Remote-Backend verwenden.

Um Ihnen bei der Entscheidung zu helfen, welcher Ansatz für Ihre Situation geeignet ist, finden Sie hier ein Entscheidungsflussdiagramm:

flowchart TD A[Wie viele Personen verwalten die Infrastruktur?] --> B[Eine] A --> C[Mehrere] B --> D[Lokale Datei OK] C --> E[Remote-Backend erforderlich] E --> F[Backend-Typ wählen] F --> G[S3 + DynamoDB] F --> H[GCS] F --> I[Azure Storage] F --> J[Terraform Cloud] F --> K[Consul] G --> L[Unterstützt Locking & Versionierung] H --> L I --> L J --> M[Verwaltet, weniger Betriebsaufwand] K --> M L --> N[Zugriffskontrolle einrichten] M --> N N --> O[Bereit für den Team-Einsatz]

Remote-Backend: Die gemeinsame Quelle der Wahrheit

Ein Remote-Backend speichert den Status an einem Ort, auf den alle Teammitglieder zugreifen können. Übliche Optionen sind ein S3-Bucket auf AWS, ein GCS-Bucket auf Google Cloud oder ein Azure Storage-Container. Jeder im Team zeigt mit seinem Infrastruktur-Tool auf dasselbe Backend, sodass der Status immer konsistent ist.

Hier ist eine minimale Terraform-Backend-Konfiguration, die einen S3-Bucket zur Statusspeicherung und eine DynamoDB-Tabelle zum Locking verwendet:

terraform {
  backend "s3" {
    bucket         = "my-company-terraform-state"
    key            = "production/network/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-locks"
    encrypt        = true
  }
}

Bevor Sie diese Konfiguration verwenden, erstellen Sie den S3-Bucket mit aktivierter Versionierung und eine DynamoDB-Tabelle mit einem Primärschlüssel namens LockID (Typ String). Die Einstellung encrypt = true stellt sicher, dass die Statusdatei im Ruhezustand verschlüsselt ist.

Aber ein Remote-Backend ist nicht nur ein gemeinsamer Ordner. Sie müssen vor der Auswahl einige Dinge bedenken.

Zugriffskontrolle ist nicht verhandelbar

Statusdateien enthalten sensible Informationen. Ressourcen-IDs, IP-Adressen und manchmal Anmeldeinformationen werden im Klartext gespeichert. Wenn jemand außerhalb Ihres Teams Lesezugriff auf den Status erhält, kann er die Details Ihrer gesamten Infrastruktur einsehen. Wenn er Schreibzugriff erhält, kann er Ressourcen beschädigen oder löschen.

Sperren Sie den Bucket oder Container, in dem der Status gespeichert ist, ab. Verwenden Sie IAM-Richtlinien oder rollenbasierte Zugriffssteuerung, um sicherzustellen, dass nur autorisierte Personen und Systeme den Status lesen oder schreiben können. Behandeln Sie den Status-Bucket wie eine Produktionsdatenbank.

Geschwindigkeits- und Kostenabwägungen

Lokaler Status ist schnell, weil die Datei auf Ihrem Rechner liegt. Remote-Backends erfordern das Herunterladen des Status vor einem Plan oder Apply und das anschließende Hochladen. Für kleine Teams mit einigen Dutzend Ressourcen dauert das ein bis zwei Sekunden. Bei großer Infrastruktur mit Tausenden von Ressourcen können Download und Upload Minuten dauern.

Einige Backends berechnen pro Operation oder pro Gigabyte Speicher. S3 berechnet zum Beispiel PUT- und GET-Anfragen. Wenn Ihr Team dutzende Male am Tag terraform plan ausführt, summieren sich diese Kosten. Wählen Sie ein Backend, das zum Nutzungsmuster Ihres Teams passt.

Versionierung rettet Sie vor Fehlern

Einige Remote-Backends unterstützen Versionierung. S3 kann einen Verlauf jeder Statusdateiänderung speichern. Wenn jemand eine Änderung anwendet, die etwas kaputt macht, können Sie zu einer früheren Statusversion zurückkehren und die Wiederherstellung durchführen.

Versionierung ist standardmäßig nicht aktiviert. Sie müssen sie explizit einschalten. Gehen Sie nicht davon aus, dass Ihr Backend automatisch einen Verlauf speichert. Überprüfen Sie die Dokumentation und aktivieren Sie die Versionierung, bevor Sie sie benötigen.

Verwaltete Backends reduzieren den Betriebsaufwand

Wenn Sie keinen Bucket, keine Zugriffsrichtlinien und keine Versionierung selbst verwalten möchten, ziehen Sie ein verwaltetes Backend wie Terraform Cloud oder HashiCorp Consul in Betracht. Diese Dienste sind speziell für die Statusverwaltung konzipiert. Sie enthalten Versionierung, Verlauf, Locking und Integration in CI/CD-Pipelines.

Der Nachteil sind Kosten und Vendor-Lock-in. Verwaltete Backends berechnen pro Benutzer oder pro Workspace. Sie sind auch von der Verfügbarkeit und API des Anbieters abhängig. Für Teams, die sich auf die Infrastruktur und nicht auf die Statusverwaltung konzentrieren möchten, ist dieser Kompromiss oft wert.

Locking verhindert gleichzeitige Änderungen

Selbst mit einem Remote-Backend können zwei Personen gleichzeitig terraform apply ausführen. Ohne Locking lesen beide Vorgänge denselben Status, nehmen Änderungen vor und schreiben zurück. Der zweite Schreibvorgang überschreibt den ersten, und die Änderungen der ersten Person gehen verloren.

Die meisten Remote-Backends unterstützen Locking. S3 mit DynamoDB verwendet beispielsweise eine DynamoDB-Tabelle, um eine Sperre zu halten. Wenn jemand einen Vorgang startet, erwirbt das Tool die Sperre. Andere Vorgänge müssen warten, bis die Sperre freigegeben wird. Dies verhindert Statusbeschädigungen durch gleichzeitige Schreibvorgänge.

Locking ist für Teams nicht optional. Wenn Ihr Backend es nicht unterstützt, suchen Sie eines, das es tut.

Eine praktische Checkliste für die Statusspeicherung

Bevor Sie sich entscheiden, wo Sie den Status speichern, gehen Sie diese Checkliste durch:

  • Ist das Backend für alle zugänglich, die es benötigen?
  • Ist der Zugriff auf autorisierte Personen und Systeme beschränkt?
  • Unterstützt das Backend Versionierung?
  • Unterstützt das Backend Locking?
  • Sind die Kosten für die Nutzung Ihres Teams akzeptabel?
  • Ist die Latenz für Ihren Workflow akzeptabel?

Wenn Sie alle sechs Fragen mit Ja beantworten, haben Sie ein solides Status-Backend.

Die konkrete Erkenntnis

Speichern Sie den Infrastruktur-Status nicht auf Ihrem Laptop. Verwenden Sie ein Remote-Backend, das Zugriffskontrolle, Versionierung und Locking unterstützt. Die wenigen Minuten, die Sie für die Einrichtung eines ordnungsgemäßen Status-Backends benötigen, ersparen Ihnen stundenlanges Debugging, wenn jemand versehentlich eine Ressource löscht oder die Änderungen eines Kollegen überschreibt. Ihre Infrastruktur ist nur so zuverlässig wie der Status, der sie verfolgt. Stellen Sie sicher, dass dieser Status an einem sicheren Ort gespeichert ist.