Introduction
Votre équipe dispose de deux serveurs applicatifs, mais les clients ont besoin d'une adresse unique. Vous créerez un Application Load Balancer, relierez son listener à un groupe cible et inscrirez les deux serveurs. Les réponses HTTP réelles indiqueront quel serveur traite chaque requête.
Vous devez connaître les instances EC2, les sous-réseaux VPC et les groupes de sécurité des cours précédents. L'environnement fournit le réseau, les serveurs actifs et AWS CLI configuré. Vous créerez les ressources d'équilibrage et les supprimerez à la fin.
Liens avec les certifications
Ce laboratoire propose une première pratique des sujets d'examen suivants.
- Solutions Architect – Associate (SAA-C03) · Tâche 2.1 : Concepts d'Application Load Balancer et répartition des requêtes entre serveurs applicatifs.
- CloudOps Engineer – Associate (SOA-C03) · Tâche 2.2 : Configuration élémentaire d'Elastic Load Balancing et observation de la disponibilité des cibles.
Créer l'Application Load Balancer
Vous allez créer un point d'entrée unique pour les deux serveurs préparés.
Un Application Load Balancer (ALB) distribue les requêtes HTTP ou HTTPS aux serveurs applicatifs. Un Network Load Balancer (NLB) traite les connexions de transport, notamment TCP et UDP ; ALB convient à cette application HTTP. Vous utiliserez ALB dans tout le laboratoire.
Entrez dans le répertoire de travail préparé :
cd /home/labex/project
Le fichier launch.env contient les identifiants du réseau fourni. Lisez-le, puis utilisez source pour charger ses affectations de variables dans votre shell actuel :
cat launch.env
source launch.env
SUBNET_ID et SECOND_SUBNET_ID désignent des sous-réseaux dans deux zones de disponibilité distinctes. ALB nécessite au moins deux sous-réseaux de ce type. ALB_SECURITY_GROUP_ID désigne le groupe préparé autorisant HTTP sur le port 80 ; les serveurs ont un autre groupe pour leur port applicatif.
Créez un équilibreur applicatif accessible depuis Internet nommé application-alb. Accessible depuis Internet décrit son schéma d'adressage. --query sélectionne uniquement l'ARN et --output text facilite sa réutilisation. La syntaxe shell $(...) enregistre la sortie dans LB_ARN :
LB_ARN=$(aws elbv2 \
create-load-balancer \
--name application-alb \
--type application \
--scheme internet-facing \
--subnets "$SUBNET_ID" "$SECOND_SUBNET_ID" \
--security-groups "$ALB_SECURITY_GROUP_ID" \
--query 'LoadBalancers[0].LoadBalancerArn' \
--output text)
Un Amazon Resource Name (ARN) identifie une ressource AWS. Inspectez l'équilibreur à l'aide de l'ARN enregistré :
aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[].{Name:LoadBalancerName,Type:Type,Scheme:Scheme,DNS:DNSName}'
Recherchez application-alb, le type application et le schéma internet-facing. Le nom DNS sera l'adresse des clients ; sa valeur varie selon l'environnement. Créer l'équilibreur ne connecte pas encore les serveurs.
Cliquez sur AWS View à côté de Terminal. La page lit le même état que CLI et doit afficher application-alb. Les zones du groupe cible et des cibles restent vides, car vous ne les avez pas reliées.
La capture illustre cette étape. Le nom correspond au laboratoire ; le nom DNS est un exemple.
Relier un listener à un groupe cible
Vous allez définir la destination des requêtes HTTP entrantes.
Un groupe cible contient les serveurs pouvant servir une application. Son port est celui utilisé pour contacter ces serveurs. Un listener accepte les connexions clientes sur l'équilibreur et choisit la destination via une action. Ici, les clients utilisent le port 80, tandis que l'application écoute sur 8081.
Créez un groupe cible de type instance dans la VPC fournie. --target-type instance signifie que vous inscrirez des IDs EC2. Le chemin /health est l'endpoint de disponibilité de l'application :
TG_ARN=$(aws elbv2 \
create-target-group \
--name application-targets \
--protocol HTTP \
--port 8081 \
--vpc-id "$VPC_ID" \
--target-type instance \
--health-check-path /health \
--query 'TargetGroups[0].TargetGroupArn' \
--output text)
Créez le listener HTTP. Son action par défaut transmet les requêtes à TG_ARN. La notation CLI Type=forward,TargetGroupArn=... définit cette action :
LISTENER_ARN=$(aws elbv2 \
create-listener \
--load-balancer-arn "$LB_ARN" \
--protocol HTTP \
--port 80 \
--default-actions "Type=forward,TargetGroupArn=$TG_ARN" \
--query 'Listeners[0].ListenerArn' \
--output text)
Inspectez le listener créé :
aws elbv2 \
describe-listeners \
--load-balancer-arn "$LB_ARN" \
--query 'Listeners[].{Protocol:Protocol,Port:Port,Actions:DefaultActions}'
La sortie doit montrer HTTP sur le port 80 et une action de transfert vers votre groupe. Dans AWS View, le groupe apparaît entre l'ALB et les serveurs. Aucune cible n'est encore inscrite ; vous devez connecter les serveurs.
Inscrire et tester les deux serveurs
Vous allez inscrire deux serveurs actifs et observer de vraies requêtes atteignant chacun d'eux.
Listez les serveurs préparés. Le filtre de noms sélectionne leurs tags et la requête affiche les champs utiles à la connexion :
aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-a,app-b' \
--query 'Reservations[].Instances[].{Instance:InstanceId,Name:Tags[?Key==`Name`].Value|[0],State:State.Name,PrivateIP:PrivateIpAddress}' \
--output table
Les deux instances doivent être running. Récupérez leurs IDs séparément par nom pour ne pas dépendre de l'ordre de la liste :
APP_A=$(aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-a' \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
APP_B=$(aws ec2 \
describe-instances \
--filters 'Name=tag:Name,Values=app-b' \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Inscrire les cibles relie ces IDs au groupe. Sans remplacement explicite par Port, chaque cible utilise le port applicatif 8081 du groupe :
aws elbv2 \
register-targets \
--target-group-arn "$TG_ARN" \
--targets "Id=$APP_A" "Id=$APP_B"
L'ALB interroge /health pour déterminer la disponibilité. Attendez que les contrôles signalent des cibles saines. Un waiter CLI répète des requêtes en lecture seule jusqu'à satisfaire la condition ou expirer :
aws elbv2 \
wait target-in-service \
--target-group-arn "$TG_ARN"
Inspectez les IDs, les ports et les états de santé des cibles inscrites :
aws elbv2 \
describe-target-health \
--target-group-arn "$TG_ARN" \
--query 'TargetHealthDescriptions[].{Instance:Target.Id,Port:Target.Port,Health:TargetHealth.State}' \
--output table
Les deux cibles doivent afficher le port 8081 et l'état healthy. Enregistrez le nom DNS de l'équilibreur :
LB_DNS=$(aws elbv2 \
describe-load-balancers \
--load-balancer-arns "$LB_ARN" \
--query 'LoadBalancers[0].DNSName' \
--output text)
Utilisez curl, un client HTTP, pour interroger l'endpoint de santé. --config client.conf lit les paramètres fournis ; -sS masque la progression tout en affichant les erreurs :
curl --config client.conf -sS "http://$LB_DNS/health"
Une réponse réussie ressemble à cet exemple ; l'ID d'instance est illustratif :
{"service":"Report server","message":"Application ready","instance_id":"i-..."}
Envoyez six requêtes distinctes. La boucle for répète la requête et echo place chaque réponse sur une nouvelle ligne :
for request in 1 2 3 4 5 6; do
curl --config client.conf -sS "http://$LB_DNS/health"
echo
done
Recherchez les valeurs de APP_A et APP_B dans les réponses. Cela prouve la répartition entre deux serveurs ; le nombre de requêtes ne mesure ni performance ni capacité. L'algorithme par défaut est round robin. En production, les connexions et d'autres réglages peuvent aussi influencer la répartition.
Ouvrez AWS View et confirmez que les deux cibles sont saines. Cliquez plusieurs fois sur Send request et lisez instance_id. La requête traverse le listener jusqu'à l'application ; les cartes montrent les ressources, tandis que la réponse identifie le serveur qui l'a réellement traitée.
Cet exemple montre deux cibles saines et une requête réussie. Vos IDs seront différents ; comparez la réponse à vos propres cibles.
Supprimer les ressources d'équilibrage
Vous allez supprimer vos ressources tout en conservant les serveurs et le réseau fournis.
Supprimez d'abord le listener pour retirer la dépendance de transfert vers le groupe :
aws elbv2 \
delete-listener \
--listener-arn "$LISTENER_ARN"
Supprimez votre équilibreur, puis son groupe cible :
aws elbv2 \
delete-load-balancer \
--load-balancer-arn "$LB_ARN"
aws elbv2 \
delete-target-group \
--target-group-arn "$TG_ARN"
Confirmez que les deux inventaires d'équilibrage sont vides :
aws elbv2 \
describe-load-balancers \
--query 'LoadBalancers[].LoadBalancerName'
aws elbv2 \
describe-target-groups \
--query 'TargetGroups[].TargetGroupName'
Chaque requête doit renvoyer []. AWS View doit montrer qu'il n'y a ni équilibreur ni groupe cible. Les instances EC2 fournies restent actives ; ce sont des ressources de préparation, exclues de votre nettoyage.
Résumé
Vous avez créé un Application Load Balancer, relié un listener HTTP à un groupe et inscrit deux serveurs EC2. Vous avez inspecté leur santé et identifié les deux serveurs grâce aux réponses réelles. Enfin, vous avez supprimé vos ressources d'équilibrage et conservé les serveurs et le réseau préparés.
Le prochain laboratoire explique comment les contrôles de santé détectent une panne, maintiennent le trafic sur les cibles saines et réintègrent une cible rétablie.
