Créer et supprimer votre première ressource AWS

Introduction

Votre équipe a besoin d'un stockage privé pour ses rapports. Dans ce lab, vous allez créer un premier bucket avec Terraform, comparer sa configuration avec AWS et l'état Terraform, puis examiner et appliquer sa destruction. Un rapport de référence distinct appartient à une autre équipe et doit rester inchangé.

Vous devez déjà connaître les ressources Terraform, init, plan, apply, l'état et destroy, et savoir modifier des fichiers et interroger S3 avec l'AWS CLI. Terraform, le fournisseur AWS et l'accès par CLI sont prêts. Utilisez Terminal pour les commandes et AWS View pour observer le stockage ; aucun compte AWS personnel ni clé d'accès ne sont nécessaires. Chaque lab démarre de manière indépendante.

Liens avec les certifications

Créer le bucket de rapports

Dans cette étape, vous allez relier une définition de ressource Terraform au compte AWS actuel et créer un bucket privé pour les rapports.

Commencez par entrer dans le répertoire racine préparé et interroger votre région et l'identité de l'appelant. Un répertoire racine est une configuration Terraform indépendante avec son propre état. Le compte de l'appelant indique où s'exécutent les requêtes du fournisseur ; l'ARN identifie l'identité qui les émet.

cd /home/labex/project/first-aws-resource
aws configure get region
aws sts \
  get-caller-identity
terraform version

La région est us-east-1. Terraform indique la version 1.17.2. L'accès préparé pour vous est distinct de tout compte AWS personnel.

Le fichier provider.tf fourni sélectionne le fournisseur AWS en version 6.14.0, configure la connexion préparée et fixe Terraform à la version 1.17.2. Le fournisseur traduit les opérations sur les ressources en requêtes à l'API AWS. Sa configuration est fournie pour vous permettre de vous concentrer sur la gestion des ressources.

Créez main.tf avec la configuration suivante. cat et <<'EOF' écrivent tout ce qui précède le délimiteur de fermeture EOF dans le fichier nommé. aws_s3_bucket est le type de ressource AWS ; reports est le nom local utilisé par Terraform. Ensemble, ils forment l'adresse aws_s3_bucket.reports. L'attribut bucket est le nom du bucket AWS, distinct de cette adresse. Les tags indiquent l'usage de la ressource.

cat > main.tf <<'EOF'
resource "aws_s3_bucket" "reports" {
  bucket = "terraform-first-reports"
  tags = {
    Project = "TerraformReports"
  }
}

output "report_bucket" {
  value = aws_s3_bucket.reports.id
}
EOF

Initialisez cette configuration racine et validez-la :

terraform init
terraform validate

init installe le fournisseur à la version fixée depuis le cache préparé et écrit .terraform.lock.hcl. Conservez ce fichier de verrouillage des dépendances avec la configuration d'un véritable projet : il enregistre le fournisseur choisi et les sommes de contrôle des paquets. Il est distinct de l'état Terraform, qui associe les adresses des ressources aux identifiants des ressources déployées. Le cache étant préparé pour cet environnement Linux, init peut avertir que les sommes de contrôle du fichier de verrouillage ne couvrent que linux_amd64 ; l'initialisation se termine tout de même. Un projet utilisé sur d'autres plateformes doit aussi disposer des sommes de contrôle correspondantes.

Examinez le plan avant de créer quoi que ce soit :

terraform plan

Le résultat attendu est Plan: 1 to add, 0 to change, 0 to destroy. Certains attributs indiquent (known after apply), car AWS les attribue ou les renvoie lors de la création. Confirmez le nom du bucket et le tag du projet. Un plan présente les actions prévues ; il ne crée pas le bucket.

Appliquez la configuration et saisissez yes à la demande de confirmation :

terraform apply

Le résultat attendu est Apply complete! Resources: 1 added, 0 changed, 0 destroyed. La sortie report_bucket vaut terraform-first-reports. Dans AWS View, le nouveau bucket vide apparaît à côté de team-reference-reports. Ne modifiez ni ce bucket de référence ni son objet keep.txt.

Cliquez sur Continue après avoir exécuté les commandes. Le contrôle interroge indépendamment AWS et la correspondance dans l'état ; la réussite d'une commande ne suffit pas à elle seule.

Comparer la configuration, l'état et AWS

Dans cette étape, vous allez relier l'adresse de ressource Terraform au bucket privé existant, puis confirmer que la configuration a convergé.

La sortie lit l'identifiant du bucket à travers une référence de ressource. state list affiche l'adresse gérée ; state show affiche ses attributs enregistrés. Ces commandes inspectent la correspondance sans modifier AWS.

terraform output report_bucket
terraform state list
terraform state show aws_s3_bucket.reports

Repérez aws_s3_bucket.reports et son identifiant terraform-first-reports. Votre configuration exprime la ressource souhaitée, AWS héberge la ressource et l'état relie les deux. Une entrée dans l'état ne prouve pas à elle seule que la ressource existe encore.

Interrogez AWS directement. get-bucket-location renvoie null pour la région S3 us-east-1. L'ACL doit accorder l'accès uniquement à l'utilisateur canonique propriétaire ; aucune autorisation ne doit être accordée à un groupe public. Ce lab crée un bucket privé et n'ajoute pas de stratégie de bucket publique.

aws s3api \
  get-bucket-location \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-acl \
  --bucket terraform-first-reports
aws s3api \
  get-bucket-tagging \
  --bucket terraform-first-reports

Confirmez que le tag Project vaut TerraformReports. Vérifiez que le rapport indépendant reste lisible. L'expression --query sélectionne uniquement sa taille en octets et la commande laisse l'objet stocké inchangé.

aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength
terraform plan

Le plan doit indiquer No changes. Cela signifie que le fournisseur ne détecte aucune modification de configuration pour les ressources gérées. Ce résultat ne prouve pas toutes les propriétés de sécurité possibles et ne valide pas les données du rapport ; ces points nécessitent leurs propres contrôles. Pour en savoir plus, consultez la documentation sur l'état Terraform et le contrôle d'accès S3.

Supprimer uniquement la ressource gérée

Dans cette étape, vous allez examiner et appliquer un plan de destruction, puis prouver que le bucket géré et sa correspondance dans l'état ont disparu, tandis que le rapport de référence est conservé.

terraform plan -destroy présente la suppression prévue des ressources figurant dans l'état de cette configuration racine. Cette commande ne signifie pas « supprimer tous les buckets du compte ». Lisez l'adresse et l'identifiant du bucket avant de poursuivre :

terraform plan -destroy

Le résultat attendu est Plan: 0 to add, 0 to change, 1 to destroy. Le bucket de référence est absent du plan, car cette configuration racine ne le gère pas. Le bucket cible est vide ; les labs suivants expliquent pourquoi les données stockées et les versions exigent des décisions de conservation distinctes.

Détruisez le bucket géré et saisissez yes à la demande de confirmation :

terraform destroy

Le résultat attendu est Destroy complete! Resources: 1 destroyed. Inspectez maintenant l'état et interrogez les buckets restants :

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. terraform-first-reports est absent de la liste des buckets obtenue avec succès ; team-reference-reports et son rapport sont toujours présents. Gardez l'accès AWS configuré jusqu'à la fin du dernier contrôle afin qu'une erreur d'authentification ne puisse pas être confondue avec une suppression réussie. La configuration et le fichier de verrouillage restent disponibles si vous souhaitez recréer la ressource.

Résumé

Vous avez créé un bucket S3 privé avec un fournisseur AWS à version fixée, comparé la configuration et l'état avec des requêtes AWS, vérifié un plan convergent et détruit uniquement la ressource gérée. Le rapport de référence indépendant est resté intact. Dans le prochain lab, vous utiliserez des paramètres d'entrée et des références de ressources pour gérer le contenu des rapports.