Formation DevOps | Formation AWS Services : Workshop LoadBalancer
AWSDEV – WORKSHOP
AMAZON AUTO SCALING GROUP
Procédure de connexion : Si vous n’avez pas de compte AWS
- Se connecter à la console à l’URL suivante :
-
S’authentifier avec le compte IAM
- Nom d’utilisateur et mot de passe : remis par le formateur
AUTO SCALING : GETTING START
Objectifs :
- Créer un ALB internet-facing et le paramétrer
- Créer un Auto Scaling Group et l’associer à un Target Group
- Créer une Launch Configuration pour des instances qui s’auto-configurent (user-data)
- Utiliser des Scaling Policies pour réagir dynamiquement à des franchissements de seuils
Dans ce workshop, il s’agit de déployer une infrastructure Web hautement-disponible et élastique.
Un CLB distribue du trafic dans plusieurs AZs, vers des instances dont la gestion est confiée à un Auto Scaling Group (voir ci-contre). Les instances s’auto-configurent au lancement.
Une alarme CloudWatch sert de déclencheur pour démarrer ou stopper des instances, en se basant sur la moyenne de consommation CPU de l’ensemble des instances.
Nous commençons par créer un CLB avec un Target Group qui sera associé à notre Auto Scaling Group.
Dans le menu Services > EC2 > Load Balancers, cliquer sur « Create Load Balancer » :
Choisir la version « Classic Load Balancer », et dans le second écran, saisir les informations demandées :
Dans la Step 2, créer un Security Group pour l’CLB en indiquant, dans la règle de flux entrant pour HTTP, l’adresse de sortie de votre réseau d’entreprise pour les flux Web :
Cliquer sur « Next : Configure Security Settings ». Dans la Step 3, ignorer le warning relatif à l’utilisation recommandé de HTTPS (inutile dans le cadre de ce workshop).
Step4 Configurer le heathcheck
La Step 5 permet d’enregistrer auprès du Target Group des instances qui seraient déjà prêtes à prendre du trafic.
Nous n’en sommes pas à ce stade, cliquer sur « Next : Review » puis sur « Create ».
Au préalable, nous allons créer le Security Group des futures instances Web, en précisant que l’CLB peut s’y connecter sur le port HTTP, ainsi que notre poste client (à des fins de tests). Dans le menu EC2 > Security Groups, créer ceci :
Pour créer l’Auto Scaling group, aller dans le menu EC2 > Auto Scaling Groups et cliquer sur « Create Auto Scaling Group » :
![][image14]
Cliquer sur « Create a launch template » pour définir le profil des instances à créer :
Sélectionner une instance type t2.micro puis dans la Step 3, saisir les informations suivantes :
Ensuite la paire de clé pour la connections ssh :
Sélectionner le Security Group créé plus tôt dans le workshop puis cliquer sur « Review » et « Create launch configuration ».
Dans details avancé :
![][image19]
Insérer le user-data ci-dessous, qui permettra d’autoconfigurer les instances au démarrage (installation d’un server web) :
![][image20]
#!/bin/bash
# Install apache, php and stress tool
yum -y install epel-release
amazon-linux-extras install epel
yum -y install httpd php stress
# Start web server
systemctl enable httpd.service
service httpd start
# Create stress and relax web page
cat <<EOF > /var/www/html/index.php
<?php
\$output = shell_exec(‘hostname -f’);
echo “<pre>Hi there, I am instance with internal DNS address \$output</pre>”;
if (\$_GET[‘run’]) {
# This code will run if ?run=true is set.
exec("/usr/bin/stress -c 4");
}
if (\$_GET[‘relax’]) {
# This code will run if ?run=true is set.
exec("/usr/bin/killall stress");
}
?>
<a href="?run=true">Stress Me!</a>
<br>
<a href="?relax=true">Relax Me!</a>
EOF
Nous sommes prêts à enchainer avec la création de l’Auto Scaling Group.
Préciser dans la Step 1 les paramètres suivants :
Au cours de la Step 2, nous allons préciser 2 Scaling Policies :
- Une qui précise dans quel contexte ajouter automatiquement des instances
- Une seconde qui précise quand il est nécessaire de réduire le nombre d’instances
Faut faire attention au niveau de security group .
Indiquer les dimensions minimales et maximales de l’Auto Scaling group :
Yes Disable Scale
Cliquer ensuite sur « Ajouter des notifications » pour la première policy et renseigner ces paramètres :
Cliquer sur « Create Alarm ». De retour dans la première fenêtre, préciser l’action à prendre :
Cliquer sur « Next : Configure Notification » puis sur « Next : Configure Tags » :
Cliquer sur « Review » puis sur « Create Auto Scaling group ».
Le tableau suivant récapitule la stratégie de scaling que nous voulons mis en œuvre :
CPU AVG | 0 à 10% | 41% à 89% | 90% à 100% |
---|---|---|---|
Sale out | N/A | N/A | Ajouter 1 instances |
Scale in | Supprimer 1 instance | N/A | N/A |
On peut consulter les actions du groupe dans son panneau d’activité (Menu > EC2 > Auto Scaling Groups > aws-formation-autoscaling > Panneau « Activity History ») :
Une seule instance a été démarrée pour le moment, ce qui correspond à la valeur « Desired » de l’Auto Scaling group.
Pour terminer de paramétrer l’Auto Scaling group, nous allons préciser la politique de suppression d’instances (sur quel critère choisir une instance lorsqu’il faut réduire le nombre).
Faut aller à la list du group auto scaling :
Sélectionner le vôtre ensuite : Modifier mise à l’échelle automatique en cliquant sur create dynamic scaling policy :
Cliquez sur créer une Alarme après sélectionnez une métrique : vous choisissez le CPUtilization dans le auto scaling groupe :
Terminer en cliquant sur « Save ».
Dans la suite du workshop, nous allons simuler une charge CPU sur les instances afin d’observer comment réagit l’Auto Scaling Group.
Au préalable on peut observer l’état des alarmes dans CloudWatch (Menu CloudWatch > Alarms) :
A cet instant, l’alarme de Scale-In est déclenchée car la CPU Utilization est inférieure à 40%. CloudWatch ordonne à l’Auto Scaling Group de supprimer des instances, mais comme la dimension de l’Auto Scaling Group est au minimum de 1, l’ordre est ignoré.
Pour faire monter la CPU de la première instance à 100%, s’y connecter avec un navigateur Web (directement, sans passer par l’CLB) et cliquer sur le bouton « Stress Me ! » :
On peut observer dans CloudWatch que la métrique CPUUtilization augmente :
La moyenne CPU pour le groupe atteint les 100%. Compte-tenu de la policy de Scale-Out, cela entraîne la création d’une nouvelle instance, que l’on peut observer dans le panneau « Activity History » de l’Auto Scaling group.
On peut également observer que ces 2 instances se sont correctement associées au Target Group de l’CLB (Status = healthy) :
Pour s’assurer que le trafic est distribué, se connecter à l’endpoint de l’CLB à l’aide d’un navigateur (le nom DNS est indiqué dans le panneau de description de l’CLB) :
A chaque rechargement de la page depuis le navigateur, on observe bien la distribution alternative vers les 2 instances (l’affichage de la page web indique le hostname privé de l’instance de backend).
Poursuivons le workshop en faisant varier la charge CPU sur le groupe.
Connectez-vous avec un navigateur Web à la seconde instance créée (attaquer l’adresse IP de l’instance, ne pas passer par l’CLB), puis stressez-là.
Lorsque la moyenne CPU pour le groupe atteint les 100%, la policy de Scale-Out se déclenche en provoquant la création d’une 3eme instance.
Lorsque la 3eme instance est en ligne, on observe que la moyenne CPU pour le groupe descend à 66% (en effet, 2 instances sur 3 consomment 100%). Le tableau ci-dessous rappelle la stratégie de scaling, qui ne prévoit aucune action dans l’intervalle 41% - 89%.
CPU AVG | 0 à 40% | 41% à 89% | 90% à 100% |
---|---|---|---|
Sale out | N/A | N/A | Ajouter 1 instances |
Scale in | Supprimer 1 instance | N/A | N/A |
Nous allons solliciter la policy de Scale-In en faisant descendre la moyenne CPU du groupe en dessous de 40%. Pour cela, cliquer sur le bouton « Relax Me ! » d’une des 2 instances. Quelques instants plus tard, la moyenne se stabilise à 33%, ce qui entraîne l’arrêt d’une instance.
Le groupe se stabilise à 2 instances, avec une consommation CPU moyenne de 50%.
Cliquez sur le bouton « Relax Me ! » de la dernière instance qui consommait : la moyenne CPU descend à 0, ce qui entraîne à nouveau l’arrêt d’une instance.
Le groupe finit par se stabiliser à son minimum, soit une seule instance.
Terminer le workshop :
- Terminer l’Auto Scaling group (cela entrainera automatiquement l’arrêt de l’instance restante)
- Supprimer la Launch Configuration
- Supprimer l’ALB
- Supprimer le target group
Decouvrez plus d’Offres de la plateform ItGalaxy.io :
Découvrez notre gamme complète de services et formations pour accélérer votre carrière.
1. Nous contactez
- Description: Besoin de Formation et des Solutions cloud complètes pour vos applications
- Links:
2. Infra as a Service
- Description: Infrastructure cloud évolutive et sécurisée
- Links:
3. Projets Développeurs
- Description: Découvrez des opportunités passionnantes pour les développeurs
- Links:
4. Développeurs
- Description: Rejoignez notre communauté de développeurs
- Links:
5. Formations Complètes
- Description: Accédez à des formations professionnelles de haute qualité
- Links:
6. Marketplace
- Description: Découvrez notre place de marché de services
- Links:
7. Blogs
- Description: Découvrez nos blogs
- Links:
- comment creer une application mobile ?
- Comment monitorer un site web ?
- Command Checkout in git ?
- Comment git checkout to commit ?
- supprimer une branche git
- dockercoin
- kubernetes c est quoi
- architecture kubernetes
- Installer Gitlab Runner ?
- .gitlab-ci.yml exemples
- CI/CD
- svelte 5 vs solid
- svelte vs lit
- solidjs vs qwik
- alpine vs vue
- Plateform Freelance 2025
- Creation d’un site Web gratuitement
This website is powered by ItGalaxy.io