Zwei Terraform-Arbeitsverzeichnisse koordinieren

Einführung

Zwei für die Wartung verantwortliche Personen haben Arbeitskopien derselben Umgebung. Beobachten Sie einen tatsächlichen Schreibprozess auf dem gemeinsamen State, einen konkurrierenden Plan, der an dessen nativer Sperre scheitert, und die erfolgreiche Arbeit aus dem anderen Verzeichnis nach der normalen Freigabe.

Sie benötigen Kenntnisse über Remote-State in S3 und das gewöhnliche Planen und Anwenden von Terraform-Konfigurationen. Diese frische Umgebung stellt beide initialisierten Arbeitskopien, eine kontrollierte Änderung mit Zeitverzögerung, Berichtsspeicher und eine Referenz des Finanzteams bereit; eine frühere VM oder ein persönliches AWS-Konto ist nicht erforderlich.

Bezug zu Zertifizierungen

Lab-Überblick

Zwei Kopien einer Umgebung erkennen

In diesem Schritt stellen Sie fest, dass zwei Arbeitsverzeichnisse absichtlich dieselbe Umgebung verwalten. Es handelt sich nicht um separate dev- und preview-Bereitstellungen: Beide Backend-Konfigurationen wählen reports/shared.tfstate in coordination-team-state aus.

cd /home/labex/project/shared-state-operators
cat operator-a/shared.s3.tfbackend
cat operator-b/shared.s3.tfbackend

Beide verwenden use_lockfile = true. Terraform erstellt während eines Schreibvorgangs ein natives S3-Sperrobjekt neben diesem State, damit ein weiterer Schreibprozess nicht mit einem widersprüchlichen Stand arbeitet.

terraform -chdir=operator-a state show aws_s3_bucket.reports
terraform -chdir=operator-b state show aws_s3_bucket.reports

Beide kennzeichnen coordinated-daily-reports. Lesen Sie dessen tatsächlichen Bericht und lassen Sie die Referenz des Finanzteams unverändert:

aws s3 \
  cp s3://coordinated-daily-reports/report.txt -

Erwarten Sie Daily sales: 120 orders. Untersuchen Sie die bereitgestellte kontrollierte Änderung:

cat operator-a/pending-change.tf

Nur für diese Übung pausiert eine Ressource vom Typ terraform_data ihre Erstellung über local-exec für 30 Sekunden. Diese Pause macht die Sperre eines tatsächlichen Schreibprozesses beobachtbar. Auch gewöhnliche Ressourcenaktualisierungen halten eine Sperre; eine künstliche Wartezeit ist keine Empfehlung für Produktionsbereitstellungen. Diese kontrollierte State-Änderung ist in beiden Konfigurationen vorhanden, wurde aber noch nicht angewendet.

Tatsächliche Sperrkonkurrenz und normale Freigabe beobachten

In diesem Schritt führen Sie einen tatsächlichen Schreibprozess und einen konkurrierenden Plan aus dem zweiten Verzeichnis aus. Verwenden Sie den gesamten folgenden Block als einen Vorgang, damit Lesepausen das Beobachtungsfenster nicht aufbrauchen.

& startet Operator A im Hintergrund; $! erfasst dessen Prozess-ID. Seine Ausgabe wird in eine Protokolldatei geschrieben, damit der Fehler des zweiten Operators lesbar bleibt. Die begrenzte Schleife wartet auf die tatsächliche S3-Sperre, statt eine feste Startzeit anzunehmen. Die if-Anweisung ermöglicht es, den erwarteten fehlgeschlagenen Plan zu untersuchen, und wait liefert den tatsächlichen Abschlussstatus des Schreibprozesses zurück. Dies sind zwei unabhängige Terraform-Prozesse, obwohl Sie sie aus einem Terminal starten.

terraform -chdir=operator-a apply -auto-approve > /tmp/operator-a.log 2>&1 &
WRITER_PID=$!
echo "$WRITER_PID"
for attempt in $(seq 1 60); do
  if aws s3api head-object \
    --bucket coordination-team-state \
    --key reports/shared.tfstate.tflock > /dev/null 2>&1; then
    break
  fi
  sleep 1
done
aws s3api get-object \
  --bucket coordination-team-state \
  --key reports/shared.tfstate.tflock \
  /tmp/current-lock.json
cat /tmp/current-lock.json
if terraform -chdir=operator-b plan -lock-timeout=0s; then
  echo 'Unexpected: the competing plan acquired the lock.'
  false
else
  PLAN_EXIT=$?
  echo "$PLAN_EXIT"
fi
wait "$WRITER_PID"
cat /tmp/operator-a.log

Der konkurrierende Plan muss mit 1 und Error acquiring the state lock enden. Ein Authentifizierungs- oder Verbindungsfehler belegt keine Sperrkonkurrenz. Die Sperrinformationen gehören zum tatsächlichen Schreibprozess; das Hochladen einer Datei mit dem Namen der Sperre würde keine Koordination von Schreibprozessen nachweisen.

Operator A sollte seine kontrollierte Erstellung erfolgreich abschließen und die Sperre normal freigeben. Deaktivieren Sie die Sperrung nicht, löschen Sie keine Sperre eines aktiven Schreibprozesses und verwenden Sie force-unlock nicht, um den zweiten Operator fortfahren zu lassen. In AWS View bleiben die Berichtsspeicher durchgehend verfügbar; die Sperre koordiniert die Verwaltung und nicht den Lesezugriff auf Berichte.

Nach der Freigabe aus der anderen Arbeitskopie fortfahren

In diesem Schritt lassen Sie Operator B nach Abschluss des Schreibprozesses auf regulärem Weg die Backend-Sperre erwerben. Die zweite Arbeitskopie sollte jetzt den aktualisierten gemeinsamen State lesen, statt unabhängig eine weitere Kopie der Ressourcen zu erstellen.

terraform -chdir=operator-b plan -lock-timeout=5s

Erwarten Sie No changes. Derselbe Befehl, der während des Schreibvorgangs blockiert wurde, kann die Sperre jetzt normal erwerben und freigeben.

Untersuchen Sie den abgeschlossenen State aus beiden Verzeichnissen:

terraform -chdir=operator-a state list
terraform -chdir=operator-b state list

Jede Liste enthält aws_s3_bucket.reports und terraform_data.coordination. Es handelt sich um dieselbe Umgebung mit gemeinsamen Verwaltungsdaten, nicht um zwei Bereitstellungen.

aws s3 \
  cp s3://coordinated-daily-reports/report.txt -

Der ursprüngliche Text bleibt verfügbar. Untersuchen Sie die Versionshistorie des States:

aws s3api \
  list-object-versions \
  --bucket coordination-team-state \
  --prefix reports/shared.tfstate

Der tatsächliche State hat eine Historie, und im aktuellen Objektbestand sollte keine aktive .tflock verbleiben. Historische Sperrversionen oder Löschmarkierungen sind keine aktive Sperre eines Schreibprozesses.

terraform -chdir=operator-a plan

Erwarten Sie auch hier No changes. Die Hintergrundprüfungen unterscheiden tatsächliche Konkurrenz zwischen Terraform-Prozessen von einer manuell bereitgestellten Sperre und überprüfen die ursprünglichen Berichtsversionen, die normale Freigabe und den erfolgreichen späteren Zugriff. Überlassen Sie den gemeinsamen Speicher und das Backend ihren Eigentümern.

Zusammenfassung

Sie haben zwei Arbeitskopien einer Umgebung von separaten Umgebungen unterschieden, tatsächliche Konkurrenz um eine native Sperre beobachtet und nach der normalen Freigabe durch den Schreibprozess sicher weitergearbeitet, ohne eine aktive Sperre zu löschen.