Examiner et appliquer une modification de stockage

Introduction

Votre équipe doit étiqueter un stockage de rapports existant comme release 2 sans recréer le stockage ni modifier son rapport. Vous allez examiner un plan enregistré, l'appliquer, puis détecter et corriger une dérive de tag délibérée.

Cet environnement indépendant prépare le petit stockage de départ et l'état local. Utilisez vos connaissances de plan/apply, des fichiers de variables et des requêtes S3 ; l'état distant et les approbations automatisées ne sont pas nécessaires.

Liens avec les certifications

Examiner et appliquer un plan enregistré

Dans cette étape, vous allez mettre à jour le tag de release d'un stockage de rapports préparé à l'aide d'un plan enregistré, tout en conservant son bucket et son rapport existants.

Cette configuration racine neuve gère déjà le petit stockage que les labs précédents vous ont appris à créer. La préparation fournit cette situation de départ pour vous permettre de vous concentrer sur l'examen des modifications. La nouvelle release souhaitée est 2 ; le rapport existant doit rester orders,12. Commencez par lire la configuration, les valeurs et le tag actuel :

cd /home/labex/project/storage-change
cat main.tf
cat release.tfvars
terraform state list
aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports

Le fichier d'entrée sélectionne actuellement la release 1. Modifier le nom d'une ressource pourrait remplacer le stockage, mais modifier un tag peut mettre à jour le bucket existant. Modifiez uniquement l'entrée de release :

cat > release.tfvars <<'EOF'
release = "2"
EOF
terraform plan -var-file=release.tfvars -out=change.tfplan

Une mise à jour sur place du bucket est attendue : 0 to add, 1 to change, 0 to destroy. -out écrit un artefact de plan natif qui contient cette configuration et ces valeurs d'entrée. À la différence d'un aperçu non enregistré, appliquer ce fichier utilise le plan examiné au lieu d'en générer un nouveau à partir de modifications ultérieures. Dans de véritables projets, les plans peuvent contenir des valeurs sensibles ; traitez-les donc comme des artefacts du projet.

Lisez le plan enregistré avant de l'appliquer :

terraform show change.tfplan

Confirmez que Release passe de 1 à 2 et qu'aucun objet ni bucket n'est remplacé. Appliquez ensuite l'artefact. Aucune demande supplémentaire de saisie de yes n'apparaît pour un plan enregistré :

terraform apply change.tfplan

Interrogez le tag actuel et lisez le rapport :

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

Les résultats attendus sont la release 2 et orders,12. Un plan enregistré n'est utile que si la ressource après application et les données préservées correspondent à la modification examinée.

Détecter et corriger une dérive de tag

Dans cette étape, vous allez observer une véritable modification de tag effectuée en dehors de Terraform et rétablir la configuration déclarée sans modifier le rapport.

Une dérive est une différence entre la ressource déployée et sa configuration souhaitée. Utilisez l'AWS CLI pour modifier le tag en dehors de Terraform. Cet exercice délibéré modifie un véritable attribut de ressource que le fournisseur peut lire ; il ne modifie pas un marqueur local de réussite.

aws s3api \
  put-bucket-tagging \
  --bucket terraform-change-reports \
  --tagging '{"TagSet":[{"Key":"Project","Value":"TerraformReports"},{"Key":"Release","Value":"unexpected"}]}'

Demandez à Terraform de comparer la ressource actuelle avec la release souhaitée. -detailed-exitcode distingue 0 (aucune modification), 2 (une modification proposée) et 1 (une erreur). Le plan suivant renvoie intentionnellement 2 ; cela signifie qu'il a détecté la différence de tag, pas que le déploiement a échoué.

terraform plan -var-file=release.tfvars -detailed-exitcode

Le plan propose de ramener unexpected à 2. Examinez et enregistrez la correction, puis appliquez cet artefact :

terraform plan -var-file=release.tfvars -out=repair.tfplan
terraform show repair.tfplan
terraform apply repair.tfplan

Confirmez le tag actuel et la convergence du plan :

aws s3api \
  get-bucket-tagging \
  --bucket terraform-change-reports
terraform plan -var-file=release.tfvars -detailed-exitcode

Le tag vaut 2 ; le plan final indique No changes et se termine avec le code 0. Le rapport reste inchangé. Cela démontre la détection d'une dérive de tag lisible, pas celle de toute modification possible de données effectuée en dehors de Terraform. Consultez Terraform plan pour les plans enregistrés et les codes de sortie détaillés.

Nettoyer le stockage modifié

Dans cette étape, vous allez supprimer uniquement le stockage géré par cette configuration racine après la réussite des contrôles de modification et de dérive.

Examinez et exécutez la suppression, en saisissant yes pour destroy :

terraform plan -destroy -var-file=release.tfvars
terraform destroy -var-file=release.tfvars

L'objet de rapport est supprimé avant son bucket. Interrogez les ressources restantes et la correspondance vide :

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

Le rapport de référence de l'équipe est conservé. Les plans locaux enregistrés sont des artefacts d'examen ; leur présence ne signifie pas que les ressources AWS supprimées existent encore.

Résumé

Vous avez appliqué un artefact de plan natif examiné, distingué les mises à jour sur place du remplacement, observé une véritable dérive de tag à travers les lectures du fournisseur, rétabli la configuration souhaitée et conservé les données du rapport jusqu'au nettoyage.