Eine vorhandene Ressource in die Verwaltung aufnehmen

Einführung

Sie übernehmen einen genutzten Berichts-Bucket, der außerhalb von Terraform erstellt wurde. Nehmen Sie ihn in die Verwaltung auf, ohne ihn neu zu erstellen oder seinen Bericht neu zu schreiben. Prüfen Sie anschließend einen kleinen Konfigurationsabgleich und führen Sie ihn aus, während der benachbarte Speicher des Finanzteams unverändert bleibt.

Sie sollten bereits Terraform-Konfiguration, Ressourcenadressen, init, plan, apply und lokalen State sowie grundlegende S3-Objektoperationen verstehen. Terraform, sein AWS-Provider, die Zugriffskonfiguration und zwei unabhängige Berichts-Buckets sind in dieser frischen Umgebung vorbereitet. Ein persönliches AWS-Konto oder Ressourcen aus einem früheren Lab sind nicht erforderlich.

Bezug zu Zertifizierungen

Lab-Überblick

Vorhandenen Speicher und gewünschte Konfiguration untersuchen

In diesem Schritt vergleichen Sie die bereits in AWS vorhandene Ressource mit der Konfiguration, die Sie gleich verwalten werden. AWS View oberhalb von Terminal zeigt dieselben S3-Ressourcen, die Ihre CLI liest. Klappen Sie report.txt in der Karte handover-daily-reports auf, um die Berichtsdaten zu untersuchen; finance-reference-reports gehört einem anderen Team und muss unverändert bleiben.

Eine Terraform-Ressourcenadresse, beispielsweise aws_s3_bucket.reports, kennzeichnet einen Konfigurationsblock. Der Bucket-Name kennzeichnet die entfernte AWS-Ressource. Der State hält die Zuordnung zwischen diesen beiden Identitäten fest. Eine Konfigurationsdatei allein stellt diese Zuordnung nicht her.

Wechseln Sie in das vorbereitete Stammverzeichnis und lesen Sie die gewünschte Bucket-Konfiguration:

cd /home/labex/project/report-storage
cat main.tf

Das Argument bucket wählt handover-daily-reports aus. Owner muss reporting bleiben; das neue Tag ManagedBy wird die Übergabe dokumentieren. force_destroy = false verhindert, dass Terraform bei einem späteren Löschvorgang einen nicht leeren Bucket automatisch leert. Dies ist eine Einstellung für das Verhalten von Terraform, unabhängig von dem im Bucket gespeicherten Bericht.

Untersuchen Sie die vorhandenen Tags:

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Anfangs ist nur Owner=reporting vorhanden. Geben Sie den ursprünglichen Bericht auf der Standardausgabe aus, indem Sie - als Ziel verwenden:

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

Erwarteter Bericht:

Daily sales: 120 orders

Initialisieren Sie das Arbeitsverzeichnis. init installiert den auf eine feste Version festgelegten Provider für dieses Stammverzeichnis; es importiert oder erstellt den Bucket nicht:

terraform init

Untersuchen Sie die vorgeschlagenen Aktionen, ohne sie auszuführen:

terraform plan

Der Plan schlägt 1 to add vor, weil dieses Stammverzeichnis noch keine Zuordnung zu einer verwalteten Ressource besitzt. Der Bucket existiert bereits; dies weist auf eine fehlende Verwaltungszuordnung im State hin und ist keine Erlaubnis, den Speicher zu ersetzen. Führen Sie diesen Erstellungsplan nicht aus. Im nächsten Schritt stellen Sie die Zuordnung ausdrücklich her.

Bevor Sie fortfahren, bestätigen Sie manuell, dass Sie den Berichts-Bucket identifizieren, seinen Bericht lesen und ihn vom Speicher des Finanzteams unterscheiden können. Die Hintergrundprüfung dieses Untersuchungsschritts prüft den Erhalt der vorbereiteten Ressourcen, nicht Ihr Verständnis des angezeigten Plans.

Den vorhandenen Bucket importieren und den Unterschied prüfen

In diesem Schritt ordnen Sie den vorhandenen Bucket seiner vorgesehenen Terraform-Adresse zu. Der CLI-Befehl import liest eine entfernte Ressource und erfasst ihre Identität im State. Er erzeugt weder die gewünschte Konfiguration noch importiert er jedes Objekt im Bucket.

Führen Sie den Import aus und geben Sie zuerst die Konfigurationsadresse und dann den Namen des vorhandenen Buckets an:

terraform import aws_s3_bucket.reports handover-daily-reports

Achten Sie auf Import successful!. Prüfen Sie, welche Adresse jetzt verwaltet wird:

terraform state list

Erwartete Adresse:

aws_s3_bucket.reports

Lesen Sie ihre Attribute:

terraform state show aws_s3_bucket.reports

Sowohl id als auch bucket sollten handover-daily-reports kennzeichnen. report.txt bleibt in S3 gespeichert; der Import eines Buckets übernimmt das Objekt nicht unter einer separaten Adresse vom Typ aws_s3_object. Der Bucket des Finanzteams darf nicht im State dieses Stammverzeichnisses erscheinen.

Ein Import garantiert nicht, dass der Plan sofort leer ist. Einige Einstellungen stammen vom entfernten Dienst; andere, darunter force_destroy, beschreiben das Verhalten von Terraform selbst und müssen nach dem Import möglicherweise mit der Konfiguration abgeglichen werden. Ein solcher Unterschied bedeutet nicht, dass Ihr Bericht beschädigt wurde.

Speichern Sie einen Plan zur Prüfung. -out=handover.tfplan speichert die geplanten Aktionen, damit Sie im nächsten Schritt denselben geprüften Plan ausführen können:

terraform plan -out=handover.tfplan

Lesen Sie den gespeicherten Plan:

terraform show handover.tfplan

Erwarten Sie eine Aktualisierung ohne Neuerstellung (~), das hinzugefügte Tag ManagedBy=Terraform und möglicherweise einen Abgleich von force_destroy auf false. Die Zusammenfassung muss lauten:

Plan: 0 to add, 1 to change, 0 to destroy.

Wenn der Plan eine Löschung, einen Ersatz, eine Erstellung, einen anderen Bucket-Namen oder Änderungen am Speicher des Finanzteams vorschlägt, halten Sie an und prüfen Sie Stammverzeichnis, Ressourcenadresse und Import-ID. Beheben Sie einen unerwarteten Plan nicht durch Löschen des vorhandenen Berichts.

Den Abgleich anwenden und den Datenerhalt bestätigen

In diesem Schritt führen Sie ausschließlich den geprüften Plan aus und weisen nach, dass der ursprüngliche Bericht erhalten bleibt. Wenn Sie apply einen gespeicherten Plan übergeben, wird dieser direkt und ohne zweite Bestätigungsabfrage ausgeführt. Führen Sie ihn erst aus, nachdem Sie die Zusammenfassung des vorherigen Schritts mit null Erstellungen und null Löschungen bestätigt haben:

terraform apply handover.tfplan

Erwarten Sie Resources: 0 added, 1 changed, 0 destroyed. Der Bucket wird jetzt verwaltet, und das Übergabe-Tag stimmt mit der Konfiguration überein.

Lesen Sie die aktuellen Tags, um das Ergebnis in AWS zu überprüfen:

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Sowohl Owner=reporting als auch ManagedBy=Terraform sollten vorhanden sein; die Reihenfolge der Tags ist unerheblich.

Lesen Sie den Bericht erneut:

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

Er muss weiterhin Daily sales: 120 orders enthalten. Klappen Sie in AWS View beide Berichte auf und bestätigen Sie, dass der Berichtsinhalt und die Referenz des Finanzteams weiterhin verfügbar sind. Ein Tag-Abgleich erfordert weder einen neuen Bucket noch das Neuschreiben eines Objekts.

Prüfen Sie die Übereinstimmung zwischen der aktuellen Konfiguration, dem State und der frisch abgefragten AWS-Ressource:

terraform plan

Erwartetes Ergebnis:

No changes. Your infrastructure matches the configuration.

Ein Plan ohne Änderungen allein reicht als Nachweis einer sicheren Übergabe nicht aus: Sie haben auch die vorgesehene Ressourcenadresse und die ursprünglichen Daten geprüft. Die Hintergrundprüfung vergleicht zusätzlich die ursprüngliche Objektversion und den benachbarten Speicher und erstellt in einer temporären Kopie einen Plan für die aktuelle Konfiguration, um die Übereinstimmung zu bestätigen. Behalten Sie für diese Übergabe beide Buckets bei. Führen Sie terraform destroy nicht aus: Der Bericht wird weiterhin verwendet. Schützen Sie bei einer echten Übergabe den State als sensible Betriebsdaten und organisieren Sie den Zugriff für die nächste verantwortliche Person; übertragen Sie State oder gespeicherte Pläne mit sensiblen Werten nicht in ein öffentliches Repository.

Weitere Informationen finden Sie in HashiCorps Workflow für CLI-Importe.

Zusammenfassung

Sie haben einen vorhandenen Bucket mit der Terraform-Konfiguration verglichen, seine Identität unter der vorgesehenen State-Adresse importiert und einen Abgleich ohne Löschung oder Neuerstellung geprüft, bevor Sie ihn ausgeführt haben. Sie haben einen Plan ohne Änderungen bestätigt und dabei den ursprünglichen Bericht sowie den Speicher des Finanzteams erhalten. Der Import stellt die Verwaltung her; die Konfigurationsprüfung bestimmt, was Terraform als Nächstes ändern soll.