CONTACT & INFORMATIONS PERSONNELLES

● Tel : (+221)775708806 / 766288197

● Email : dmaodo@gmail.com

PROFIL PROFESSIONNEL

Architecte Technique Senior (16+ ans) spécialisé en Architecture à Micro-services et DevOps. Expertise prouvée dans la refonte de systèmes critiques (Télécoms, Finance) et le leadership technique (encadrement et mentoring d’équipes de développeurs). Expert de niveau 3 en Génie Logiciel (Java/Spring Boot) et méthodologies Clean Architecture/Clean Code.

COMPÉTENCES TECHNIQUES

EXPÉRIENCES PROFESSIONNELLES

Janvier 2024 – Présent

● Refonte de la messagerie vocale visuelle.

● Pilotage du Reverse Engineering du code existant.

● Rédaction des spécifications technico-fonctionnelles.

● Redéfinition et proposition d’architecture pour les modules de refonte (Micro-services).

● Définition et validation de l’architecture technique des micro-services. ● Mise en place de la chaîne DevOps complète (Docker, Jenkins, Sonar) pour l’industrialisation des systèmes.

● Encadrement technique et mentoring de l’équipe et des apprentis ingénieurs.

● Digitalisation des campagnes de tournées (géolocalisation des points d’attentions). ● Conception de l’architecture technique et applicative de nouveaux modules. ● Migration de données Cloudant vers CouchDB.

● Formation théorique et pratique des futurs collaborateurs (junior et senior) sur la Stack ELK (ElasticSearch, Logstash, Kibana), GIT, et Cassandra (Big Data).

● Mise en place de l’infrastructure de load-balancing du produit CRM & 360 Customer View.

● Rédaction de la spécification technique détaillée et du coût de mise en œuvre.

• Mise en place de l’infrastructure de load-balancing du produit CRM & 360 Customer View.
• Rédaction de la spécification technique détaillée et du coût de mise en œuvre.

• Mise en place d’une plateforme de télédéclaration (MOBILE,SMS,USSD,SVI) basée sur une architecture micro-services et Restful-API.
• Implémentation du microservice de notification SMS (Twilio) et d’une infrastructure de monitoring.

● Transformation digitale : Initialisation des stacks et architecture technique (Restful API, Micro-services, front-end).

● Appui technique et mentoring d’une équipe de deux développeurs.

● Mise en place de l’environnement de développement industrialisé (Gitlab, Jenkins, Sonar).

● Application des Best practices Git avec SAP Hybris.

● Appui technique d’une équipe de huit développeurs.

Septembre 2017 à Février 2019

● Projet KBTR (KPI Business Real Time) : gestion des indicateurs KPIS en temps réel avec usage du Big Data (Hadoop, Hive).

● Mise en place de l’environnement de développement (Microservices backend et frontend) et Best practices de Team Leading.

Mai 2016 à Février 2017

Gestion oneClick Deploy : gestion de configurations, livraisons et sauvegarde des serveurs.

Environnement de microservices.

● Projet AGATE APRR : Collecte et Valorisation des tickets de péages. ● Architecture : Batch de collecte, de basculement et de valorisation.

Novembre 2014 à Novembre 2015

● Sécurisation et numérisation des titres de transport.

● Architecture : Analyse conceptuelle et proposition de la solution. Développement des modules (référentiel, visites techniques, immatriculation).

● Analyse et développement des systèmes d’informations de collecte de données patient. ● Industrialisation : Mise en place de l’infrastructure WAN (DNS, Samba, SSH, Postfix/Exim, FTP) et de l’environnement développeur.

● Conception et développement du Système d’Information interne (gestion des collaborateurs, paie, reporting).

● Déploiement du parc informatique et mise en place de la politique de sécurité (plus de 150 postes).

• Développement du site de GrosBill (e-commerce).
• Rédaction de spécifications techniques et fonctionnelles. Déploiement de l’application

● Amélioration du module Statistique de la plateforme sportive WAZABET. ● Formateur sur les briques métiers (Smarty Templating, Pear_Cache, Doctrine(ORM)).

● Audit technique du système douanier GAINDE-Extension.

● Rédaction de l’audit technique et proposition des choix de nouvelles briques technologiques.

● Architecture technique du Movney.

● Implémentation de l’architecture technique. Administration des serveurs.

● Développement Backend et Frontend du portail Mobiciné (promotion artistes africains).

Avril 2007 à Janvier 2010

● Gestion des brevets d’invention (migration et refonte applicative) de l’INPI. ● Développement de l’intranet de gestion des marques et brevets de l’UE. Correction de bugs et développement du backend du portail OEB.

Avril 2006 à Mars 2007

● Développement backend et frontend pour la gestion de vente en ligne B2B.

FORMATION

• 2005 : DESS 2TIC (Diplôme d’Études Supérieures Spécialisées), Université Gaston Berger Saint-Louis, Sénégal
• 2004 : Maîtrise Informatique, Université Gaston Berger Saint-Louis, Sénégal
• 2003 : Licence Informatique, Université Gaston Berger Saint-Louis, Sénégal

ACTIVITÉS ACADÉMIQUES

Enseignements Universitaires (Depuis 2010)

● Domaines : Applications distribuées/JEE, Web Dynamique, Web Service & Technologie XML, Microservices, Développement Web Fullstack.

● Institutions : UGB (depuis 2013), ESP (2010-2012), Université de Thiès, Université Alioune DIOP de Bambey.

Encadrements de Mémoires (Master 2 / Licence)

Université Gaston Berger de Saint-Louis :

● 2024-2025: Permis de travail pour les employés des entreprises, Abidine Abdallahi ABIDINE, Master 2 MadDIS2CFPP UGB

● 2024-2025: Réalisation d’une application intelligente de réclamation des clients au centre de Mauritel, Mlle Aïchétou Mamadou SOW, Master 2 MadDIS2,CFPP UGB

● 2024-2025 (en cours) : Améliorer la productivité en industrialisant un environnement de développement par le biais des outils de containerisation, Maimouna GUEYE, Licence Professionnelle Génie Informatique, UGB

● 2023-2024 : Solution de gestion d’achat et logistique de transport, KHAWLA MOHAMED YESLEM AYEDE, Master 2 MadDIS2, CFPP, UGB

● 2023-2024 : Gestion facturation pour RIMTIC. BINT OUMRANA MOHAMED HAMDY 2022/2023 Master 2 MadDIS2,CFPP, UGB
● 2022-2023 : Mise en place d’une cartographie des volontaires pour la campagne de collecte de sang. Mme M’barcka Bekar Deida 2022/2023 Master 2 MadDIS2,CFPP, UGB ● 2022-2023 : Études comparatives entre les Framework Restful Gin-Golang & Spring Boot. El HACEN MAMADOU DIOP Master 2 MadDIS2, CFPP, UGB

● 2022-2023 : État de l’art des services de paiements Et intégration avec la plateforme de commerce électronique Shopify Samba Oumar Ba Master 2 MadDIS2, CFPP, UGB ● 2021-2022 : Mise en place d’une application hybride (web & mobile) de Service de Nettoyage chez Qwalit Tech : CHOZEN. Moussa DIA,2021/2022 Master 2 MadDIS2, CFPP, UGB

● 2021-2022 : Mise à niveau du progiciel de gestion des flux automatisé de transport, Analyse et Conception du module Importation. EL GHALIA Mohamed Salem,2021/2022 Master 2 MadDIS2, CFPP, UGB

● 2021-2022 : Analyse et conception d’un logiciel de transport et transit en : Analyse et Conception du module exportation. VATIMETOU MOHAMED HAMDI,2021/2022 Master 2 MadDIS2, CFPP, UGB

● 2019-2020 : Réalisation d’un système de gestion de la cuvette de Boundioum. Mr Dadah DIOP, 2019/2022 Master 2 Master 2 MadDIS2, CFPP, UGB

Ecole Supérieure Polytechnique :

● 2010-2011 : Mise en place d’une plateforme de MMS : Envoi de sonneries et logos. Abdou Salam KANE,2010-2011-ESP, UCAD

● 2010-2011 : Choix d’outils de monitoring pour une notification d’alerte SMS : cas de la DOUANE SENEGALAISE. El Hadji Malick DIENG,2010-2011, Département Génie Informatique, Licence Professionnelle Télécoms & Réseaux, ESP, UCAD

● 2010-2011 : Mise en place d’un SVA avec l’API FACEBOOK. Bélal Ba et Pape Mor Coundoul,2010-2011, Département Génie Informatique, Licence Professionnelle Télécoms & Réseaux, ESP, UCAD

Université Alioune Diop de Bambey :

● 2023-2024 : Conception et Réalisation d’une application mobile pour la réservation d’hôtel, Assane Guilavogui, UFR SATIC, SID

LANGUES

● Wolof (Maternelle)

● Français (Courant)

● Poular (Courant)

● Anglais, Arabe, Espagnol (Scolaire)

🚀 Notifications Pull vs. Push : Maîtrisez l’Art de la Livraison d’Infos avec Firebase

1. 💡 Introduction : Fini les boîtes aux lettres vides !

Salut à toi, humain(e) ! Si tu as déjà utilisé une application qui t’envoie un petit message sur ton téléphone pour te dire que ton ami a aimé ta photo, tu as déjà bénéficié d’une notification.

Les notifications sont le cœur battant de l’engagement utilisateur. Elles transforment une application passive en un outil dynamique qui te rappelle d’y revenir. Dans cet article, nous allons décortiquer les deux grandes stratégies pour y arriver – le Pull et le Push – et te montrer comment mettre en place la magie du Push en utilisant Firebase Cloud Messaging (FCM).

2. ❓ Problématique : Pourquoi les notifications ?

Imagine une application de réseau social sans notifications. Pour savoir si quelqu’un t’a répondu, tu devrais ouvrir l’application toutes les 5 minutes et actualiser ta page. C’est inefficace, frustrant, et ça vide ta batterie !

Les notifications résolvent ce problème en :

• Améliorant l’Engagement : Elles ramènent l’utilisateur dans l’application.
• Offrant une Réactivité Maximale : L’information arrive instantanément.
• Permettant la Communication Asynchrone : L’émetteur n’a pas besoin que le récepteur soit “en ligne” au moment de l’envoi.

3. ⚖️ Push vs Pull : Définitions & Différences

C’est là que réside le concept fondamental. Faisons simple :

Le Modèle PULL (Tirer) : Le Facteur qui Attend

• Définition : C’est le client (ton téléphone/navigateur) qui initie la demande. Il va régulièrement demander au serveur : “J’ai de nouvelles données pour moi ?”.
• Analogie : C’est comme aller vérifier ta boîte aux lettres tous les matins. S’il n’y a rien, tu as fait le voyage pour rien.
• Exemples : La plupart des requêtes HTTP classiques (GET), les requêtes pour actualiser un flux RSS.
• Inconvénients : Latence (tu dois attendre le prochain “check”) et consommation de ressources (le client et le serveur travaillent même si rien n’a changé).

Le Modèle PUSH (Pousser) : Le Livreurs de Pizza

• Définition : C’est le serveur qui initie la communication. Dès qu’une nouvelle donnée est prête, il la “pousse” vers le client.
• Analogie : C’est comme le livreur de pizza qui sonne à ta porte dès que ta commande est prête. C’est instantané !
• Exemples : Les notifications mobiles, les e-mails entrants, les mises à jour en direct.
• Avantages : Zéro latence pour l’utilisateur, très économe en ressources côté client (il n’a pas besoin de vérifier).

4. 🌍 Comparaison Push / Pull chez les géants de l’informatique

5. 🔗 Webhooks vs Notifications Push/Pull

Tu entendras souvent parler de Webhooks dans le contexte du “Push”, et c’est important de faire la distinction :

• Webhooks (ou Push HTTP) : C’est du Push, mais généralement utilisé pour la communication de serveur à serveur. Par exemple, quand une transaction PayPal est terminée, PayPal envoie une requête HTTP PUSH à un serveur (le tien) pour le prévenir.

• Notifications Push (FCM, APNs) : C’est du Push, mais destiné à la communication de serveur au client final (l’application mobile ou web de l’utilisateur). Elles passent par des services intermédiaires optimisés (comme FCM) pour garantir la livraison et économiser la batterie.

6. 📱 Présentation de FCM (Firebase Cloud Messaging)

Puisque développer un système Push fiable de zéro est un cauchemar (problèmes de connectivité, gestion des jetons, économie de batterie, etc.), on utilise des services spécialisés. Le plus populaire et le plus facile d’accès est Firebase Cloud Messaging (FCM), une offre de Google.

FCM, c’est le ‘facteur universel’ : Il gère la connexion persistante et sécurisée entre ton serveur d’application et l’appareil de l’utilisateur, que l’appareil soit Android, iOS ou une application Web.

7. 🏗️ Architecture du Système FCM

Comprendre l’architecture, c’est comprendre comment ça marche ! Il y a trois acteurs clés :

1. Le Client (L’Application de l’Utilisateur) : C’est ton application mobile ou web. Il reçoit et affiche la notification.
2. FCM (Le “Router”) : Le service de Google qui gère la connexion en direct avec chaque appareil. Il reçoit le message de ton serveur et le relaie à la bonne plateforme (Android ou Apple).
3. Le Serveur d’Application (Ton Backend) : C’est là que la logique métier réside (ex: un nouvel ami a posté, la commande est prête). C’est ce serveur qui appelle l’API de FCM pour lui dire : “Envoie ce message à cet utilisateur !”.

8. 🛠️ Étapes de Configuration Pratique

Pour implémenter des notifications avec FCM, voici les étapes simplifiées :

Étape 1 : Côté Client (Ton App)

1. Enregistrement : Au premier lancement, ton application demande à FCM un Token d’enregistrement (ou Jeton) unique pour cet appareil. C’est l’adresse postale de l’appareil.
2. Transmission du Token : L’application envoie ce Jeton au Serveur d’Application (Ton Backend).
3. Gestion du Message : L’application installe un Listener (écouteur) pour savoir quoi faire quand le message arrive (ex: afficher une alerte, mettre à jour des données).

Étape 2 : Côté Serveur (Ton Backend)

1. Stockage : Ton serveur doit stocker en base de données le Jeton de l’utilisateur (l’adresse postale) avec l’ID de l’utilisateur.
2. Envoi : Quand un événement se produit (ex: un ‘Like’), ton serveur exécute un code qui appelle l’API de FCM en lui fournissant :
   • Le Jeton de l’appareil cible.
   • Le Contenu de la notification (titre, corps, icône).
3. FCM prend le relais : FCM reçoit l’appel et se charge de livrer la notification à l’appareil correspondant.

9. 🛡️ Sécurité et Bonnes Pratiques

• Gestion des Tokens : Les Jetons peuvent changer (par exemple, si l’utilisateur désinstalle et réinstalle l’application). Ton serveur doit gérer la mise à jour et la suppression des jetons invalides pour éviter d’envoyer des notifications dans le vide.
• Confidentialité : N’inclus jamais d’informations ultra-sensibles (comme des mots de passe) dans le corps des notifications, car elles transitent par le service FCM.
• Limiter les Abus : Ne spamme jamais l’utilisateur ! Un excès de notifications est la première cause de désinstallation d’une application.

10. ✅ Avantages / 🛑 Limites de FCM

11. 🎬 Conclusion et Démonstration de l’Application

Le passage du Pull au Push est une étape cruciale pour créer une expérience utilisateur moderne et engageante. Grâce à des outils comme Firebase Cloud Messaging, nous pouvons facilement implémenter cette stratégie sans avoir à gérer les complexités des connexions réseau persistantes.

12. 📖 Documentation Générale et Concepts

• Accueil Firebase Cloud Messaging :

  • Le point de départ pour comprendre les fonctionnalités, la tarification (principalement gratuit) et les cas d’utilisation.
  • Lien vers la documentation FCM

• Architecture et Processus des Messages :

  • Comprendre en détail le rôle du serveur, de FCM et du client.
  • Lien vers l’aperçu de l’architecture FCM

13. 📱 Guides de Démarrage Rapide (Par Plateforme Client)

Ces guides t’expliquent comment installer le SDK Firebase et obtenir le fameux Jeton d’enregistrement sur l’appareil.

• Pour Android (Kotlin/Java) :

  • Comment configurer ton projet Android et gérer les messages entrants.
  • Lien vers le guide de démarrage Android

• Pour iOS / Swift :

  • Les étapes pour configurer le projet Apple (APNs) et le relier à Firebase.
  • Lien vers le guide de démarrage iOS

• Pour le Web (JavaScript) :

  • Comment intégrer FCM à ton site web pour afficher des notifications dans le navigateur.
  • Lien vers le guide de démarrage Web

14. ⚙️ Guides d’Implémentation Côté Serveur (Backend)

C’est ici que tu apprendras à envoyer la notification après avoir collecté le Jeton. Tu peux utiliser n’importe quel langage de programmation pour ton backend en utilisant l’API HTTP ou les SDK d’administration.

• Envoi de Messages avec l’API HTTP v1 :

  • La méthode recommandée pour envoyer des messages depuis ton propre backend.
  • Lien vers le guide d’envoi via l’API HTTP v1

• Utilisation du SDK Admin (Exemple Node.js) :

  • Si tu utilises Node.js, Python, Java, ou d’autres pour ton backend, le SDK Admin simplifie l’envoi de messages à FCM.
  • Lien vers le guide d’utilisation du SDK Admin

• Comment simplifier les tâches de déploiements d’applications dans plusieurs serveurs avec le même stack d’outils ?
• Ou ne plus répéter les tâches d’installations des outils pour l’infrastructure de développement ou de la production ?
• Ou bien ne plus entendre la fameuse phrase « Pourtant cela marche sur mon environnement/machine » de la part des collaborateurs.
• Comment fournir un stack préfabriqué de l’entreprise pour les nouveaux collaborateurs pour leur simplifier les tâches d’installations et/ou de configuration ?
• Comment configurer un arsenal de serveurs avec plus ou moins les mêmes caractéristiques ?

Si ces genres de questions vous concernent, alors la virtualisation et ses outils référents sont le remède de votre souci. Un des outils permettant de résoudre votre problème est Vagrant.

Vagrant s’adresse aux développeurs, aux devops, aux geeks etc…

Wikipédia cite : « Vagrant est un logiciel libre et open-source pour la création et la configuration des environnements de développement virtuel. Il peut être considéré comme un wrapper autour de logiciels de virtualisation comme VirtualBox. »

L’on peut citer d’autres outils de virtualisation en l’occurrence VMware, Hyper-V, Xen, KVM, Oracle VM, Proxmox VE, oVirt etc.

Parce qu’elle utilise le principe de virtualisation, il est donc compatible avec la majorité des systèmes d’exploitation (OS). C’est-à-dire qu’un utilisateur travaillant sous Mac aura accès au même environnement qu’un développeur sous Windows ou Linux tout en conservant les mêmes stacks.

Dans la suite, l’on utilisera VirtualBox comme outils de virtualisation avec Vagrant car ce dernier est en réalité une surcouche des solutions de virtualisation. Il faudra noter aussi que Vagrant n’est pas un outil de provisioning qui gère les dépendances logicielles de la machine virtuelle (VM).

Les solutions de provisionning par ordre de priorité sont pour les débutants l’usage des scripts shell puis enfin l’utilisation des solutions prouvées comme : Ansible, Puppet, Solo, Chef.

Vagrant repose sur la trilogie suivante :

1. Un fichier d’entrée Vagrantfile

• Écrit en Ruby, ce fichier de configuration principale va servir à définir le dossier racine du projet avec quelques options de configurations. Les options de base de configurations seront :
  • Le type de machine souhaité (Ubunty, Centos, Debian etc…) et dans le vocabulaire de Vagrant c’est la box.
  • La configuration réseau (nat, dhcp, ip fixe etc…)
  • Le provider qui est soit un script shell et/ou les outils tels Ansible, Puppet etc.

2. Les boxes

• Ceux sont la plupart du temps des OS (Ubuntu entre autres…) ou des applications préinstallées prêtes à l’emploi pour accélérer la construction de l’environnement virtuel.

3. Un ou plusieurs providers

• Vagrant ne virtualisant pas directement les environnements fait appel à un provider pour accomplir cette tâche. VirtualBox étant la plus utilisée pour la plupart du temps mais VmWare gagne aussi du terrain.

Un cas d’exemple universel : « Hello World » à la sauce Vagrant

Créer un répertoire que l’on nommera lab-vagrant et démarrons un petit projet vagrant en exécutant la commande :

λ vagrant init

A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Lister le contenu de ce répertoire :

λ ls
Vagrantfile

Cette commande crée un fichier de configuration de nom Vagrantfile dont le contenu est commenté. Nous allons modifier ce fichier en supprimer les commentaires et le personnaliser.

Générerons notre VM en exécutant la commande ci-dessous :

λ vagrant up

Explication du code en rapport avec ce qui est plus haut.

Nous avons configuré notre environnement avec le système d’exploitation hashicorp/precision32 avec sa version 1.0.0. Celui-ci est une box dans le jargon de Vagrant, nous pourrions pu utiliser un Ubuntu ou un Debian ou CentOS pourquoi pas ?

config.vm.box = “hashicorp/precise32”
config.vm.box_version = “1.0.0”

Notre logiciel de virtualisation étant VirtualBox, nous définissons une mémoire octroyée et l’absence d’interface ergonomique.

config.vm.provider “virtualbox” do |vb|
  vb.gui = false
  vb.memory = “1024”
end

Puis en dernier, l’affichage d’un message une fois que le provisioning est terminé par les citations des auteurs (Shakespeare et La Fontaine).

Pour les besoins de simplicité, nous appelons un script-line avec l’aide des possibilités du Shell en lieu et place des outils de provisionning comme Puppet, Salt, Chef, Solo, Ansible etc…

Commandes Vagrant fréquemment utilisées

Avec un vagrant ssh, l’on peut faire ce que l’on veut sur sa VM en terme d’installations de paquets, de personnalisation (clavier, heure…)

vagrant@vm1hello:~$ uname -a
Linux vm1hello 3.13.0–32-generic #57~precise1-Ubuntu SMP Tue Jul 15 03:50:54 UTC 2014 i686 i686 i386 GNU/Linux
vagrant@vm1hello:~$ whoami
vagrant
vagrant@vm1hello:~$ sudo apt-get update
# ... Logs de l'update ...
vagrant@vm1hello:~$ sudo apt-get install -y git
# ... Logs de l'installation de git ...

Vagrant et HAProxy comme Load Balancing

Le load balancing est une technique qui consiste à répartir les charges sur différents appareils d’un même réseau. Elle permet notamment aux serveurs de sites Internet à forte audience de ne pas se retrouver surchargés. Dans le load balancing, les multiples requêtes sont distribuées sur plusieurs serveurs.

Techniquement, chaque élément qui compose le système a un rôle :

1. L’internet à travers lequel l’utilisateur accède.
2. Le serveur DNS, chargé de faire la jonction entre le nom de domaine et l’adresse IP du serveur qui l’héberge.
3. Le loadbalancer a pour but de transmettre les charges sur différentes ressources.

Pour ce billet, nous allons utiliser Vagrant pour faire du load balancing avec HAProxy.

Nous allons utiliser trois (3) instances avec les caractéristiques suivantes :

Sur les deux derniers serveurs (webserver1, webserver2), Apache y est installé servant de tests pour le load balancing servi par HAProxy.

Configuration des Instances via Vagrant et Shell Scripts

Pour configurer nos instances, nous définissons pour chaque instance l’appel à un script shell pour l’installation et la configuration :

webserver.sh

Ce script installe le paquet Apache 2, ajoute le nom du serveur dans le fichier de configuration d’Apache et redémarre Apache.

Le fichier index.html est modifié pour qu’il affiche selon l’algorithme utilisé par le loadbalancer pour l’élection des serveurs :

• Soit Webserver1 / Je suis votre serviteur !
• Ou Webserver2 / Je suis votre serviteur !

haproxy.sh

Pour la configuration HAProxy, nous avons les étapes suivantes :

1. Mise à jour du gestionnaire des paquets : apt-get update -y -qq
2. Installer HAProxy : apt-get install -y haproxy
3. Activer HAProxy comme daemon au démarrage :

   cat > /etc/default/haproxy <<EOF
   ENABLED=1
   EOF
   

4. Configuration des serveurs pour le load balancing avec l’algorithme roundrobin :

   server webserver1 192.168.50.10:80 check
   server webserver2 192.168.50.20:80 check
   

5. Accéder à l’interface web des statistiques de HAProxy :
   • stats enable
   • stats auth admin:admin
   • stats uri /haproxy?stats
6. Valider la configuration : haproxy -f /etc/haproxy/haproxy.cfg -c
7. Démarrer l’utilitaire HAProxy : service haproxy start

Test de l’Infrastructure

Pour tester notre infrastructure, lancer les commandes suivantes :

vagrant up

Nous pouvons nous connecter à chaque instance en SSH :

vagrant ssh webserver1
vagrant ssh webserver2
vagrant ssh haproxy

En appelant le serveur (par l’IP du load balancer), l’on est servi suivant la disponibilité de webserver1 et/ou webserver2.

Nous pouvons tester en mode web et avoir les réponses suivant la disponibilité des serveurs.

HAProxy offre l’interface d’administration des serveurs. Il suffit de se pointer sur http://192.168.50.30/haproxy?stats.

Ici nous remarquons que tous nos serveurs sont au vert. Essayer d’éteindre le premier serveur à savoir webserver1.

λ vagrant halt webserver1
==> webserver1: Attempting graceful shutdown of VM…

Et nous aurons l’interface HAProxy qui prend en compte l’état actuel des serveurs.

Liens Utiles

• Boxes Vagrant : http://www.vagrantbox.es/
• HAProxy Ubuntu : https://upcloud.com/community/tutorials/haproxy-load-balancer-ubuntu/
• HAProxy Wikipedia : https://en.wikipedia.org/wiki/HAProxy

```