Lokalen State nach S3 verschieben

Einführung

Eine für die Wartung verantwortliche Person benötigt einen gemeinsamen Speicherort für die Ressourcenzuordnungen eines funktionierenden Stacks. Migrieren Sie einen lokalen State in ein separates, versioniertes S3-Backend und erhalten Sie dabei den vorhandenen Bericht. Beobachten Sie anschließend die State-Historie und den unabhängigen Lebenszyklus des Backends.

Sie sollten Terraform-State, Import, gespeicherte Pläne und S3-Objektversionen verstehen. Alle Ressourcen dieses Labs sind in dieser frischen Umgebung vorbereitet; ein früherer State oder ein persönliches AWS-Konto ist nicht erforderlich.

Bezug zu Zertifizierungen

Lab-Überblick

Lokalen State und Backend voneinander abgrenzen

In diesem Schritt identifizieren Sie den geschäftlich genutzten Bucket und das separate Ziel für den State. Das bereitgestellte Berichts-Root-Modul verwaltet bereits migration-daily-reports; sein lokaler State ist von der Referenz des Finanzteams unabhängig. Der versionierte Bucket maintenance-team-state wurde vom Plattformteam vorbereitet, damit er bereits existiert, bevor dieses Root-Modul ihn verwendet.

cd /home/labex/project/state-migration
terraform state list
terraform state show aws_s3_bucket.reports

Bestätigen Sie, dass die ID des entfernten Buckets migration-daily-reports lautet. Ein Backend speichert Ressourcenzuordnungen; es ist nicht der Provider, der AWS-Ressourcen erstellt und liest. Die Verbindungseinstellungen für Provider und Backend sind in dieser Umgebung separat vorbereitet.

Speichern Sie eine private lokale Sicherung, bevor Sie den Speicherort des States ändern. Die Umleitung (>) schreibt den State als JSON in eine Datei; übertragen Sie State oder Pläne nicht in eine öffentliche Versionsverwaltung:

terraform state pull > local-before-migration.json
chmod 600 local-before-migration.json

Prüfen Sie die Versionierung des Backends und dessen anfangs leeren Objektbestand:

aws s3api \
  get-bucket-versioning \
  --bucket maintenance-team-state

Erwarten Sie Status: Enabled.

aws s3api \
  list-objects-v2 \
  --bucket maintenance-team-state

Es sollte noch kein State-Objekt existieren. Die Wahl eines leeren Ziels ist wichtig: Eine Migration zu einem Schlüssel, der bereits zu einer anderen Umgebung gehört, kann deren Verwaltungsdaten überschreiben. Lassen Sie migration-finance-reference unberührt.

Die vorhandene Zuordnung zum vorgesehenen S3-Schlüssel migrieren

In diesem Schritt konfigurieren Sie ein entferntes Backend und kopieren die vorhandene lokale Ressourcenzuordnung in dessen leeres Ziel. Ein Schlüssel ist der Name des State-Objekts im Backend-Bucket; wählen Sie ihn für eine bestimmte Umgebung.

Schreiben Sie eine teilweise S3-Backend-Deklaration. Die Verbindungseinstellungen werden separat bereitgestellt, und die nächste Datei legt Ihre Auswahl von Bucket und Schlüssel fest:

cat > backend.tf <<'HCL'
terraform {
  backend "s3" {}
}
HCL

Erstellen Sie die umgebungsspezifische Backend-Konfiguration. use_lockfile = true aktiviert die native S3-Sperrdatei von Terraform für zukünftige Schreibzugriffe:

cat > reports.s3.tfbackend <<'HCL'
bucket       = "maintenance-team-state"
key          = "reports/production.tfstate"
region       = "us-east-1"
use_lockfile = true
HCL

-migrate-state fordert Terraform auf, die vorhandene Zuordnung in das neue Backend zu verschieben. Terraform fragt, ob es den vorhandenen State kopieren soll; die printf-Pipeline liefert die Antwort yes. Führen Sie dies erst aus, nachdem Sie bestätigt haben, dass der Zielschlüssel dieses Labs leer war:

printf 'yes\n' | terraform init \
  -backend-config=backend-connection.hcl \
  -backend-config=reports.s3.tfbackend \
  -migrate-state

Erwarten Sie eine erfolgreiche S3-Backend-Konfiguration und eine abgeschlossene Initialisierung. Verwenden Sie die Migration nicht, um zu einer bereits vorhandenen Umgebung zu wechseln: Die Auswahl eines vorhandenen States ist ein anderer Vorgang, der später in diesem Kurs behandelt wird.

Untersuchen Sie die Zuordnung an ihrem neuen Speicherort:

terraform state show aws_s3_bucket.reports

Die Ressourcen-ID muss weiterhin migration-daily-reports sein. Bestätigen Sie, dass S3 jetzt das tatsächliche State-Objekt enthält:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Ein ETag und eine VersionId zeigen das gespeicherte State-Objekt an. Diese Metadaten allein reichen nicht aus: Die Hintergrundprüfung liest zusätzlich dessen Ressourcenzuordnung und vergleicht die Identität und Bytes des vorhandenen Berichts.

terraform plan

Erwarten Sie No changes. Eine State-Migration sollte den geschäftlich genutzten Bucket nicht neu erstellen.

Eine neue Version des Remote-States beobachten

In diesem Schritt führen Sie eine geprüfte Konfigurationsaktualisierung aus und beobachten die daraus entstehende State-Historie. Die Versionierung erhält frühere State-Objekte; dieses Lab beobachtet die Historie, statt beschädigten State wiederherzustellen.

Fügen Sie ein Revision-Tag hinzu und lassen Sie Bucket-Namen, Eigentümer und Löscheinstellung unverändert:

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "reports" {
  bucket        = "migration-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting", Revision = "two" }
}
HCL

Prüfen Sie einen gespeicherten Plan:

terraform plan -out=revision.tfplan

Erwarten Sie 0 to add, 1 to change, 0 to destroy. Führen Sie ausschließlich diese Aktualisierung ohne Neuerstellung aus:

terraform apply revision.tfplan

Untersuchen Sie die Versionen des Backend-Objekts:

aws s3api \
  list-object-versions \
  --bucket maintenance-team-state \
  --prefix reports/production.tfstate

Nach der Migration und Aktualisierung sollten mindestens zwei State-Versionen existieren. Sie beschreiben die Verwaltungshistorie und unterscheiden sich von den Versionen des geschäftlich genutzten Berichts im anderen Bucket.

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

Der Bericht enthält weiterhin Daily sales: 120 orders. AWS View zeigt den geschäftlich genutzten Speicher, die Referenz des Finanzteams und das Backend als separate Buckets. State-Dateien können sensible Werte enthalten; untersuchen Sie nur die für diese Übung benötigten Metadaten.

terraform plan

Erwarten Sie No changes. Überprüfen Sie diesen funktionierenden Zustand, bevor Sie die separate Bereinigungsphase beginnen.

Geschäftsressourcen entfernen und das Backend erhalten

In diesem Schritt legen Sie diesen entbehrlichen Geschäfts-Stack still, nachdem seine Funktionalität und der Datenerhalt erfolgreich geprüft wurden. Das Backend des Plattformteams und die unabhängige Referenz des Finanzteams liegen außerhalb des Löschumfangs dieses Stacks.

force_destroy = false verhindert, dass Terraform den versionierten Berichts-Bucket stillschweigend leert. Identifizieren Sie gezielt die ursprüngliche Berichtsversion, bevor Sie den Bericht dieses Labs löschen. Die Befehlsersetzung speichert ihre ID; zeigen Sie diesen nicht geheimen Bezeichner an:

VERSION_ID=$(aws s3api \
  head-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --query VersionId \
  --output text)
echo "$VERSION_ID"

Löschen Sie genau diese entbehrliche Version und anschließend die Geschäftsressource. Diese Befehle beenden die Verfügbarkeit des Berichts absichtlich erst nach der Prüfung des Datenerhalts im vorherigen Schritt:

aws s3api \
  delete-object \
  --bucket migration-daily-reports \
  --key report.txt \
  --version-id "$VERSION_ID"
terraform destroy -auto-approve

-auto-approve überspringt eine Bestätigungsabfrage; verwenden Sie es hier nur für den einzelnen entbehrlichen Geschäfts-Bucket, den Sie gerade geprüft haben. Erwarten Sie 1 destroyed.

Bestätigen Sie, dass seine Verwaltungsdaten weiterhin im Backend vorhanden sind:

aws s3api \
  head-object \
  --bucket maintenance-team-state \
  --key reports/production.tfstate

Das Backend bleibt erhalten und enthält jetzt einen State ohne verwaltete Geschäftsressourcen. Die Referenz des Finanzteams muss weiterhin verfügbar sein. Das Löschen eines Stacks löscht nicht den von seinem Backend verwendeten Speicher. Lassen Sie dieses Backend für seinen Eigentümer unversehrt; führen Sie kein weiteres gewöhnliches apply aus, das den gewünschten Geschäfts-Bucket neu erstellen würde.

Informationen zur Backend-Konfiguration und zu nativen Sperrdateien finden Sie in der S3-Backend-Dokumentation.

Zusammenfassung

Sie haben die Aufgaben von Provider und Backend voneinander getrennt, eine vorhandene Zuordnung gesichert und nach S3 migriert, State-Versionen beobachtet und einen Geschäfts-Stack entfernt, ohne sein unabhängig verwaltetes Backend zu löschen.