Introduction
Un répartiteur peut éviter une application défaillante, mais ne crée pas son serveur de remplacement. Vous créerez un modèle et un groupe Auto Scaling maintenant deux instances, provoquerez une panne et vérifierez que le nouvel ID répond réellement aux requêtes.
Vous devez connaître EC2 User Data, les groupes cibles ALB et les contrôles de santé. Cet environnement neuf fournit réseau, image, paire de clés et groupe cible vide avec écouteur HTTP, sans flotte existante. La CLI et les fichiers de connexion sont préparés indépendamment des laboratoires précédents.
Liens avec les certifications
Ce laboratoire offre une pratique introductive des thèmes suivants.
- Solutions Architect – Associate (SAA-C03) · Tâche 2.1 : Modèles, capacité Auto Scaling et intégration ALB ; tâche 2.2 : Remplacement des backends défaillants pour soutenir la disponibilité.
- CloudOps Engineer – Associate (SOA-C03) · Tâche 2.1 : Maintien de capacité EC2 ; tâche 2.2 : Identification et remplacement des backends grâce à la santé applicative.
Créer le modèle de lancement
Vous définirez la configuration utilisée par Auto Scaling pour démarrer chaque serveur.
Entrez dans le dossier de travail et chargez les variables réseau :
cd /home/labex/project
source launch.env
Un modèle de lancement contient AMI, type, groupes de sécurité et configuration de démarrage. Examinez le fichier fourni :
cat launch-template.json
cat application-user-data.sh
Le JSON sélectionne l’AMI préparée, t3.micro, report-key et le groupe de sécurité applicatif. UserData contient le script présenté séparément, encodé en base64. Celui-ci initialise le message Application ready et healthy à true. Chaque lancement doit appliquer cette configuration ; une modification dans un ancien serveur ne change pas le modèle.
Créez le modèle. file:// demande à la CLI de lire la valeur du paramètre dans le JSON :
LT_ID=$(aws ec2 \
create-launch-template \
--launch-template-name application-template \
--launch-template-data file://launch-template.json \
--query 'LaunchTemplate.LaunchTemplateId' \
--output text)
Les modèles possèdent des versions numérotées. Examinez la version 1, explicitement utilisée par votre groupe :
aws ec2 \
describe-launch-template-versions \
--launch-template-id "$LT_ID" \
--versions 1 \
--query 'LaunchTemplateVersions[].{Version:VersionNumber,AMI:LaunchTemplateData.ImageId,Type:LaunchTemplateData.InstanceType,Key:LaunchTemplateData.KeyName,Groups:LaunchTemplateData.SecurityGroupIds}'
Créer un modèle ne lance aucune instance. Ouvrez AWS View : ALB et groupe cible existent, mais aucun serveur n’est encore enregistré.
Démarrer et connecter la flotte
Vous créerez un groupe Auto Scaling et connecterez ses véritables instances au répartiteur fourni.
Un groupe Auto Scaling maintient le nombre souhaité entre minimum et maximum. La capacité souhaitée est un nombre d’instances, pas une mesure de débit. Minimum 2, souhaité 2 et maximum 3 permettent deux serveurs au départ et un serveur supplémentaire.
Récupérez l’ARN du groupe cible et le nom DNS du répartiteur :
TG_ARN=$(aws elbv2 \
describe-target-groups \
--names application-targets \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--names application-alb \
--query 'LoadBalancers[0].DNSName' \
--output text)
Créez le groupe avec la version 1 et les deux sous-réseaux. --target-group-arns enregistre automatiquement les instances dans ALB. --health-check-type ELB inclut la santé du répartiteur dans les décisions de remplacement ; EC2 seul ne détecte pas toutes les pannes applicatives. Le délai de grâce laisse démarrer les instances avant un remplacement pour santé applicative. Ici, il vaut 30 secondes ; en production, adaptez-le au démarrage :
aws autoscaling \
create-auto-scaling-group \
--auto-scaling-group-name application-fleet \
--launch-template "LaunchTemplateId=$LT_ID,Version=1" \
--min-size 2 \
--max-size 3 \
--desired-capacity 2 \
--vpc-zone-identifier "$SUBNET_ID,$SECOND_SUBNET_ID" \
--target-group-arns "$TG_ARN" \
--health-check-type ELB \
--health-check-grace-period 30
Examinez le groupe et ses IDs :
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Min:MinSize,Desired:DesiredCapacity,Max:MaxSize,HealthCheck:HealthCheckType,Grace:HealthCheckGracePeriod,Instances:Instances[].InstanceId}'
Attendez la disponibilité des applications, puis examinez les cibles :
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
aws elbv2 \
describe-target-health \
--target-group-arn "$TG_ARN" \
--query 'TargetHealthDescriptions[].{Instance:Target.Id,Health:TargetHealth.State}' \
--output table
Deux IDs doivent être sains. Envoyez six requêtes et comparez les réponses aux instances du groupe :
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Ouvrez AWS View. Confirmez capacité 2, deux cibles saines et réponses réelles 200 des deux IDs avec Send request. Les sous-réseaux et zones indiquent la configuration ; cet exercice ne mesure pas la résilience physique interzone.
Observer le remplacement automatique
Vous provoquerez une panne et laisserez le groupe remplacer l’instance sans réparation manuelle.
Sélectionnez une instance actuelle et récupérez son adresse publique pour SSH :
OLD_ID=$(aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[0].Instances[0].InstanceId' \
--output text)
OLD_IP=$(aws ec2 \
describe-instances \
--instance-ids "$OLD_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
Modifiez seulement healthy pour obtenir 503. Comme précédemment, un JSON temporaire évite d’écraser le fichier pendant sa lecture :
ssh -F ssh_config "ubuntu@$OLD_IP" \
'sudo jq ".healthy = false" /etc/report-app/config.json > /tmp/report-config.json && sudo install -m 644 /tmp/report-config.json /etc/report-app/config.json'
ssh -F ssh_config "ubuntu@$OLD_IP" \
'curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8081/health'
Attendez 503. L’application échoue alors que l’instance fonctionne. ALB détecte les échecs ; après le délai de grâce, le groupe remplace l’instance pour restaurer sa capacité. Le même modèle initialise le remplaçant avec une configuration saine.
Gardez AWS View ouvert pour observer IDs et états. L’état défaillant peut être bref car le remplacement suit la détection ; une nouvelle cible peut apparaître initial. N’effectuez aucune réparation ni commande run-instances supplémentaire.
Attendez la terminaison de l’ancienne instance et les cibles saines :
aws ec2 \
wait instance-terminated \
--instance-ids "$OLD_ID"
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Examinez l’ancienne instance et le groupe actuel :
aws ec2 \
describe-instances \
--instance-ids "$OLD_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].{Desired:DesiredCapacity,Instances:Instances[].InstanceId}'
L’ancien ID doit être terminated. La capacité reste 2, avec un nouvel ID. Le remplaçant est un serveur réinitialisé ; les modifications faites uniquement dans l’ancien ne sont pas conservées automatiquement.
Envoyez à nouveau six requêtes :
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Cherchez les deux IDs actuels, dont le nouveau, sans l’ancien. Dans AWS View, confirmez deux cibles saines et une vraie réponse du remplaçant avec Send request. Le nombre de ressources ne suffit pas à prouver le fonctionnement applicatif.
Exemple : la capacité reste à deux et la nouvelle instance renvoie HTTP 200. Vos IDs seront différents.
Supprimer la flotte et le modèle
Vous supprimerez groupe, instances et modèle tout en conservant ALB et réseau fournis.
Supprimez le groupe avec --force-delete pour terminer ses instances malgré le minimum 2. Supprimer uniquement le modèle n’arrête pas les instances :
aws autoscaling \
delete-auto-scaling-group \
--auto-scaling-group-name application-fleet \
--force-delete
aws ec2 \
wait instance-terminated \
--filters "Name=tag:aws:autoscaling:groupName,Values=application-fleet"
aws ec2 \
delete-launch-template \
--launch-template-id "$LT_ID"
Le waiter sélectionne les instances via l’étiquette automatique Auto Scaling, ancienne instance remplacée comprise, et attend leur terminaison. Vérifiez l’absence du groupe, les modèles et les cibles :
aws autoscaling \
describe-auto-scaling-groups \
--auto-scaling-group-names application-fleet \
--query 'AutoScalingGroups[].AutoScalingGroupName'
aws ec2 \
describe-launch-templates \
--query 'LaunchTemplates[].LaunchTemplateName'
aws elbv2 \
describe-target-health \
--target-group-arn "$TG_ARN" \
--query 'TargetHealthDescriptions[].Target.Id'
Les trois listes doivent être []. Le désenregistrement peut prendre du temps ; attendez et répétez la dernière requête si nécessaire. AWS View conserve ALB et groupe cible sans flotte ni cibles enregistrées. Conservez réseau, AMI et paire de clés fournis.
Résumé
Vous avez créé un modèle versionné et un groupe maintenant deux serveurs réels. Vous avez utilisé les contrôles ALB, provoqué une panne et vérifié qu’un nouvel ID répondait. Enfin, vous avez supprimé groupe, instances et modèle en conservant répartiteur et réseau.
Le prochain laboratoire change la capacité par des politiques simples et teste les limites du groupe.
