Réutiliser et modifier un déploiement d’application

Introduction

Un déploiement d'application peut évoluer sans que chaque modification remplace son instance. Vous allez utiliser un module local fourni, examiner une mise à jour de tag qui conserve la charge de travail, puis publier une nouvelle configuration de démarrage qui la remplace. L'application lit son rapport depuis un stockage externe fourni.

Ce lab suppose la connaissance des bases des appels de modules Terraform, des plans et de l'état, ainsi que des labs précédents sur EC2 et les rôles des charges de travail. Un environnement neuf fournit le déploiement initial, le réseau, l'AMI, le rôle/profil, les rapports privés et l'application de référence. Vous modifierez l'appel du module et observerez l'identité des ressources, les fichiers locaux et les données externes à chaque étape.

Liens avec les certifications

Aperçu du lab

Lire l'interface du module et appliquer une mise à jour

Dans cette étape, vous allez lire les entrées et les sorties du module fourni, modifier son entrée de tag de release et vérifier que l'instance existante et son fichier local restent intacts.

AWS View, dans la partie supérieure, observe les mêmes ressources que Terminal et envoie de véritables requêtes à la charge de travail. Le déploiement du module est déjà en cours d'exécution. Le rôle/profil fourni accorde uniquement la lecture du rapport requis ; le réseau, le rôle et le bucket de rapports restent en dehors du périmètre de gestion de cette configuration racine.

Inspectez l'appel racine et la petite interface du module :

cd /home/labex/project/application-releases
cat application.tf
cat modules/application/variables.tf
cat modules/application/outputs.tf
cat modules/application/main.tf
terraform state list
ORIGINAL_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

source = "./modules/application" sélectionne le répertoire du module local. L'appel transmet les entrées d'infrastructure préparées ainsi que message et release_label. Le module enfant crée la ressource EC2 et sa sortie expose l'identifiant réel de l'instance à travers la sortie racine. Les adresses dans l'état commencent donc par module.application.

Le module associe release_label au tag ReleaseNote. Il insère message dans User Data et active user_data_replace_on_change. Vous modifierez les entrées de l'appelant tout en conservant cette implémentation fournie. Gardez les trois fichiers sous modules/application/ inchangés et utilisez ce module local fourni. Effectuez vos modifications dans l'appel racine.

Dans AWS View, sélectionnez application-server, User · 198.51.100.10, Application · 8081 et Health, puis cliquez sur Send request. Les résultats attendus sont Connected · 200 et Application release one. Choisissez Local report file et envoyez à nouveau une requête : l'instance préparée contient local,existing-record. Choisissez Private report pour lire le rapport S3 distinct, period,total / Q1,320.

Modifiez uniquement l'entrée de tag de initial à reviewed. Cela réécrit le petit appel racine tout en conservant toutes les références d'infrastructure et le message de démarrage :

cat > application.tf <<'HCL'
module "application" {
  source = "./modules/application"
  ami_id = var.ami_id
  subnet_id = var.subnet_id
  security_group_id = var.security_group_id
  profile_name = var.profile_name
  report_bucket = var.report_bucket
  message = "Application release one"
  release_label = "reviewed"
}
output "instance_id" { value = module.application.instance_id }
output "image_id" { value = module.application.image_id }
output "report_bucket" { value = var.report_bucket }
HCL
terraform fmt
terraform validate
terraform plan

Examinez une mise à jour sur place du tag de l'instance du module, sans création ni destruction d'instance. Appliquez et saisissez yes :

terraform apply

Comparez l'identifiant réel et le tag natif :

echo "$ORIGINAL_ID"
terraform output -raw instance_id
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Tags:Tags}'

L'identifiant est inchangé et ReleaseNote vaut reviewed. Dans AWS View, envoyez des requêtes Health et Local report file à la même instance. Son message reste Application release one et son enregistrement local existant est conservé. Une mise à jour de tag ne relance pas l'initialisation au démarrage.

terraform plan

Le résultat attendu est No changes.

Examiner et appliquer le remplacement lié à la configuration de démarrage

Dans cette étape, vous allez modifier le message de démarrage, inspecter un plan de remplacement enregistré et vérifier la nouvelle charge de travail tout en conservant le rapport externe.

Le message fait partie de User Data. Le paramètre user_data_replace_on_change de ce module fait d'une modification de configuration de démarrage un remplacement explicite de l'instance. L'enregistrement local existant appartient au système de fichiers de l'ancienne instance ; le rapport S3 appartient à un stockage fourni séparément.

Modifiez le message de l'appel et enregistrez le plan :

sed -i 's/Application release one/Application release two/' application.tf
terraform fmt
terraform validate
terraform plan -out=release.tfplan
terraform show release.tfplan

Examinez le remplacement -/+ de l'instance et les données User Data modifiées. Le plan ne doit pas détruire le réseau fourni, le rôle, le profil, l'image, le bucket ni l'application de référence. release.tfplan enregistre le plan examiné pour la commande suivante.

Appliquez ce plan enregistré :

terraform apply release.tfplan

L'application d'un plan enregistré ne demande pas une nouvelle saisie de yes ; la commande applique les actions enregistrées. Attendez la fin, puis comparez les deux identités réelles d'instance :

NEW_ID=$(terraform output -raw instance_id)
echo "$ORIGINAL_ID"
echo "$NEW_ID"
aws ec2 \
  describe-instances \
  --instance-ids "$ORIGINAL_ID" "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name,Image:ImageId}'

Les identifiants diffèrent : l'instance d'origine est terminated et la nouvelle est running sur la même AMI préparée. Faites correspondre les identifiants au lieu de vous fier à l'ordre des lignes.

Dans AWS View, sélectionnez l'entrée application-server en cours d'exécution et envoyez Health. Les résultats attendus sont Connected · 200 et Application release two. L'ancienne instance terminée n'est plus une cible en cours d'exécution sélectionnable.

Envoyez Local report file. Son contenu est maintenant local,initialized, créé par User Data dans la nouvelle instance. L'enregistrement local de l'ancienne instance n'a pas été conservé par le remplacement. Envoyez ensuite Private report : le rapport S3 externe renvoie toujours Connected · 200 avec period,total / Q1,320. Envoyez Unrelated private object et attendez Connected · 403 avec Access denied.

Sélectionnez enfin reference-server, User, le port 8081 et Health, puis envoyez une requête. Il doit toujours renvoyer Connected · 200 et Reference application.

terraform plan

Le résultat attendu est No changes. La nouvelle instance est gérée par le module, tandis que les données externes et l'environnement de référence restent intacts.

Détruire la charge de travail du module et garder ses dépendances

Dans cette étape, vous allez supprimer l'instance de remplacement gérée tout en préservant l'infrastructure fournie, le rôle de la charge de travail et les données de rapports externes.

Enregistrez l'identifiant de l'image avant de détruire les ressources gérées par la configuration racine :

IMAGE_ID=$(terraform output -raw image_id)
echo "$IMAGE_ID"
terraform plan -destroy

Une instance gérée doit être à détruire. La source de données AMI lit une image existante ; le réseau, le profil, le rôle et le bucket ont été transmis au module comme entrées fournies. Appliquez la suppression et saisissez yes :

terraform destroy

Interrogez l'état natif de terminaison de l'instance de remplacement et inspectez l'état restant :

aws ec2 \
  describe-instances \
  --instance-ids "$NEW_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
terraform state list

Les résultats attendus sont terminated et aucune instance gérée restante dans l'état. L'image et le profil fournis doivent toujours exister :

aws ec2 describe-images --image-ids "$IMAGE_ID" --query 'Images[].{ID:ImageId,Name:Name}'
aws iam \
  get-instance-profile \
  --instance-profile-name supplied-application-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

Utilisez l'opérateur Terminal pour lire le rapport S3 conservé. Cela contrôle la préservation des données externes ; l'accès limité propre à la charge de travail a été vérifié avant la destruction.

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/g5-retained-report.csv
cat /tmp/g5-retained-report.csv

Ses octets restent period,total / Q1,320. Dans AWS View, sélectionnez reference-server, User, le port 8081 et Health, puis envoyez une requête. Le résultat attendu est Connected · 200 avec Reference application.

Conservez les fichiers racines et ceux du module pour examen. Le HCL conservé proposerait une nouvelle instance lors d'un plan ordinaire ultérieur ; le nettoyage exige la suppression native de la charge de travail gérée, pas un futur plan vide.

Résumé

Vous avez utilisé les entrées et les sorties d'un module fourni pour mettre à jour une charge de travail existante et publier une instance de remplacement. Vous avez examiné l'impact sur les ressources et les données, appliqué un plan enregistré, distingué les fichiers locaux de l'instance des rapports externes conservés et nettoyé uniquement la charge de travail appartenant au module.