Paramétrer un stockage privé de rapports

Introduction

Votre équipe a besoin de stockages de rapports pour le développement et la prévisualisation, avec des contenus différents. Vous allez réutiliser une configuration, suivre les références du bucket vers l'objet et prouver que deux configurations racines indépendantes gèrent des ressources AWS différentes.

Appuyez-vous sur le premier lab Terraform sur AWS et sur vos connaissances des variables et des sorties. Les outils, l'accès et la connexion du fournisseur sont prêts ; aucune ressource d'une VM précédente n'est réutilisée.

Liens avec les certifications

Déployer le stockage de développement

Dans cette étape, vous allez utiliser des variables d'entrée et une référence de ressource pour créer un stockage de rapports de développement à partir d'une configuration.

Les deux configurations racines préparées, report-dev et report-preview, sont initialement vides à l'exception du fichier de connexion du fournisseur. Chacune conservera son propre état local. Cela diffère d'un changement des entrées dans une seule configuration racine : celle-ci continue de gérer les ressources déjà enregistrées dans son état.

Entrez dans le répertoire racine de développement et créez le modèle de ressources. Les variables environment et report sont des entrées de type chaîne. ${var.environment} insère le nom de l'environnement dans le nom du bucket. L'argument bucket de l'objet référence l'identifiant de la ressource bucket ; Terraform peut ainsi découvrir la dépendance et créer le bucket en premier. content_type indique aux lecteurs comment interpréter les octets.

cd /home/labex/project/report-dev
cat > main.tf <<'EOF'
variable "environment" { type = string }
variable "report" { type = string }

resource "aws_s3_bucket" "reports" {
  bucket = "terraform-reports-${var.environment}"
  tags = {
    Project     = "TerraformReports"
    Environment = var.environment
  }
}

resource "aws_s3_object" "report" {
  bucket       = aws_s3_bucket.reports.id
  key          = "reports/current.csv"
  content      = var.report
  content_type = "text/csv"
}

output "bucket_name" { value = aws_s3_bucket.reports.id }
output "report_key" { value = aws_s3_object.report.key }
EOF

Créez un fichier de variables pour cet environnement. La séquence d'échappement \n représente un saut de ligne dans la chaîne du rapport. Séparer les valeurs permet de réutiliser le même modèle de ressources.

cat > dev.tfvars <<'EOF'
environment = "dev"
report      = "orders,12\n"
EOF

Initialisez, validez et examinez cette configuration racine. -var-file sélectionne le fichier de valeurs ; cette option ne sélectionne pas un état différent.

terraform init
terraform validate
terraform plan -var-file=dev.tfvars

Deux ressources doivent être ajoutées : le bucket et son objet de rapport. Appliquez les mêmes entrées et saisissez yes à la demande de confirmation :

terraform apply -var-file=dev.tfvars

Les sorties identifient le bucket et la clé de l'objet. Enregistrez et affichez ces valeurs avec $(...), qui capture la sortie d'une commande. -raw affiche une sortie de type chaîne sans les guillemets de Terraform.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
KEY=$(terraform output -raw report_key)
echo "$KEY"

Lisez le rapport réellement stocké via AWS, au lieu de considérer une sortie ou une entrée dans l'état comme une preuve des données. La réponse contient ContentType: text/csv ; le fichier de destination contient les octets.

aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key "$KEY" \
  dev-downloaded.csv
cat dev-downloaded.csv

Le résultat attendu est orders,12. AWS View permet aussi de développer reports/current.csv dans terraform-reports-dev. Laissez le rapport de référence distinct de l'équipe inchangé.

Réutiliser le modèle avec un état distinct

Dans cette étape, vous allez déployer le même modèle avec les entrées de prévisualisation tout en conservant le stockage de développement.

Copiez uniquement le modèle de ressources dans le répertoire racine de prévisualisation préparé. Dans cet exercice, copiez seulement main.tf, car chaque configuration racine préparée sera initialisée séparément. Ne clonez pas terraform.tfstate ni le répertoire .terraform/ initialisé pour créer un autre environnement : ils peuvent transporter la correspondance d'origine avec les ressources ou le backend. Le fichier de verrouillage des dépendances .terraform.lock.hcl est différent : il enregistre les versions des fournisseurs et leurs sommes de contrôle, peut être partagé ou versionné avec la configuration et ne contient aucune correspondance avec les ressources d'un environnement. Le répertoire racine de prévisualisation possède déjà son propre fichier de connexion du fournisseur.

cp /home/labex/project/report-dev/main.tf /home/labex/project/report-preview/main.tf
cd /home/labex/project/report-preview
cat > preview.tfvars <<'EOF'
environment = "preview"
report      = "orders,25\n"
EOF

Initialisez cette configuration racine et examinez le plan de prévisualisation :

terraform init
terraform plan -var-file=preview.tfvars

Deux ajouts sont à nouveau attendus, avec terraform-reports-preview comme nom de bucket. Une suppression inattendue du bucket de développement indiquerait que vous avez réutilisé le mauvais état. Appliquez et saisissez yes :

terraform apply -var-file=preview.tfvars

Lisez la sortie et le rapport de prévisualisation. L'entrée d'environnement modifie le nom et le tag ; l'entrée de rapport modifie les octets réellement stockés.

BUCKET=$(terraform output -raw bucket_name)
echo "$BUCKET"
aws s3api \
  get-object \
  --bucket "$BUCKET" \
  --key reports/current.csv \
  preview-downloaded.csv
cat preview-downloaded.csv

Le résultat attendu est orders,25. Comparez les sorties et les listes d'état des deux configurations racines avec l'option globale -chdir de Terraform, qui exécute la commande dans un répertoire racine nommé sans changer le répertoire de votre shell :

terraform -chdir=/home/labex/project/report-dev output bucket_name
terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview output bucket_name
terraform -chdir=/home/labex/project/report-preview state list

Les deux configurations racines possèdent des adresses telles que aws_s3_bucket.reports, mais chacune correspond à un bucket AWS différent. Confirmez que les données de développement sont restées intactes :

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

Le résultat attendu est orders,12. Il s'agit d'états locaux indépendants, pas de workspaces ni d'un backend partagé. La documentation des variables d'entrée Terraform explique plus en détail la sélection des fichiers de variables.

Supprimer les deux stockages créés

Dans cette étape, vous allez détruire les ressources de chaque configuration racine sans supprimer le rapport de référence de l'équipe.

Chaque configuration racine a besoin de ses propres entrées lors de la destruction. Examinez le plan de suppression du développement, puis lancez la destruction et saisissez yes. L'objet est supprimé avant son bucket, car Terraform connaît leur dépendance.

terraform -chdir=/home/labex/project/report-dev plan -destroy -var-file=dev.tfvars
terraform -chdir=/home/labex/project/report-dev destroy -var-file=dev.tfvars

Supprimez maintenant uniquement les ressources de la configuration racine de prévisualisation, en confirmant à nouveau avec yes :

terraform -chdir=/home/labex/project/report-preview destroy -var-file=preview.tfvars

Chaque destruction indique deux ressources supprimées. Vérifiez que les deux correspondances sont vides et que le rapport de référence indépendant existe toujours :

terraform -chdir=/home/labex/project/report-dev state list
terraform -chdir=/home/labex/project/report-preview state list
aws s3api \
  list-buckets \
  --query 'Buckets[].Name'
aws s3api \
  head-object \
  --bucket team-reference-reports \
  --key keep.txt \
  --query ContentLength

Seul le bucket de référence reste présent. Une liste obtenue avec succès après authentification prouve l'absence ; un échec d'accès ou de réseau ne la prouverait pas. Conservez les identifiants préparés jusqu'à la fin du contrôle final.

Résumé

Vous avez réutilisé un modèle de bucket et d'objet avec deux fichiers de variables, lu les octets réels des rapports et leur Content-Type, maintenu l'indépendance de l'état de chaque configuration racine et supprimé uniquement vos deux environnements.