Protéger l’historique des rapports pendant les mises à jour

Introduction

Un rapport plus récent ne doit pas priver l'équipe de la possibilité de lire ses données antérieures. Vous allez configurer la gestion des versions, publier deux rapports et distinguer les lectures historiques des lectures courantes avant de nettoyer délibérément ce stockage jetable.

Utilisez les connaissances sur les variables, les références d'objets et les configurations racines indépendantes acquises dans le lab précédent. Cet environnement neuf fournit uniquement les outils, l'accès du fournisseur et un rapport de référence indépendant.

Liens avec les certifications

Publier la première version

Dans cette étape, vous allez gérer la configuration de gestion des versions du bucket avec Terraform avant de publier son premier rapport.

Les versions d'objets S3 sont des copies conservées des données, chacune avec un identifiant de version. Elles diffèrent des révisions Git du HCL et du fichier de verrouillage des fournisseurs de Terraform. Terraform peut configurer la gestion des versions ; S3 conserve ensuite les versions d'objets lors des mises à jour des données. Un plan sans modification ne prouve pas à lui seul que les données historiques sont lisibles.

Entrez dans le répertoire racine préparé et écrivez la définition du stockage :

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

Il y a maintenant trois ressources : un bucket, ses paramètres de gestion des versions et un objet. L'objet dépend déjà du bucket par sa référence à l'identifiant. Le depends_on explicite ajoute l'ordre qui ne peut pas être déduit de cette référence : la gestion des versions doit être activée avant le premier téléversement.

Écrivez l'entrée du premier rapport et initialisez :

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

Trois ajouts sont attendus. Appliquez et saisissez yes :

terraform apply -var-file=release1.tfvars

Interrogez le paramètre effectif et la première version :

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}'

Le statut est Enabled. Le rapport possède un identifiant de version non nul et Current: true. AWS View affiche l'objet actuellement lisible ; utilisez la requête sur les versions pour inspecter l'historique.

Mettre à jour le rapport et lire son historique

Dans cette étape, vous allez publier des octets différents, lire explicitement l'ancienne version et prouver que la lecture de l'historique laisse le rapport courant inchangé.

Créez un second fichier d'entrée. Conserver les deux fichiers facilite la comparaison des versions de données prévues ; les fichiers eux-mêmes ne constituent pas l'historique stocké.

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

Une mise à jour d'objet est attendue, sans remplacement du bucket. -out enregistre un artefact de plan qui inclut les valeurs d'entrée sélectionnées. Appliquez cet artefact examiné ; cette commande ne demande pas de confirmation, car vous avez déjà sélectionné le plan enregistré :

terraform apply update.tfplan

Répertoriez à nouveau les versions réelles :

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

L'ancienne entrée et l'entrée courante possèdent des identifiants de version différents. Sélectionnez l'identifiant du rapport antérieur et affichez-le. La requête filtre la clé du rapport et IsLatest == false ; [0] choisit la première ancienne entrée correspondante dans l'historique à deux versions de ce lab.

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"

Téléchargez l'ancienne version par son identifiant, puis téléchargez la version courante sans identifiant de version :

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

Les résultats attendus sont orders,12 dans l'ancien fichier et orders,25 dans le fichier courant. Un GET visant une version précise lit une version existante ; il ne la copie pas par-dessus l'objet courant. Interrogez une nouvelle fois l'identifiant courant et comparez-le à la valeur affichée de CURRENT_VERSION :

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

L'identifiant est inchangé. Terminez la vérification de cette étape avant de supprimer des versions. Le contrôle lit les octets réels anciens et courants et préserve les deux. Consultez la gestion des versions S3 pour distinguer une clé d'objet, ses versions et les marqueurs de suppression.

Supprimer délibérément l'historique créé

Dans cette étape, vous allez inventorier et supprimer toutes les versions de votre bucket de rapports jetable avant de supprimer ses ressources de configuration Terraform.

Détruire l'infrastructure et décider d'abandonner l'historique des rapports sont des actions différentes. Un bucket versionné non vide ne peut normalement pas être supprimé. Supprimer un objet courant sans identifiant de version peut créer un marqueur de suppression, qui masque l'objet courant tandis que les anciennes versions subsistent. Ici, vous supprimerez explicitement les versions inventoriées par identifiant, après avoir prouvé leur conservation à l'étape précédente.

Créez une requête de suppression à partir de la liste native des versions. Ce lab ne contient qu'un petit ensemble de versions de rapports et aucun marqueur de suppression existant ; chaque version répertoriée appartient à votre bucket. --query transforme chaque entrée en champs Key/VersionId acceptés par delete-objects.

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

Vérifiez que le fichier contient uniquement des versions de terraform-history-reports. Supprimez ensuite ces versions précises. file:// demande à l'AWS CLI de lire une requête JSON depuis le fichier local.

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

La liste obtenue avec succès ne comporte aucune entrée Versions ni DeleteMarkers. Détruisez maintenant les ressources de cette configuration racine et saisissez yes :

terraform destroy -var-file=release2.tfvars

Terraform actualise d'abord l'état et peut constater que l'objet a déjà été supprimé. Il supprime ensuite la configuration de gestion des versions restante et le bucket vide. Inspectez enfin la correspondance et la référence conservée :

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

La liste de l'état est vide et seul le bucket de référence de l'équipe subsiste. N'utilisez pas cette procédure d'abandon des données sur un stockage dont l'historique doit être conservé.

Résumé

Vous avez distingué les modifications de configuration des versions de données, activé la gestion des versions avant le téléversement, lu les octets distincts des rapports ancien et courant sans écraser la version courante, et explicitement inventorié et supprimé uniquement les versions créées dans votre stockage.