Eine Speicheränderung prüfen und anwenden

Einführung

Ihr Team muss einen vorhandenen Berichtsspeicher als Release 2 kennzeichnen, ohne den Speicher neu zu erstellen oder seinen Bericht zu ändern. Sie prüfen einen gespeicherten Plan, führen ihn aus und erkennen und beheben anschließend eine absichtlich erzeugte Tag-Abweichung.

Diese unabhängige Umgebung stellt den kleinen Ausgangsspeicher und den lokalen State bereit. Nutzen Sie Ihre Kenntnisse zu plan/apply, Variablendateien und S3-Abfragen; Remote-State und automatisierte Genehmigungen sind nicht erforderlich.

Bezug zu Zertifizierungen

Einen gespeicherten Plan prüfen und ausführen

In diesem Schritt aktualisieren Sie das Release-Tag eines vorbereiteten Berichtsspeichers mit einem gespeicherten Plan und erhalten dabei seinen vorhandenen Bucket und Bericht.

Dieses frische Root-Modul verwaltet bereits den kleinen Speicher, dessen Erstellung Sie in früheren Labs gelernt haben. Die Vorbereitung stellt diese Ausgangssituation bereit, damit Sie sich auf die Änderungsprüfung konzentrieren können. Das gewünschte neue Release ist 2; der vorhandene Bericht muss orders,12 bleiben. Lesen Sie zunächst die Konfiguration, die Werte und das aktuelle Tag:

cd /home/labex/project/storage-change
cat main.tf
cat release.tfvars
terraform state list
aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports

Die Eingabedatei wählt derzeit Release 1 aus. Eine Änderung des Ressourcennamens könnte den Speicher ersetzen, während eine Tag-Änderung den vorhandenen Bucket aktualisieren kann. Ändern Sie nur die Release-Eingabe:

cat > release.tfvars <<'EOF'
release = "2"
EOF
terraform plan -var-file=release.tfvars -out=change.tfplan

Erwarten Sie eine Bucket-Aktualisierung ohne Neuerstellung: 0 to add, 1 to change, 0 to destroy. -out schreibt ein natives Planartefakt, das diese Konfiguration und diese Eingabewerte enthält. Beim Anwenden dieser Datei wird der geprüfte Plan verwendet, statt aus späteren Änderungen einen neuen Plan zu erzeugen, wie es bei einer nicht gespeicherten Vorschau der Fall wäre. Pläne können in echten Projekten sensible Werte enthalten; behandeln Sie sie daher als Projektartefakte.

Lesen Sie den gespeicherten Plan, bevor Sie ihn ausführen:

terraform show change.tfplan

Bestätigen Sie, dass sich Release von 1 auf 2 ändert und kein Objekt oder Bucket ersetzt wird. Führen Sie anschließend das Artefakt aus. Bei einem gespeicherten Plan erscheint keine zusätzliche Bestätigungsabfrage für yes:

terraform apply change.tfplan

Fragen Sie das aktuelle Tag ab und lesen Sie den Bericht:

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
aws s3api \
  get-object \
  --bucket terraform-change-reports \
  --key reports/current.csv \
  retained.csv
cat retained.csv

Erwarten Sie Release 2 und orders,12. Ein gespeicherter Plan ist nur dann nützlich, wenn die geänderte Ressource und die erhaltenen Daten mit der geprüften Änderung übereinstimmen.

Eine Tag-Abweichung erkennen und beheben

In diesem Schritt beobachten Sie eine tatsächliche Tag-Änderung außerhalb von Terraform und stellen die deklarierte Konfiguration wieder her, ohne den Bericht zu ändern.

Drift ist eine Abweichung zwischen der bereitgestellten Ressource und ihrer gewünschten Konfiguration. Verwenden Sie die AWS CLI, um das Tag außerhalb von Terraform zu ändern. Diese gezielte Übung verändert ein tatsächliches Ressourcenattribut, das der Provider lesen kann; sie bearbeitet keine lokale Erfolgsmarkierung.

aws s3api \
  put-bucket-tagging \
  --bucket terraform-change-reports \
  --tagging '{"TagSet":[{"Key":"Project","Value":"TerraformReports"},{"Key":"Release","Value":"unexpected"}]}'

Lassen Sie Terraform die aktuelle Ressource mit dem gewünschten Release vergleichen. -detailed-exitcode unterscheidet 0 (keine Änderung), 2 (eine vorgeschlagene Änderung) und 1 (ein Fehler). Der folgende Plan gibt absichtlich 2 zurück; dies bedeutet, dass er den Tag-Unterschied gefunden hat, und nicht, dass die Bereitstellung fehlgeschlagen ist.

terraform plan -var-file=release.tfvars -detailed-exitcode

Der Plan schlägt vor, unexpected wieder auf 2 zu ändern. Prüfen und speichern Sie die Reparatur und führen Sie anschließend dieses Artefakt aus:

terraform plan -var-file=release.tfvars -out=repair.tfplan
terraform show repair.tfplan
terraform apply repair.tfplan

Bestätigen Sie das aktuelle Tag und einen Plan ohne weitere Änderungen:

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
terraform plan -var-file=release.tfvars -detailed-exitcode

Das Tag ist 2; der abschließende Plan meldet No changes und endet mit 0. Der Bericht bleibt unverändert. Dies zeigt eine durch Abfragen erkennbare Tag-Abweichung und nicht die Erkennung jeder möglichen Datenänderung außerhalb von Terraform. Informationen zu gespeicherten Plänen und detaillierten Exit-Codes finden Sie unter Terraform plan.

Den geänderten Speicher bereinigen

In diesem Schritt entfernen Sie ausschließlich den von diesem Root-Modul verwalteten Speicher, nachdem die Änderungs- und Drift-Prüfungen bestanden wurden.

Prüfen Sie die Löschung und führen Sie sie aus. Geben Sie bei destroy den Wert yes ein:

terraform plan -destroy -var-file=release.tfvars
terraform destroy -var-file=release.tfvars

Das Berichtsobjekt wird vor seinem Bucket entfernt. Fragen Sie die verbleibenden Ressourcen und die leere Zuordnung ab:

terraform state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Der Referenzbericht des Teams bleibt erhalten. Gespeicherte lokale Pläne sind Prüfartefakte; ihr Vorhandensein bedeutet nicht, dass gelöschte AWS-Ressourcen noch existieren.

Zusammenfassung

Sie haben ein geprüftes natives Planartefakt ausgeführt, Aktualisierungen ohne Neuerstellung von Ersetzungen unterschieden, eine tatsächliche Tag-Abweichung durch Provider-Abfragen beobachtet, die gewünschte Konfiguration wiederhergestellt und die Berichtsdaten bis zur Bereinigung erhalten.