TP services réseaux

Load Balancing HAProxy et Docker

1) Pour commencer nous allons installer une machine virtuelle Debian minimale avec connectivité
internet et un accès SSH depuis la machine hôte.

2) Depuis le terminal, Installation de Docker dans cette machine

2.1)) Mettons à jour la machine virtuelle avec la commande : apt-get update

2.2) Installons les dépendances : apt-get install apt-transport-https ca-certificates curl gnupg2 software-
properties-common

2.3) Ensuite téléchargeons docker via le lien

curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add –

après mettons le cache du dépôt à jour

2.4) add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/debian \
$(lsb_release -cs) \
stable"

2.5) Mise à jour du cache des dépôts : apt-get update

2.6) Maintenant nous pouvons installer docker et containerd : apt-get install docker-ce docker-ce-cli
containerd.io

2.7) Vérifions l’installation de docker : docker run hello-world

2.8) Installons maintenant docker-compose : curl -L
"https://github.com/docker/compose/releases/download/1.25.4/docker-compose-$(uname -s)-$(uname -
m)" -o /usr/local/bin/docker-compose
2.9) Mettre les bons droits à l’exécutable : chmod +x /usr/local/bin/docker-compose

2.10) Faisons un lien symbolique dans le PATH pour pouvoir exécuter le binaire :
ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

2.11) Vérifions maintenant l’installation de docker-compose : docker-compose --version

3) Installation de l’infrastructure

3.1) Extrayons le contenu de l’archive fournie pour le TP en installant, si ce n’est pas fait, git sur notre
machine pour aller chercher et extraire cette archive qui nous est fournie :
apt- get install git
git clone https://github.com/JCdrd/TP_HA.git

3.2) Lisons le fichier de configuration docker-compose : docker-compose config docker-config.yml

3.3) Lançons l’infrastructure : docker-compose up
Nous pouvons remarquer qu’il fonctionne normalement. A partir de là, nous allons ouvrir un autre
terminal pour continuer.

3.4) Vérification de la liste des images docker présentent sur la VM : docker images

3.5) Vérifions également la liste des conteneurs qui fonctionnent : docker ps

3.6) Vérifions la liste des réseaux internes docker : docker network ls

3.7) Installons le paquet apache bench (outil des serveurs web) : apt-get install apache2-utils

3.8) Lançons un bench apache pour voir le temps de réponse : ab -n 10000 -c 30 http://192.168.0.33/
3.9) Dans un premier temps, il nous renvoi les informations sur le serveur (version d’apache, adresse IP et
port utilisé).
Ensuite les informations sur ce qui a été envoyé pour le bench (temps mit, nombre total de requêtes,
requêtes ayant marché ou pas), suivi du nombre de requêtes par seconde etc. enfin nous voyons un
classement des requêtes en fonction de leur temps d’émission. On voit que 100% des requêtes ont mis
313 ms à arriver (la plus longue des requêtes.
Nous pouvons observer qu’Apache est capable de récupérer un grand nombre de requêtes (10000 dans
notre cas en un temps bref autrement dit il est opérationnel.

3.10) Maintenant simulons plusieurs visites consécutives sur l’infrastructure web :

for i in {1..50}; do curl 192.168.0.33:80; done
Nous remarquons que les serveurs Apache 1 & 2 répondent et c’est le serveur Apache 2 qui répond en 1er.
On a simulé des visites pour comprendre qu’une fois sur deux, les requêtes sont dirigées sur un serveur
différent (load balancing = on reparti les taches).

3.11) Eteignons un des serveur web de backend : docker stop 1

3.12) Resimulons des visites sur l’infrastructure d’hébergement web :

for i in {1..50}; do curl 192.168.0.33:80; done

Nous remarquons que les deux serveurs Apache marchent chacun de leur tour en commençant par le
serveur 2

3.13) Eteignons le second serveur web : docker stop haproxy_apache_con_2

3.14) Resimuler des visites sur l’infrastructure d’hébergement web : for i in {1..50}; do curl
192.168.0.33:80; done

Le serveur 1 a pris le relai pour toutes les erreurs.

Après avoir essayer d’arrêter les 2 serveurs, on nous envoi un erreur (une page html avec une erreur 503
service indisponible). Vu que les 2 serveurs sont arrêtés, logiquement l’erreur est renvoyée car rien n’est
accessible.

3.15) Relançons un des serveur web de backend : docker start haproxy_apache_con_1

3.16) Resimuler des visites sur l’infrastructure d’hébergement web : for i in {1..50}; do curl
192.168.0.33:80; done
3.17) Pour vérifier les choses de façon graphique, HAProxy propose une interface web de monitoring,
pour y accèder il faut se rendre via un navigateur web sur l’url : http://10.0.2.16/haproxy?stats avec
les informations de login soit admin:admin