Einführung
Ein verständlicherer Name in der Konfiguration sollte keine Neuerstellung von funktionierendem Speicher erfordern. Benennen Sie die Terraform-Adresse eines verwalteten Berichts-Buckets um, prüfen Sie den Unterschied zwischen einer unsicheren direkten Umbenennung und einer deklarierten Verschiebung und erhalten Sie seine ursprünglichen Daten.
Sie benötigen Erfahrung mit Terraform-Import, State und Plänen aus dem vorherigen geführten Lab oder aus gleichwertiger Praxis. Diese frische Umgebung stellt einen eigenen verwalteten Bericht und eine unabhängige Referenz des Finanzteams bereit. Verwenden Sie Terminal für Terraform und AWS View für die vorhandenen Berichte; ein persönliches AWS-Konto ist nicht erforderlich.
Bezug zu Zertifizierungen
| Zertifizierung | Prüfungsaufgabe | Übung |
|---|---|---|
| CloudOps Engineer – Associate (SOA-C03) | Task 3.1, Skill 3.1.6 | Terraform-Grundlagenübung: Infrastruktur durch geprüfte Konfigurations- und State-Änderungen warten und dabei funktionierende Ressourcen erhalten. |
Lab-Überblick
Logische Adressen und entfernte Ressourcenidentität vergleichen
In diesem Schritt untersuchen Sie eine funktionierende Terraform-Konfiguration in ihrem Stammverzeichnis, bevor Sie ihre Ressource umbenennen. Das Stammverzeichnis und zwei versionierte Berichte sind unabhängig für dieses Lab vorbereitet. Der Berichts-Bucket wird hier verwaltet; der Speicher des Finanzteams liegt außerhalb dieser Terraform-Konfiguration.
cd /home/labex/project/report-refactor
terraform state list
Die ursprüngliche Adresse lautet aws_s3_bucket.reports. Lesen Sie die ID der entfernten Ressource:
terraform state show aws_s3_bucket.reports
id = "rename-daily-reports" kennzeichnet den vorhandenen AWS-Bucket. Das Umbenennen eines Terraform-Blocks ändert dessen logische Adresse, nicht diesen Bucket-Namen.
Lesen Sie die bereitgestellte Konfiguration und bestätigen Sie einen Ausgangszustand ohne ausstehende Änderungen:
cat main.tf
terraform plan
Erwarten Sie No changes. Klappen Sie in AWS View den Bericht in rename-daily-reports auf; lassen Sie rename-finance-reference unverändert. Lesen Sie dieselben Berichtsbytes in Terminal:
aws s3 \
cp s3://rename-daily-reports/report.txt -
Erwarten Sie Daily sales: 120 orders. Ziel ist es, die Adresse zu ändern, unter der dieser Speicher verwaltet wird, und dabei seine Identität sowie die ursprüngliche Objektversion zu erhalten.
Die Umbenennung mit einem moved-Block beschreiben
In diesem Schritt beobachten Sie, warum eine direkte Adressumbenennung zu einem Plan mit Löschung führt. Anschließend teilen Sie Terraform mit, dass sich die neue Adresse auf dieselbe Ressource bezieht.
Ein Here-Dokument schreibt die Konfiguration zwischen den HCL-Markierungen in main.tf; > ersetzt diese Datei. Ändern Sie nur die lokale Blockbezeichnung in report_archive und lassen Sie den Namen und die Attribute des entfernten Buckets unverändert:
cat > main.tf <<'HCL'
resource "aws_s3_bucket" "report_archive" {
bucket = "rename-daily-reports"
force_destroy = false
tags = { Owner = "reporting" }
}
HCL
Untersuchen Sie das Ergebnis, bevor Sie Änderungen anwenden:
terraform plan
Ohne eine Beziehung zwischen den Adressen erkennt Terraform die alte Adresse als fehlend und eine neue Adresse ohne State-Zuordnung. Erwarten Sie 1 to add, 0 to change, 1 to destroy. Führen Sie diesen Plan nicht aus und löschen Sie den Bericht nicht, um die Löschung des Buckets zu ermöglichen.
Ein moved-Block deklariert eine Beziehung zwischen alter und neuer Adresse. Damit wird eine Umstrukturierung der Konfiguration dokumentiert, während der Name des AWS-Buckets unverändert bleibt. Legen Sie die Deklaration in einer separaten .tf-Datei ab; Terraform liest alle .tf-Dateien in diesem Stammverzeichnis gemeinsam:
cat > moved.tf <<'HCL'
moved {
from = aws_s3_bucket.reports
to = aws_s3_bucket.report_archive
}
HCL
Speichern und prüfen Sie den korrigierten Plan:
terraform plan -out=rename.tfplan
Erwarten Sie aws_s3_bucket.reports has moved to aws_s3_bucket.report_archive und 0 to add, 0 to change, 0 to destroy. Die geplante State-Adresse ändert sich, während die AWS-Ressource nicht neu erstellt werden muss. Behalten Sie die Deklaration zusammen mit der Konfiguration bei, damit auch ältere State-Kopien die Umstrukturierung nachvollziehen können.
Die Adressmigration anwenden und den Bericht erhalten
In diesem Schritt führen Sie den gespeicherten sicheren Plan aus und bestätigen, dass sich nur die logische Adresse geändert hat. Ein gespeicherter Plan wird ohne erneute Bestätigungsabfrage ausgeführt. Bestätigen Sie daher zunächst, dass seine Zusammenfassung null Erstellungen und null Löschungen ausweist.
terraform apply rename.tfplan
Die Ressourcenzusammenfassung sollte 0 added, 0 changed, 0 destroyed anzeigen. Untersuchen Sie die daraus entstandene Zuordnung:
terraform state list
terraform state show aws_s3_bucket.report_archive
Nur die neue Adresse wird aufgelistet, und ihre Bucket-ID bleibt rename-daily-reports. Prüfen Sie den tatsächlichen Bericht:
aws s3 \
cp s3://rename-daily-reports/report.txt -
Der ursprüngliche Text lautet weiterhin Daily sales: 120 orders. AWS View zeigt weiterhin dieselben Buckets des Berichtswesens und des Finanzteams; bei einer logischen Umbenennung ist keine neue Ressourcenkarte zu erwarten.
terraform plan
Erwarten Sie No changes. Die unabhängige Prüfung vergleicht zusätzlich die ursprüngliche VersionId und den benachbarten Speicher und erstellt in einer temporären Kopie einen Plan für die aktuelle Konfiguration. Lassen Sie beide genutzten Berichte für die nächste verantwortliche Person unversehrt.
Informationen zur Bedeutung beibehaltener moved-Deklarationen bei der Weiterentwicklung von Modulen finden Sie in HashiCorps Dokumentation zur Ressourcenumstrukturierung.
Zusammenfassung
Sie haben eine Terraform-Adresse von einer AWS-Ressourcen-ID unterschieden, einen zerstörerischen Plan aus einer direkten Umbenennung verworfen und eine moved-Deklaration angewendet, ohne den Bucket oder den Bericht neu zu erstellen.
