Die Berichtshistorie bei Aktualisierungen schützen

Einführung

Ein neuerer Bericht darf dem Team nicht die Möglichkeit nehmen, frühere Daten zu lesen. Sie konfigurieren die Versionierung, veröffentlichen zwei Berichte und unterscheiden das Lesen historischer Versionen vom Lesen der aktuellen Version, bevor Sie diesen entbehrlichen Speicher bewusst bereinigen.

Nutzen Sie Ihre Kenntnisse zu Variablen, Objektreferenzen und unabhängigen Root-Modulen aus dem vorherigen Lab. Diese frische Umgebung stellt ausschließlich Werkzeuge, Provider-Zugriff und einen unabhängigen Referenzbericht bereit.

Bezug zu Zertifizierungen

Die erste Version veröffentlichen

In diesem Schritt verwalten Sie die Versionierungskonfiguration des Buckets mit Terraform, bevor Sie seinen ersten Bericht veröffentlichen.

S3-Objektversionen sind aufbewahrte Datenkopien mit jeweils einer Versions-ID. Sie unterscheiden sich von Git-Revisionen der HCL-Dateien und von der Provider-Sperrdatei von Terraform. Terraform kann die Versionierung konfigurieren; S3 bewahrt anschließend bei Datenaktualisierungen Objektversionen auf. Ein Plan ohne Änderungen allein beweist nicht, dass historische Daten lesbar sind.

Wechseln Sie in das vorbereitete Stammverzeichnis und schreiben Sie die Speicherdefinition:

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

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-history-reports"
}

resource "aws_s3_bucket_versioning" "reports" {
  bucket = aws_s3_bucket.reports.id
  versioning_configuration {
    status = "Enabled"
  }
}

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

Es gibt jetzt drei Ressourcen: einen Bucket, seine Versionierungseinstellungen und ein Objekt. Das Objekt hängt durch seine ID-Referenz bereits vom Bucket ab. Das explizite depends_on ergänzt die Reihenfolge, die aus dieser Referenz nicht abgeleitet werden kann: Die Versionierung muss vor dem ersten Upload aktiviert sein.

Schreiben Sie die Eingabe für den ersten Bericht und initialisieren Sie die Konfiguration:

cat > release1.tfvars <<'EOF'
report = "orders,12\n"
EOF
terraform init
terraform validate
terraform plan -var-file=release1.tfvars

Erwarten Sie drei Erstellungen. Wenden Sie die Konfiguration an und geben Sie yes ein:

terraform apply -var-file=release1.tfvars

Fragen Sie die tatsächliche Einstellung und die erste Version ab:

aws s3api \
  get-bucket-versioning \
  --bucket terraform-history-reports
aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[].{Key:Key,VersionId:VersionId,Current:IsLatest}'

Der Status lautet Enabled. Der Bericht hat eine Versions-ID ungleich null und Current: true. AWS View zeigt das aktuell lesbare Objekt; verwenden Sie die Versionsabfrage, um die Historie zu untersuchen.

Den Bericht aktualisieren und seine Historie lesen

In diesem Schritt veröffentlichen Sie andere Bytes, lesen die alte Version ausdrücklich aus und weisen nach, dass das Lesen der Historie den aktuellen Bericht unverändert lässt.

Erstellen Sie eine zweite Eingabedatei. Wenn Sie beide Dateien behalten, lassen sich die vorgesehenen Datenversionen leicht vergleichen; die Dateien selbst sind nicht die gespeicherte Historie.

cat > release2.tfvars <<'EOF'
report = "orders,25\n"
EOF
terraform plan -var-file=release2.tfvars -out=update.tfplan
terraform show update.tfplan

Erwarten Sie eine Objektaktualisierung ohne Ersetzung des Buckets. -out speichert ein Planartefakt, das die ausgewählten Eingabewerte enthält. Führen Sie dieses geprüfte Artefakt aus; dieser Befehl fragt nicht nach einer Bestätigung, weil Sie bereits den gespeicherten Plan ausgewählt haben:

terraform apply update.tfplan

Listen Sie die tatsächlichen Versionen erneut auf:

aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[].{Key:Key,VersionId:VersionId,Current:IsLatest}'

Die alten und aktuellen Einträge haben unterschiedliche Versions-IDs. Wählen Sie die ID des älteren Berichts aus und zeigen Sie sie an. Die Abfrage filtert nach dem Berichtsschlüssel und IsLatest == false; [0] wählt den ersten passenden alten Eintrag in der aus zwei Versionen bestehenden Historie dieses Labs aus.

OLD_VERSION=$(aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query 'Versions[?Key==`reports/current.csv` && IsLatest==`false`].VersionId | [0]' \
  --output text)
echo "$OLD_VERSION"
CURRENT_VERSION=$(aws s3api \
  head-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --query VersionId \
  --output text)
echo "$CURRENT_VERSION"

Laden Sie die alte Version anhand ihrer ID herunter und anschließend die aktuelle Version ohne Versions-ID:

aws s3api \
  get-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --version-id "$OLD_VERSION" \
  old-report.csv
cat old-report.csv
aws s3api \
  get-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  current-report.csv
cat current-report.csv

Erwarten Sie orders,12 in der alten Datei und orders,25 in der aktuellen Datei. Ein versionsspezifischer GET liest eine vorhandene Version; er kopiert sie nicht über das aktuelle Objekt. Fragen Sie die aktuelle ID erneut ab und vergleichen Sie sie mit dem angezeigten Wert CURRENT_VERSION:

aws s3api \
  head-object \
  --bucket terraform-history-reports \
  --key reports/current.csv \
  --query VersionId \
  --output text

Die ID ist unverändert. Schließen Sie die Prüfung dieses Schritts ab, bevor Sie Versionen löschen. Die Prüfung liest die tatsächlichen alten und aktuellen Bytes und erhält beide. Informationen zum Unterschied zwischen einem Objektschlüssel, seinen Versionen und Löschmarkierungen finden Sie unter S3-Versionierung.

Die eigene Historie bewusst entfernen

In diesem Schritt erfassen und löschen Sie alle Versionen in Ihrem entbehrlichen Berichts-Bucket, bevor Sie dessen Terraform-Konfigurationsressourcen entfernen.

Das Löschen von Infrastruktur und die Entscheidung, die Berichtshistorie zu verwerfen, sind unterschiedliche Handlungen. Ein nicht leerer versionierter Bucket lässt sich normalerweise nicht löschen. Das Entfernen eines aktuellen Objekts ohne Versions-ID kann eine Löschmarkierung erstellen, die das aktuelle Objekt verbirgt, während ältere Versionen erhalten bleiben. Hier löschen Sie die erfassten Versionen ausdrücklich anhand ihrer IDs, nachdem Sie im vorherigen Schritt ihre Aufbewahrung nachgewiesen haben.

Erstellen Sie eine Löschanfrage aus der nativen Versionsliste. Dieses Lab enthält nur eine kleine Anzahl von Berichtsversionen und keine vorhandenen Löschmarkierungen; jede aufgeführte Version gehört zu Ihrem Bucket. --query formt jeden Eintrag in die von delete-objects akzeptierten Felder Key/VersionId um.

aws s3api \
  list-object-versions \
  --bucket terraform-history-reports \
  --query '{Objects: Versions[].{Key:Key,VersionId:VersionId}}' \
  > owned-versions.json
cat owned-versions.json

Prüfen Sie, dass die Datei nur Versionen aus terraform-history-reports enthält. Löschen Sie dann genau diese Versionen. file:// weist die AWS CLI an, eine JSON-Anfrage aus der lokalen Datei zu lesen.

aws s3api \
  delete-objects \
  --bucket terraform-history-reports \
  --delete file://owned-versions.json
aws s3api \
  list-object-versions \
  --bucket terraform-history-reports

Die erfolgreiche Auflistung enthält keine Einträge unter Versions oder DeleteMarkers. Löschen Sie jetzt die Ressourcen dieses Root-Moduls und geben Sie yes ein:

terraform destroy -var-file=release2.tfvars

Terraform aktualisiert zuerst den State und kann dabei feststellen, dass das Objekt bereits entfernt wurde. Anschließend entfernt es die verbleibende Versionierungskonfiguration und den leeren Bucket. Untersuchen Sie abschließend die Zuordnung und die erhaltene Referenz:

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 und nur der Referenz-Bucket des Teams bleibt erhalten. Verwenden Sie dieses Verfahren zum Verwerfen von Daten nicht für einen Speicher, dessen Historie erhalten bleiben muss.

Zusammenfassung

Sie haben Konfigurationsänderungen von Datenversionen unterschieden, die Versionierung vor dem Upload aktiviert, unterschiedliche alte und aktuelle Berichtsbytes gelesen, ohne die aktuelle Version zu überschreiben, und ausschließlich eigene Versionen ausdrücklich erfasst und verworfen.