Ihre erste AWS-Ressource erstellen und entfernen

Einführung

Ihr Team benötigt privaten Speicher für Berichte. In diesem Lab erstellen Sie den ersten Bucket mit Terraform, vergleichen seine Konfiguration mit AWS und dem Terraform-State und prüfen anschließend seine Löschung, bevor Sie sie ausführen. Ein separater Referenzbericht gehört einem anderen Team und muss unverändert bleiben.

Sie sollten bereits Terraform-Ressourcen, init, plan, apply, State und destroy verstehen und mit dem Bearbeiten von Dateien und S3-Abfragen über die AWS CLI vertraut sein. Terraform, der AWS-Provider und der CLI-Zugriff sind vorbereitet. Verwenden Sie Terminal für Befehle und AWS View, um den Speicher zu beobachten; ein persönliches AWS-Konto oder Zugriffsschlüssel sind nicht erforderlich. Jedes Lab beginnt unabhängig von den anderen.

Bezug zu Zertifizierungen

Den Berichts-Bucket erstellen

In diesem Schritt verknüpfen Sie eine Terraform-Ressourcendefinition mit dem aktuellen AWS-Konto und erstellen einen privaten Berichts-Bucket.

Wechseln Sie zunächst in das vorbereitete Stammverzeichnis und fragen Sie Ihre Region und die Identität des Aufrufers ab. Ein Stammverzeichnis enthält eine eigenständige Terraform-Konfiguration mit eigenem State. Das Konto des Aufrufers zeigt, in welchem Konto die Anfragen des Providers ausgeführt werden; der ARN kennzeichnet die anfragende Identität.

cd /home/labex/project/first-aws-resource
aws configure get region
aws sts \
  get-caller-identity
terraform version

Die Region ist us-east-1. Terraform meldet Version 1.17.2. Ihr vorbereiteter Zugriff ist von persönlichen AWS-Konten getrennt.

Die bereitgestellte Datei provider.tf wählt den AWS-Provider in Version 6.14.0, konfiguriert die vorbereitete Verbindung und legt Terraform auf Version 1.17.2 fest. Der Provider übersetzt Ressourcenoperationen in AWS-API-Anfragen. Seine Konfiguration ist bereits vorhanden, damit Sie sich auf die Ressourcenverwaltung konzentrieren können.

Erstellen Sie main.tf mit der folgenden Konfiguration. cat und <<'EOF' schreiben alles bis zum abschließenden EOF in die angegebene Datei. aws_s3_bucket ist der AWS-Ressourcentyp; reports ist die lokale Bezeichnung in Terraform. Gemeinsam bilden sie die Adresse aws_s3_bucket.reports. Das Attribut bucket ist der AWS-Bucket-Name und unterscheidet sich von dieser Adresse. Tags halten den Zweck der Ressource fest.

cat > main.tf <<'EOF'
resource "aws_s3_bucket" "reports" {
  bucket = "terraform-first-reports"
  tags = {
    Project = "TerraformReports"
  }
}

output "report_bucket" {
  value = aws_s3_bucket.reports.id
}
EOF

Initialisieren Sie dieses Stammverzeichnis und validieren Sie seine Konfiguration:

terraform init
terraform validate

init installiert den festgelegten Provider aus dem vorbereiteten Cache und schreibt .terraform.lock.hcl. Bewahren Sie diese Datei zur Sperrung der Abhängigkeitsversionen zusammen mit der Konfiguration eines echten Projekts auf: Sie hält den ausgewählten Provider und die Paketprüfsummen fest. Sie unterscheidet sich vom Terraform-State, der Ressourcenadressen den IDs bereitgestellter Ressourcen zuordnet. Da der Cache für diese Linux-Umgebung vorbereitet ist, kann init darauf hinweisen, dass die Prüfsummen der Lock-Datei nur linux_amd64 abdecken; die Initialisierung wird dennoch abgeschlossen. Ein Projekt, das auf weiteren Plattformen verwendet wird, benötigt auch Prüfsummen für diese Plattformen.

Prüfen Sie den Plan, bevor Sie etwas erstellen:

terraform plan

Erwarten Sie Plan: 1 to add, 0 to change, 0 to destroy. Einige Attribute zeigen (known after apply), weil AWS sie während der Erstellung zuweist oder zurückgibt. Kontrollieren Sie den Bucket-Namen und das Projekt-Tag. Ein Plan zeigt eine Vorschau der Aktionen; er erstellt den Bucket noch nicht.

Wenden Sie die Konfiguration an und geben Sie bei der Bestätigungsabfrage yes ein:

terraform apply

Erwarten Sie Apply complete! Resources: 1 added, 0 changed, 0 destroyed. Der Ausgabewert report_bucket ist terraform-first-reports. In AWS View erscheint der neue leere Bucket neben team-reference-reports. Lassen Sie diesen Referenz-Bucket und sein Objekt keep.txt unverändert.

Verwenden Sie Continue, nachdem Sie die Befehle ausgeführt haben. Die Prüfung fragt AWS und die State-Zuordnung unabhängig voneinander ab; ein erfolgreicher Befehl allein reicht nicht aus.

Konfiguration, State und AWS vergleichen

In diesem Schritt stellen Sie die Verbindung zwischen der Terraform-Ressourcenadresse und dem tatsächlichen privaten Bucket her. Anschließend bestätigen Sie, dass die Konfiguration einen übereinstimmenden Zustand erreicht hat.

Die Ausgabe liest die Bucket-ID über eine Ressourcenreferenz. state list zeigt die verwaltete Adresse; state show zeigt ihre erfassten Attribute. Diese Befehle untersuchen die Zuordnung, ohne AWS zu verändern.

terraform output report_bucket
terraform state list
terraform state show aws_s3_bucket.reports

Suchen Sie nach aws_s3_bucket.reports und seiner ID terraform-first-reports. Ihre Konfiguration beschreibt die gewünschte Ressource, AWS enthält die Ressource und der State verbindet beides. Ein State-Eintrag allein beweist nicht, dass die Ressource noch existiert.

Fragen Sie AWS direkt ab. get-bucket-location gibt für die S3-Region us-east-1 den Wert null zurück. Die ACL sollte nur dem kanonischen Benutzer des Eigentümers Zugriff gewähren; es darf keine öffentliche Gruppenberechtigung geben. Dieses Lab erstellt einen privaten Bucket und fügt keine öffentliche Bucket-Richtlinie hinzu.

aws s3api \
  get-bucket-location \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-acl \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-tagging \
  --bucket terraform-first-reports

Bestätigen Sie, dass das Tag Project den Wert TerraformReports hat. Prüfen Sie, ob der unabhängige Bericht weiterhin lesbar ist. Der Ausdruck --query wählt nur seine Länge in Byte aus, und der Befehl lässt das gespeicherte Objekt unverändert.

aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength
terraform plan

Der Plan sollte No changes. melden. Dies bedeutet, dass der Provider keine Konfigurationsänderungen für die verwalteten Ressourcen erkennt. Es beweist weder alle denkbaren Sicherheitseigenschaften noch die Gültigkeit der Berichtsdaten; dafür sind eigene Prüfungen erforderlich. Weitere Informationen finden Sie unter Terraform-State und S3-Zugriffssteuerung.

Nur die verwaltete Ressource entfernen

In diesem Schritt prüfen Sie einen Löschplan und führen ihn aus. Danach weisen Sie nach, dass der verwaltete Bucket und seine State-Zuordnung entfernt wurden, während der Referenzbericht erhalten bleibt.

terraform plan -destroy zeigt eine Vorschau der Löschung von Ressourcen im State dieses Stammverzeichnisses. Es bedeutet nicht „alle Buckets im Konto löschen“. Lesen Sie die Adresse und die Bucket-ID, bevor Sie fortfahren:

terraform plan -destroy

Erwarten Sie Plan: 0 to add, 0 to change, 1 to destroy. Der Referenz-Bucket fehlt im Plan, weil dieses Stammverzeichnis ihn nicht verwaltet. Der Ziel-Bucket ist leer; spätere Labs erläutern, warum gespeicherte Daten und Versionen eigene Entscheidungen zur Aufbewahrung erfordern.

Löschen Sie den verwalteten Bucket und geben Sie bei der Bestätigungsabfrage yes ein:

terraform destroy

Erwarten Sie Destroy complete! Resources: 1 destroyed. Untersuchen Sie jetzt den State und fragen Sie die verbleibenden Buckets ab:

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

Die State-Liste ist leer. terraform-first-reports fehlt in der erfolgreich abgerufenen Bucket-Liste; team-reference-reports und sein Bericht bleiben erhalten. Lassen Sie den AWS-Zugriff konfiguriert, bis die abschließende Prüfung abgeschlossen ist, damit ein Authentifizierungsfehler nicht mit einer erfolgreichen Löschung verwechselt werden kann. Die Konfiguration und die Lock-Datei bleiben verfügbar, falls Sie die Ressource erneut erstellen möchten.

Zusammenfassung

Sie haben mit einem auf eine feste Version festgelegten AWS-Provider einen privaten S3-Bucket erstellt, Konfiguration und State mit AWS-Abfragen verglichen, einen Plan ohne weitere Änderungen geprüft und ausschließlich die verwaltete Ressource gelöscht. Der unabhängige Referenzbericht blieb unversehrt. Im nächsten Lab verwenden Sie Eingaben und Ressourcenreferenzen, um Berichtsinhalte zu verwalten.