Jeder Umgebung einen eigenen State geben

Einführung

Ein Arbeitsverzeichnis für preview wählt den State der falschen Umgebung aus, obwohl beide Umgebungen und ihre gültigen State-Objekte bereits existieren. Stellen Sie die korrekte Beziehung zwischen Root-Modul und Schlüssel her und führen Sie eine Änderung ausschließlich an preview durch, ohne dev zu beeinträchtigen.

Sie benötigen Kenntnisse über lokale Module, Remote-State in S3 und native Sperren aus den vorherigen Einheiten. Diese unabhängige frische Umgebung enthält beide Berichtsspeicher und beide States; eine vorherige VM oder ein persönliches AWS-Konto ist nicht erforderlich.

Bezug zu Zertifizierungen

Lab-Überblick

Jede Umgebung vor Änderungen identifizieren

In diesem Schritt unterscheiden Sie zwei Umgebungen von zwei Kopien derselben Umgebung. Jedes der folgenden Root-Module hat eigene Variablen und einen vorhandenen Berichts-Bucket. Beide gültigen Remote-States existieren bereits im versionierten Backend environment-team-state.

cd /home/labex/project/environment-states
cat dev/terraform.tfvars
cat preview/terraform.tfvars

Die Eingaben benennen isolated-dev-reports und isolated-preview-reports. Ein Stammverzeichnis oder eine Variablendatei isoliert den State nicht automatisch: Backend-Bucket und Schlüssel wählen die Zuordnung aus, die Terraform verwendet.

Untersuchen Sie die vom preview-Root-Modul ausgewählte Ressource:

terraform -chdir=preview state show aws_s3_bucket.reports

Es meldet derzeit die Bucket-ID von dev, obwohl die preview-Eingaben einen anderen Bucket beschreiben. Untersuchen Sie seine aktuelle Backend-Auswahl:

cat preview/environment.s3.tfbackend

Das zwischengespeicherte Backend und die Datei wählen environments/dev.tfstate aus. Die vorgesehenen Schlüssel existieren bereits separat:

aws s3api \
  list-objects-v2 \
  --bucket environment-team-state \
  --prefix environments/

Bestätigen Sie, dass sowohl environments/dev.tfstate als auch environments/preview.tfstate existieren. AWS View zeigt ebenfalls beide Berichtsspeicher; klappen Sie ihre Objekte report.txt auf, um die unterschiedlichen ursprünglichen Daten zu sehen.

Untersuchen Sie den unsicheren preview-Plan, ohne ihn auszuführen:

terraform -chdir=preview plan

Er versucht, die preview-Eingaben mit der dev-Zuordnung in Einklang zu bringen, und kann vorschlagen, den falschen Bucket zu ersetzen. Führen Sie ihn nicht aus. Ein anderer Variablenwert ist keine Anweisung, die Verwaltung des States einer anderen Umgebung zu übernehmen.

Den vorhandenen preview-State auswählen, ohne State zu kopieren

In diesem Schritt verbinden Sie das preview-Root-Modul neu mit seinem bereits gültigen State. Eine Migration kopiert eine aktuelle Zuordnung in ein anderes Backend. Eine Neukonfiguration verwirft die zwischengespeicherte Backend-Auswahl und initialisiert das angeforderte vorhandene Backend, ohne die alte Zuordnung zu kopieren.

Lassen Sie die dev-Datei unverändert. Korrigieren Sie die Bucket-/Schlüsselauswahl von preview:

cat > preview/environment.s3.tfbackend <<'HCL'
bucket       = "environment-team-state"
key          = "environments/preview.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

Initialisieren Sie diesen vorhandenen Schlüssel mit -reconfigure. Die bereitgestellte Verbindungsdatei bleibt von Ihrer Umgebungsauswahl getrennt:

terraform -chdir=preview init \
  -reconfigure \
  -backend-config=backend-connection.hcl \
  -backend-config=environment.s3.tfbackend

Verwenden Sie hier weder -migrate-state noch -force-copy. Das Kopieren des ausgewählten dev-States in den gültigen preview-Schlüssel würde die Verwaltungsdaten von preview überschreiben, statt sie auszuwählen.

terraform -chdir=preview state show aws_s3_bucket.reports
terraform -chdir=preview plan

Erwarten Sie die ID isolated-preview-reports und No changes. Prüfen Sie dev unabhängig davon:

terraform -chdir=dev state show aws_s3_bucket.reports
terraform -chdir=dev plan

Dev wählt weiterhin isolated-dev-reports aus, ebenfalls mit No changes. Beide gültigen Schlüssel und beide ursprünglichen Berichte müssen unversehrt bleiben; dies ist eine Umgebungsauswahl und keine Wiederherstellung beschädigten States.

Nachweisen, dass eine preview-Änderung auf preview begrenzt bleibt

In diesem Schritt ändern Sie ausschließlich die Revision von preview, nachdem Sie die korrekte Zuordnung hergestellt haben. terraform.tfvars liefert Werte für die deklarierten Variablen dieses Root-Moduls; Quellkonfiguration und Ressourcenadresse können in verschiedenen Umgebungen gleich bleiben.

cat > preview/terraform.tfvars <<'HCL'
bucket_name = "isolated-preview-reports"
environment = "preview"
revision = "two"
HCL

Prüfen Sie den preview-Plan:

terraform -chdir=preview plan -out=preview.tfplan

Erwarten Sie 0 to add, 1 to change, 0 to destroy, wobei ausschließlich das Revision-Tag von preview betroffen ist. Führen Sie den gespeicherten Plan aus demselben Stammverzeichnis aus:

terraform -chdir=preview apply preview.tfplan

Untersuchen Sie die aktuellen Tags jeder Umgebung:

aws s3api \
  get-bucket-tagging \
  --bucket isolated-preview-reports

Preview sollte Environment=preview und Revision=two haben.

aws s3api \
  get-bucket-tagging \
  --bucket isolated-dev-reports

Dev sollte weiterhin Environment=dev und Revision=one haben. Lesen Sie beide ursprünglichen Berichte:

aws s3 \
  cp s3://isolated-preview-reports/report.txt -
aws s3 \
  cp s3://isolated-dev-reports/report.txt -

Erwarten Sie preview daily report und dev daily report. Die Hintergrundprüfung vergleicht zusätzlich die ursprünglichen State-Bytes von dev, beide Objektversionen und die Ressourcenzuordnungen unter beiden Backend-Schlüsseln.

terraform -chdir=preview plan
terraform -chdir=dev plan

Beide Root-Module sollten No changes melden. Erhalten Sie beide Berichtsspeicher und ihr Backend für ihre Eigentümer. Verzeichnisnamen, for_each-Schlüssel und Terraform-Variablen ersetzen keine explizite State-Isolierung; eine weitere Arbeitskopie von dev sollte bewusst denselben dev-Schlüssel auswählen, während preview seinen eigenen Schlüssel auswählen muss.

Zusammenfassung

Sie haben Arbeitskopien von Umgebungen unterschieden, einen vorhandenen State durch Backend-Neukonfiguration ausgewählt und nachgewiesen, dass eine auf preview begrenzte Aktualisierung die Ressourcen, Daten und den State von dev unverändert ließ.