Renommer des ressources sans les recréer

Introduction

Un nom de configuration plus clair ne devrait pas nécessiter de recréer un stockage opérationnel. Renommez l'adresse Terraform d'un bucket de rapports géré, examinez la différence entre un renommage direct risqué et un déplacement déclaré, et conservez les données d'origine.

Vous devez avoir pratiqué l'import, l'état et les plans Terraform dans le lab guidé précédent ou disposer d'une expérience équivalente. Cet environnement neuf fournit son propre rapport géré et une référence indépendante pour la finance. Utilisez Terminal pour Terraform et AWS View pour les rapports existants ; aucun compte AWS personnel n'est nécessaire.

Liens avec les certifications

Aperçu du lab

Comparer les adresses logiques et l'identité distante

Dans cette étape, inspectez une configuration racine Terraform opérationnelle avant de renommer sa ressource. Cette configuration racine et les deux rapports versionnés sont préparés indépendamment pour ce lab. Le bucket de rapports est géré ici ; le stockage de la finance se trouve en dehors de cette configuration racine.

cd /home/labex/project/report-refactor
terraform state list

L'adresse d'origine est aws_s3_bucket.reports. Lisez son identifiant distant :

terraform state show aws_s3_bucket.reports

id = "rename-daily-reports" identifie le bucket AWS existant. Renommer un bloc Terraform modifie son adresse logique, pas ce nom de bucket.

Lisez la configuration fournie et établissez une référence sans modification en attente :

cat main.tf
terraform plan

Le résultat attendu est No changes. Dans AWS View, développez le rapport dans rename-daily-reports ; laissez rename-finance-reference inchangé. Lisez les mêmes octets du rapport dans Terminal :

aws s3 \
  cp s3://rename-daily-reports/report.txt -

Le résultat attendu est Daily sales: 120 orders. L'objectif est de changer l'adresse qui gère ce stockage tout en préservant son identité et la version d'origine de l'objet.

Décrire le renommage avec un bloc moved

Dans cette étape, observez pourquoi un renommage direct d'adresse paraît destructif, puis indiquez à Terraform que la nouvelle adresse désigne la même ressource.

Un document intégré écrit la configuration comprise entre les marqueurs HCL dans main.tf ; > remplace ce fichier. Modifiez uniquement le nom local du bloc en report_archive, en conservant le nom du bucket distant et ses attributs inchangés :

cat > main.tf <<'HCL'
resource "aws_s3_bucket" "report_archive" {
  bucket        = "rename-daily-reports"
  force_destroy = false
  tags = { Owner = "reporting" }
}
HCL

Inspectez le résultat avant toute application :

terraform plan

Sans relation entre les adresses, Terraform constate que l'ancienne adresse a disparu et qu'une nouvelle adresse n'a pas d'entrée dans l'état. Le résultat attendu est 1 to add, 0 to change, 1 to destroy. N'appliquez pas ce plan et ne supprimez pas le rapport pour rendre la destruction possible.

Un bloc moved déclare une relation entre l'ancienne et la nouvelle adresse. Il enregistre une refactorisation de la configuration, à la différence d'un changement du nom du bucket AWS. Placez la déclaration dans un fichier .tf distinct ; Terraform lit ensemble tous les fichiers .tf de cette configuration racine :

cat > moved.tf <<'HCL'
moved {
  from = aws_s3_bucket.reports
  to   = aws_s3_bucket.report_archive
}
HCL

Enregistrez et inspectez le plan corrigé :

terraform plan -out=rename.tfplan

Les résultats attendus sont aws_s3_bucket.reports has moved to aws_s3_bucket.report_archive et 0 to add, 0 to change, 0 to destroy. Le plan prévoit une modification de l'adresse dans l'état, tandis que la ressource AWS n'a pas besoin d'être recréée. Conservez la déclaration avec la configuration afin que les copies plus anciennes de l'état puissent aussi comprendre la refactorisation.

Appliquer la migration d'adresse et préserver le rapport

Dans cette étape, appliquez le plan sûr enregistré et confirmez que seule l'adresse logique a changé. Un plan enregistré s'exécute sans nouvelle demande d'approbation ; confirmez donc d'abord que son récapitulatif ne prévoit aucune création ni destruction.

terraform apply rename.tfplan

Le récapitulatif des ressources doit afficher 0 added, 0 changed, 0 destroyed. Inspectez la correspondance obtenue :

terraform state list
terraform state show aws_s3_bucket.report_archive

Seule la nouvelle adresse figure dans la liste et son identifiant de bucket reste rename-daily-reports. Vérifiez le rapport stocké :

aws s3 \
  cp s3://rename-daily-reports/report.txt -

Le texte d'origine reste Daily sales: 120 orders. AWS View affiche toujours les mêmes buckets de rapports et de finance ; un renommage logique ne doit pas faire apparaître de nouvelle carte de ressource.

terraform plan

Le résultat attendu est No changes. Le contrôle indépendant compare aussi le VersionId d'origine et le stockage voisin, et calcule le plan de la configuration actuelle dans une copie jetable. Laissez les deux rapports opérationnels intacts pour le prochain responsable de maintenance.

Consultez la documentation de HashiCorp sur la refactorisation des ressources pour comprendre le rôle de la conservation des déclarations moved dans l'évolution des modules.

Résumé

Vous avez distingué une adresse Terraform d'un identifiant de ressource AWS, rejeté un plan destructif de renommage direct et appliqué une déclaration moved sans recréer le bucket ni le rapport.