Wenn zwei Personen gleichzeitig den gleichen Infrastrukturstatus ändern

Stellen Sie sich Folgendes vor: Entwickler A und Entwickler B müssen beide einige Infrastrukturkomponenten aktualisieren. Sie holen den aktuellen Status aus demselben S3-Bucket, jeder nimmt seine eigenen Änderungen vor, und dann laden beide ihren neuen Status zurück in S3 hoch. Das Ergebnis? Die Änderungen einer Person überschreiben stillschweigend die der anderen. Die in der Cloud ausgeführte Infrastruktur stimmt nicht mehr mit dem überein, was die Statusdatei angibt. Niemand weiß, welche Ressourcen tatsächlich verwaltet werden, und das Team verliert die Kontrolle.

Hierbei geht es nicht darum, dass zwei Personen dieselbe Ressource direkt bearbeiten. Es geht darum, dass zwei Personen die Aufzeichnung dieser Ressourcen bearbeiten. Und die Lösung ist ein Mechanismus namens State Locking.

Was State Locking tatsächlich bewirkt

State Locking ist vom Konzept her unkompliziert. Bevor jemand mit der Änderung des Status beginnt, versucht das System, ihn zu sperren. Wenn die Sperre erfolgreich ist, kann diese Person den Status lesen, Änderungen vornehmen und die neue Version speichern. Währenddessen wird jeder andere, der auf denselben Status zugreifen möchte, blockiert. Sie warten, bis die Sperre aufgehoben ist. Sobald die Änderungen gespeichert sind, wird die Sperre automatisch aufgehoben.

Das folgende Sequenzdiagramm veranschaulicht, wie zwei Entwickler mit dem Status- und dem Sperr-Backend interagieren:

Ohne diesen Mechanismus beschädigen gleichzeitige Änderungen Ihren Status. Und ein beschädigter Status bedeutet, dass Sie keine zuverlässige Quelle der Wahrheit für Ihre Infrastruktur mehr haben.

Wie verschiedene Backends Sperren handhaben

Nicht alle Status-Backends handhaben die Sperrung auf die gleiche Weise. Wenn Sie den Status in S3 speichern, benötigen Sie ein zusätzliches Backend wie DynamoDB, um die Sperre zu verwalten. DynamoDB zeichnet auf, wer die Sperre hält, wann sie begonnen hat und welcher Status gesperrt ist. Jedes Mal, wenn jemand versucht, den Status zu ändern, überprüft das System zuerst DynamoDB. Wenn eine Sperre aktiv ist, wird der Vorgang gestoppt und ein Fehler zurückgegeben.

Hier ist eine minimale Terraform-Backend-Konfiguration, die State Locking mit S3 und DynamoDB ermöglicht:

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

Das Attribut dynamodb_table weist Terraform an, eine DynamoDB-Tabelle namens terraform-locks für die Sperrung zu verwenden. Diese Tabelle muss vor der Ausführung von terraform init vorhanden sein. Sie benötigt einen Primärschlüssel namens LockID (Typ String). Terraform erstellt und gibt während der Statusoperationen automatisch Sperreinträge in dieser Tabelle frei.

Einige Backends haben eine integrierte Sperrung. Consul und etcd sind beispielsweise für verteilte Systeme konzipiert, sodass die Sperrung Teil ihres normalen Betriebs ist. Sie müssen keine zusätzlichen Komponenten wie DynamoDB einrichten. Dieser Komfort hat jedoch einen Nachteil: Sie müssen Consul oder etcd jetzt selbst betreiben und warten.

Wenn Sperren fehlschlagen

Sperren können auf eine Weise fehlschlagen, die Ihren Status blockiert. Hier ist ein häufiges Szenario: Jemand beginnt eine Änderung, dann bricht seine Internetverbindung während des Vorgangs ab. Die Sperre wurde erlangt, aber nie freigegeben, weil der Prozess abgestürzt ist. Jetzt ist der Status gesperrt und niemand kann ihn ändern.

In dieser Situation müssen Sie eine erzwungene Freigabe (Force Unlock) durchführen. Dies ist nichts, was man leichtfertig tut. Wenn Sie eine Sperre zwangsweise freigeben, während der ursprüngliche Prozess noch irgendwo läuft, riskieren Sie, den Status zu beschädigen. Das Team muss überprüfen, ob der hängende Prozess wirklich tot ist, bevor es eine erzwungene Freigabe durchführt.

Tools wie Terraform bieten Befehle für die manuelle Freigabe. Aber Force Unlock sollte niemals ein Routinevorgang sein. Wenn Ihr Team häufig mit blockierten Sperren zu kämpfen hat, suchen Sie nach den Ursachen: Netzwerkstabilität, Timeout-Konfigurationen oder wie Pipelines ausgeführt werden.

Warum dies über die reine Sperrung hinaus wichtig ist

State Locking ist eine Brücke zu einer strukturierteren Umgebungsverwaltung. Sobald Ihr Status vor gleichzeitigen Änderungen sicher ist, können Sie darüber nachdenken, wie Sie eine Konfiguration über mehrere Umgebungen hinweg verwenden können, ohne Code zu duplizieren. Hier kommen Workspaces ins Spiel.

Aber bevor Sie zu Workspaces übergehen, sollten Sie die Sperrung richtig einrichten. Ein Team, das State Locking ignoriert, wird irgendwann mit einer Situation konfrontiert, in der Infrastrukturänderungen stillschweigend verschwinden, Ressourcen verwaist werden und niemand mehr der Statusdatei vertraut.

Praktische Checkliste für State Locking

• Wählen Sie ein Backend mit Sperrungsunterstützung. S3 benötigt DynamoDB. Consul und etcd haben es integriert. Wissen Sie, was Ihr Backend erfordert.
• Testen Sie Sperrungsfehlerszenarien. Simulieren Sie einen Netzwerkausfall während einer Statusänderung. Bleibt die Sperre hängen? Kann sich Ihr Team ohne Panik erholen?
• Dokumentieren Sie die Force-Unlock-Prozedur. Schreiben Sie genau auf, wie Sie überprüfen, ob ein hängender Prozess tot ist, und wie Sie die Sperre freigeben. Überlassen Sie dies nicht dem informellen Wissen.
• Überwachen Sie Sperrkonflikte. Wenn mehrere Personen häufig auf gesperrte Zustände stoßen, benötigt Ihr Team möglicherweise eine bessere Koordination oder kleinere, häufigere Änderungen.
• Legen Sie angemessene Timeouts fest. Langlaufende Operationen sollten Timeouts haben, die Sperren automatisch freigeben, wenn der Prozess hängt.

Die konkrete Erkenntnis

State Locking ist nicht optional. Ohne sie werden gleichzeitige Änderungen Ihren Infrastrukturstatus stillschweigend beschädigen, und Sie werden es erst merken, wenn etwas in der Produktion kaputt geht. Richten Sie die Sperrung ein, bevor Ihr Team mehr als eine Person umfasst, und behandeln Sie Force Unlock wie einen Feuerlöscher: Wissen Sie, wo er ist, wissen Sie, wie man ihn benutzt, aber planen Sie nicht, ihn jeden Tag zu verwenden.