Einen privaten Berichtsspeicher parametrisieren

Einführung

Ihr Team benötigt Berichtsspeicher für Entwicklung und Vorschau mit unterschiedlichen Inhalten. Sie verwenden eine Konfiguration wieder, verfolgen die Referenzen zwischen Bucket und Objekt und weisen nach, dass zwei unabhängige Stammverzeichnisse unterschiedliche AWS-Ressourcen verwalten.

Bauen Sie auf dem ersten AWS-Terraform-Lab und Ihren vorhandenen Kenntnissen zu Variablen und Ausgabewerten auf. Werkzeuge, Zugriff und Provider-Verbindung sind vorbereitet; es werden keine Ressourcen aus früheren VMs wiederverwendet.

Bezug zu Zertifizierungen

Den Entwicklungsspeicher bereitstellen

In diesem Schritt erstellen Sie mit Eingabevariablen und einer Ressourcenreferenz einen Berichtsspeicher für die Entwicklung aus einer einzigen Konfiguration.

Die beiden vorbereiteten Stammverzeichnisse report-dev und report-preview sind anfangs bis auf die Datei für die Provider-Verbindung leer. Jedes Stammverzeichnis behält seinen eigenen lokalen State. Dies unterscheidet sich davon, Eingaben in einem einzigen Stammverzeichnis zu ändern: Ein Stammverzeichnis verwaltet weiterhin die Ressourcen, die bereits in seinem State erfasst sind.

Wechseln Sie in das Entwicklungs-Stammverzeichnis und erstellen Sie die Ressourcenvorlage. Die Variablen environment und report sind Eingaben vom Typ String. ${var.environment} fügt den Umgebungsnamen in den Bucket-Namen ein. Das Argument bucket des Objekts verweist auf die ID der Bucket-Ressource, sodass Terraform die Abhängigkeit erkennen und den Bucket zuerst erstellen kann. content_type gibt an, wie lesende Anwendungen die Bytes interpretieren sollen.

cd /home/labex/project/report-dev
cat > main.tf <<'EOF'
variable "environment" { type = string }
variable "report" { type = string }

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-reports-${var.environment}"
  tags = {
    Project     = "TerraformReports"
    Environment = var.environment
  }
}

resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = var.report
  content_type = "text/csv"
}

output "bucket_name" { value = aws_s3_bucket.reports.id }
output "report_key" { value = aws_s3_object.report.key }
EOF

Erstellen Sie eine Variablendatei für diese Umgebung. Die Escape-Sequenz \n steht für einen Zeilenumbruch in der Berichtszeichenfolge. Die Trennung der Werte ermöglicht die Wiederverwendung derselben Ressourcenvorlage.

cat > dev.tfvars <<'EOF'
environment = "dev"
report      = "orders,12\n"
EOF

Initialisieren und validieren Sie dieses Stammverzeichnis und prüfen Sie den Plan. -var-file wählt die Wertedatei aus; es wählt keinen anderen State aus.

terraform init
terraform validate
terraform plan -var-file=dev.tfvars

Erwarten Sie die Erstellung von zwei Ressourcen: dem Bucket und seinem Berichtsobjekt. Wenden Sie dieselben Eingaben an und geben Sie auf Nachfrage yes ein:

terraform apply -var-file=dev.tfvars

Die Ausgabewerte kennzeichnen den Bucket und den Objektschlüssel. Speichern Sie diese Werte mit $(...), das die Ausgabe eines Befehls erfasst, und zeigen Sie sie an. -raw gibt Zeichenfolgen ohne die Anführungszeichen von Terraform aus.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
KEY=$(terraform output -raw report_key)
echo "$KEY"

Lesen Sie den tatsächlich gespeicherten Bericht über AWS, statt einen Ausgabewert oder State-Eintrag als Nachweis der Daten zu betrachten. Die Antwort enthält ContentType: text/csv; die Zieldatei enthält die Bytes.

aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key "$KEY" \
  dev-downloaded.csv
cat dev-downloaded.csv

Erwarten Sie orders,12. In AWS View können Sie außerdem reports/current.csv in terraform-reports-dev aufklappen. Lassen Sie den separaten Referenzbericht des Teams unverändert.

Die Vorlage mit separatem State wiederverwenden

In diesem Schritt stellen Sie dieselbe Vorlage mit Vorschau-Eingaben bereit und erhalten dabei den Entwicklungsspeicher.

Kopieren Sie nur die Ressourcenvorlage in das vorbereitete Vorschau-Stammverzeichnis. Kopieren Sie in dieser Übung ausschließlich main.tf, weil jedes vorbereitete Stammverzeichnis separat initialisiert wird. Klonen Sie weder terraform.tfstate noch das initialisierte Verzeichnis .terraform/, um eine weitere Umgebung zu erstellen: Diese können die ursprüngliche Ressourcen- oder Backend-Zuordnung enthalten. Die Abhängigkeitssperrdatei .terraform.lock.hcl unterscheidet sich davon: Sie erfasst Provider-Versionen und Prüfsummen, kann zusammen mit der Konfiguration geteilt oder versioniert werden und enthält keine Zuordnung zu den Ressourcen einer Umgebung. Das Vorschau-Stammverzeichnis hat bereits eine eigene Datei für die Provider-Verbindung.

cp /home/labex/project/report-dev/main.tf /home/labex/project/report-preview/main.tf
cd /home/labex/project/report-preview
cat > preview.tfvars <<'EOF'
environment = "preview"
report      = "orders,25\n"
EOF

Initialisieren Sie dieses Stammverzeichnis und prüfen Sie den Vorschau-Plan:

terraform init
terraform plan -var-file=preview.tfvars

Erwarten Sie erneut zwei Erstellungen, mit terraform-reports-preview als Bucket-Namen. Eine unerwartete Löschung des Entwicklungs-Buckets würde darauf hinweisen, dass Sie den falschen State wiederverwendet haben. Wenden Sie die Konfiguration an und geben Sie yes ein:

terraform apply -var-file=preview.tfvars

Lesen Sie den Ausgabewert und den Bericht der Vorschau. Die Umgebungseingabe ändert den Namen und das Tag; die Berichtseingabe ändert die tatsächlich gespeicherten Bytes.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key reports/current.csv \
  preview-downloaded.csv
cat preview-downloaded.csv

Erwarten Sie orders,25. Vergleichen Sie die Ausgabewerte und State-Listen beider Stammverzeichnisse mit der globalen Terraform-Option -chdir. Sie führt den Befehl in einem angegebenen Stammverzeichnis aus, ohne das Verzeichnis Ihrer Shell zu ändern:

terraform -chdir=/home/labex/project/report-dev output bucket_name
terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview output bucket_name
terraform -chdir=/home/labex/project/report-preview state list

Beide Stammverzeichnisse haben Adressen wie aws_s3_bucket.reports, aber jede davon ist einem anderen AWS-Bucket zugeordnet. Bestätigen Sie, dass die Entwicklungsdaten unversehrt geblieben sind:

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

Erwarten Sie orders,12. Dies sind unabhängige lokale States, keine Workspaces und kein gemeinsames Backend. Die Dokumentation zu Terraform-Eingabevariablen erläutert die Auswahl von Variablendateien ausführlicher.

Beide eigenen Speicher bereinigen

In diesem Schritt löschen Sie die Ressourcen jedes Stammverzeichnisses, ohne den Referenzbericht des Teams zu löschen.

Jedes Stammverzeichnis benötigt beim Löschen seine eigenen Eingaben. Prüfen Sie den Löschplan für die Entwicklung, führen Sie anschließend die Löschung aus und geben Sie yes ein. Das Objekt wird vor seinem Bucket entfernt, weil Terraform ihre Abhängigkeit kennt.

terraform -chdir=/home/labex/project/report-dev plan -destroy -var-file=dev.tfvars
terraform -chdir=/home/labex/project/report-dev destroy -var-file=dev.tfvars

Entfernen Sie jetzt nur die Ressourcen des Vorschau-Stammverzeichnisses und bestätigen Sie erneut mit yes:

terraform -chdir=/home/labex/project/report-preview destroy -var-file=preview.tfvars

Jeder Löschvorgang meldet zwei entfernte Ressourcen. Prüfen Sie, dass beide Zuordnungen leer sind und der unabhängige Referenzbericht noch existiert:

terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Nur der Referenz-Bucket bleibt erhalten. Eine erfolgreiche authentifizierte Auflistung belegt das Fehlen der gelöschten Buckets; ein Zugriffs- oder Netzwerkfehler würde dies nicht tun. Behalten Sie die vorbereiteten Zugangsdaten bei, bis die abschließende Prüfung abgeschlossen ist.

Zusammenfassung

Sie haben eine Vorlage für Bucket und Objekt mit zwei Variablendateien wiederverwendet, die tatsächlichen Berichtsbytes und den Content-Type gelesen, den State jedes Stammverzeichnisses unabhängig gehalten und nur Ihre beiden Umgebungen bereinigt.