Placer une ressource existante sous gestion

Introduction

Vous reprenez un bucket de rapports opérationnel créé en dehors de Terraform. Placez-le sous gestion sans le recréer ni réécrire son rapport. Examinez ensuite un léger ajustement de configuration et appliquez-le en laissant inchangé le stockage voisin de l'équipe finance.

Vous devez déjà connaître la configuration Terraform, les adresses de ressources, init, plan, apply et l'état local, ainsi que les opérations élémentaires sur les objets S3. Terraform, son fournisseur AWS, la configuration d'accès et deux buckets de rapports indépendants sont préparés dans cet environnement neuf. Aucun compte AWS personnel ni ressource d'un lab précédent ne sont nécessaires.

Liens avec les certifications

Aperçu du lab

Inspecter le stockage existant et la configuration souhaitée

Dans cette étape, comparez la ressource qui existe déjà dans AWS avec la configuration que vous allez gérer. AWS View, au-dessus de Terminal, affiche les mêmes ressources S3 que celles lues par votre CLI. Développez report.txt dans la carte handover-daily-reports pour consulter les données du rapport ; finance-reference-reports appartient à une autre équipe et doit rester inchangé.

Une adresse de ressource Terraform, telle que aws_s3_bucket.reports, identifie un bloc de configuration. Le nom du bucket identifie la ressource AWS distante. L'état enregistre la correspondance entre ces deux identités. Un fichier de configuration ne suffit pas à établir cette correspondance.

Entrez dans le répertoire racine préparé et lisez la configuration souhaitée pour le bucket :

cd /home/labex/project/report-storage
cat main.tf

L'argument bucket sélectionne handover-daily-reports. Owner doit rester à reporting ; le nouveau tag ManagedBy indiquera la prise en charge. force_destroy = false empêche Terraform de vider automatiquement un bucket non vide lors d'une destruction ultérieure. Il s'agit d'un paramètre de comportement de Terraform, distinct du rapport stocké dans le bucket.

Inspectez les tags existants :

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Au départ, seul Owner=reporting existe. Récupérez le rapport d'origine sur la sortie standard en utilisant - comme destination :

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

Rapport attendu :

Daily sales: 120 orders

Initialisez le répertoire de travail. init installe le fournisseur à la version fixée pour cette configuration racine ; il n'importe ni ne crée le bucket :

terraform init

Inspectez les actions proposées sans les appliquer :

terraform plan

Le plan propose 1 to add, car cette configuration racine ne possède pas encore de correspondance pour la ressource gérée. Le bucket existe déjà ; cela révèle l'absence de prise en charge dans l'état et n'autorise pas à remplacer le stockage. N'appliquez pas ce plan de création. L'étape suivante établit explicitement la correspondance.

Avant de poursuivre, confirmez manuellement que vous savez identifier le bucket de rapports, lire son rapport et le distinguer du stockage de la finance. Le contrôle en arrière-plan de cette étape d'inspection vérifie la préservation des ressources fournies, pas votre compréhension du plan affiché.

Importer le bucket existant et examiner la différence

Dans cette étape, associez le bucket existant à l'adresse Terraform prévue. La commande CLI import lit une ressource distante et enregistre son identité dans l'état. Elle ne génère pas la configuration souhaitée et n'importe pas tous les objets du bucket.

Lancez l'import en plaçant d'abord l'adresse de configuration, puis le nom du bucket existant :

terraform import aws_s3_bucket.reports handover-daily-reports

Repérez Import successful!. Vérifiez quelle adresse est désormais gérée :

terraform state list

Adresse attendue :

aws_s3_bucket.reports

Lisez ses attributs :

terraform state show aws_s3_bucket.reports

Les attributs id et bucket doivent tous deux identifier handover-daily-reports. report.txt reste stocké dans S3 ; importer un bucket ne prend pas en charge l'objet à une adresse aws_s3_object distincte. Le bucket de la finance ne doit pas apparaître dans l'état de cette configuration racine.

L'import ne garantit pas que le plan sera immédiatement vide. Certains paramètres proviennent du service distant ; d'autres, dont force_destroy, décrivent le comportement propre de Terraform et peuvent nécessiter un ajustement de configuration après l'import. Une telle différence ne signifie pas que votre rapport a été endommagé.

Enregistrez un plan pour l'examiner. -out=handover.tfplan enregistre les actions prévues afin que l'étape suivante puisse appliquer ce même plan après examen :

terraform plan -out=handover.tfplan

Lisez le plan enregistré :

terraform show handover.tfplan

Vous devez voir une mise à jour sur place (~), l'ajout du tag ManagedBy=Terraform et, éventuellement, l'ajustement de force_destroy à false. Le récapitulatif doit être :

Plan: 0 to add, 1 to change, 0 to destroy.

Si le plan propose une suppression, un remplacement, une création, un nom de bucket différent ou des modifications du stockage de la finance, arrêtez-vous et vérifiez le répertoire racine, l'adresse de ressource et l'identifiant d'import. Ne résolvez pas un plan inattendu en supprimant le rapport existant.

Appliquer l'ajustement et confirmer la préservation

Dans cette étape, appliquez uniquement le plan que vous avez examiné et prouvez que le rapport d'origine est conservé. Fournir un plan enregistré à apply exécute directement ce plan, sans seconde demande d'approbation. Ne lancez cette commande qu'après avoir confirmé que le récapitulatif de l'étape précédente ne prévoit aucune création ni destruction :

terraform apply handover.tfplan

Le résultat attendu est Resources: 0 added, 1 changed, 0 destroyed. Le bucket est désormais géré et le tag de prise en charge correspond à la configuration.

Lisez les tags actuels pour vérifier le résultat dans AWS :

aws s3api \
  get-bucket-tagging \
  --bucket handover-daily-reports

Owner=reporting et ManagedBy=Terraform doivent tous deux être présents ; l'ordre des tags n'a pas d'importance.

Lisez à nouveau le rapport :

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

Il doit toujours contenir Daily sales: 120 orders. Dans AWS View, développez les deux rapports et confirmez que le contenu du rapport et la référence de la finance restent disponibles. Un ajustement de tag ne nécessite ni nouveau bucket ni réécriture d'objet.

Vérifiez la convergence entre la configuration actuelle, l'état et la ressource AWS actualisée :

terraform plan

Résultat attendu :

No changes. Your infrastructure matches the configuration.

Un plan sans modification ne suffit pas à prouver une prise en charge sûre : vous avez aussi vérifié l'adresse de ressource prévue et les données d'origine, tandis que le contrôle en arrière-plan compare la version d'origine de l'objet et le stockage voisin, et calcule le plan de la configuration actuelle dans une copie jetable pour confirmer la convergence. Conservez les deux buckets pour cette prise en charge. N'exécutez pas terraform destroy : le rapport est toujours utilisé. Lors d'une véritable passation, protégez l'état comme des données opérationnelles sensibles et organisez l'accès du prochain responsable de maintenance ; ne versionnez pas l'état ni des plans enregistrés contenant des valeurs sensibles dans un dépôt public.

Pour en savoir plus, consultez le processus d'import par CLI de HashiCorp.

Résumé

Vous avez comparé un bucket existant avec la configuration Terraform, importé son identité à l'adresse prévue dans l'état et examiné un ajustement non destructif avant de l'appliquer. Vous avez confirmé un plan sans modification tout en préservant le rapport d'origine et le stockage de la finance. L'import établit la gestion ; l'examen de la configuration détermine ce que Terraform doit modifier ensuite.