Introduction à HAProxy

Haproxy (High Availability Proxy) est le standard de l’industrie pour l’équilibrage de charge TCP/HTTP. Réputé pour son extrême rapidité et sa stabilité, il est utilisé par des géants comme GitHub, Reddit et Twitter pour gérer des flux massifs de données.

Pourquoi choisir HAProxy ?

Fonctionnement Technique

HAProxy repose sur un modèle de traitement non-bloquant. Contrairement à d’autres serveurs qui créent un processus ou un “thread” par connexion, HAProxy utilise une boucle d’événements unique, ce qui lui permet de rester performant même sous une charge CPU intense.

Note : Couche 4 vs Couche 7

• L4 (Transport) : L’aiguillage se fait sur l’IP et le Port. C’est ultra-rapide mais “aveugle” au contenu.
• L7 (Application) : HAProxy analyse les headers HTTP, les cookies ou l’URL pour décider du routage.

Configuration : Anatomie d’un fichier .cfg

La configuration de HAProxy ne se fait pas en YAML, mais via un format propriétaire structuré en quatre sections : global, defaults, frontend et backend.

Exemple : Routage Intelligent (Statique vs Dynamique)

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    timeout connect 5s
    timeout client  50s
    timeout server  50s

frontend http_in
    bind *:80
    # Définition des ACL (Access Control Lists)
    acl is_static path_beg /static /images
    acl is_api    path_beg /api

    # Décisions de routage basées sur les ACL
    use_backend static_servers if is_static
    use_backend api_servers    if is_api
    default_backend app_servers

backend app_servers
    balance roundrobin
    # Persistence de session via cookie
    cookie SERVERID insert indirect nocache
    server node1 192.168.1.10:80 check cookie node1
    server node2 192.168.1.11:80 check cookie node2

Sécurisation avec SSL/TLS Termination

La SSL Termination permet à HAProxy de déchiffrer le trafic HTTPS. Cela libère vos serveurs backend de cette tâche lourde en calcul, leur permettant de se concentrer sur la logique applicative en HTTP simple.

Mise en place du HTTPS

• Préparation : HAProxy nécessite souvent que le certificat et la clé privée soient combinés dans un seul fichier .pem.
• Configuration du Frontend :

frontend https_in
    # On spécifie le certificat et on active le support HTTP/2 (alpn)
    bind *:443 ssl crt /etc/ssl/certs/mon-site.pem alpn h2,http/1.1
    
    # Redirection automatique du HTTP vers le HTTPS
    http-request redirect scheme https unless { ssl_fc }
    
    default_backend app_servers

Mise en place de la Persistence de Session (Cookie)

La méthode la plus propre consiste à demander à HAProxy d’insérer un cookie spécifique dans la réponse HTTP.

Configuration du Backend :

backend app_servers
    balance roundrobin
    # 'SERVERID' est le nom du cookie qui sera créé
    # 'insert' : HAProxy ajoute le cookie si absent
    # 'indirect' : Le cookie n'est pas envoyé au serveur backend
    # 'nocache' : Empêche les caches intermédiaires de stocker ce cookie
    cookie SERVERID insert indirect nocache

    # On ajoute 'cookie <nom>' à la fin de chaque ligne serveur
    server node1 192.168.1.10:80 check cookie node1
    server node2 192.168.1.11:80 check cookie node2
    server node3 192.168.1.12:80 check cookie node3

Comment ça marche ?

• Lors de la première visite, HAProxy choisit un serveur (ex: node1).
• Il ajoute un header Set-Cookie: SERVERID=node1 dans la réponse.
• Au prochain clic, le navigateur renvoie ce cookie.
• HAProxy lit SERVERID=node1 et sait qu’il doit renvoyer l’utilisateur précisément sur ce serveur.

Filtrage d’IP et Sécurité (White/Blacklisting)

HAProxy peut servir de première ligne de défense contre des adresses IP malveillantes ou pour restreindre l’accès à une interface d’administration.

Exemple : Restreindre l’accès à l’Admin

frontend http_in
    bind *:80
    
    # 1. Définition des ACLs
    acl is_admin_path path_beg /admin
    acl is_allowed_ip src 123.123.123.123  # Votre IP fixe
    
    # 2. Action : Bloquer si c'est l'admin MAIS PAS la bonne IP
    http-request deny if is_admin_path !is_allowed_ip
    
    default_backend app_servers

Exemple : Liste noire d’IP (IP Blacklist)

Si vous avez une liste massive d’IP à bloquer, utilisez un fichier externe pour ne pas alourdir votre config :

frontend http_in
    # Bloquer toutes les IP présentes dans le fichier 'blacklist.lst'
    acl restricted_ip src -f /etc/haproxy/blacklist.lst
    http-request deny if restricted_ip

(Le fichier blacklist.lst contient simplement une IP ou un réseau par ligne, ex: 1.2.3.4 ou 192.168.1.0/24).

Bonus : Le “Drain Mode” pour la maintenance

Un avantage énorme des Sticky Sessions est de pouvoir éteindre un serveur sans déconnecter personne.

• Vous passez le serveur en mode DRAIN via l’interface de stats ou la ligne de commande.
• HAProxy arrête d’envoyer de nouveaux clients sur ce serveur.
• Il laisse les clients existants (ceux qui ont déjà le cookie) finir leur session.
• Une fois que le compteur de connexions tombe à zéro, vous pouvez couper le serveur en toute sécurité.

Administration et Diagnostic

Avant de redémarrer le service, validez toujours votre syntaxe pour éviter de “casser” la production :

# Vérifier la syntaxe du fichier de configuration
haproxy -c -f /etc/haproxy/haproxy.cfg

# Recharger la configuration sans couper les connexions en cours
sudo systemctl reload haproxy

Le Dashboard de Statistiques

HAProxy inclut une interface web native pour surveiller vos flux. Ajoutez ceci à votre config pour l’activer :

listen stats
    bind *:8404
    stats enable
    stats uri /monitor
    stats refresh 5s
    stats auth admin:password123

L’architecture “Keepalived + VIP”

Le mode cluster (ou Haute Disponibilité - HA) pour HAProxy répond à une problématique simple : si votre équilibreur de charge tombe, toute votre infrastructure devient inaccessible, même si vos serveurs backend fonctionnent parfaitement. C’est ce qu’on appelle un SPOF (Single Point of Failure).

Pour éviter cela, on utilise généralement un couple de deux serveurs HAProxy travaillant de concert.

La méthode la plus courante pour “clustériser” HAProxy n’est pas une fonctionnalité native interne au binaire HAProxy lui-même, mais l’utilisation d’un outil complémentaire nommé Keepalived.

Le concept de l’IP Virtuelle (VIP)

• Vous avez deux serveurs HAProxy avec leurs propres adresses IP (ex: 10.0.0.1 et 10.0.0.2).
• Vous créez une IP Virtuelle (VIP) (ex: 10.0.0.100) qui “flotte” entre les deux.
• Vos clients (ou votre DNS) pointent uniquement vers cette VIP.

Fonctionnement : Actif / Passif

• Le Maître (Master) : Il détient la VIP et traite 100% du trafic.
• L’Esclave (Backup) : Il surveille le Maître via un protocole appelé VRRP (sorte de “battement de cœur”).
• Le Basculement (Failover) : Si le Maître ne répond plus, l’Esclave s’aperçoit de l’absence de battement de cœur et “arrache” la VIP pour l’assigner à sa propre interface réseau. Le trafic reprend en quelques millisecondes.

La synchronisation des sessions (Peers)

Un problème survient lors du basculement : si HAProxy gère des Sticky Sessions (via table de persistance en mémoire), l’Esclave ne connaît pas les sessions du Maître. L’utilisateur devra se reconnecter.

Pour corriger cela, on configure la section peers dans HAProxy pour que les nœuds partagent leurs tables d’états en temps réel.

peers mypeers
    peer haproxy1 10.0.0.1:1024
    peer haproxy2 10.0.0.2:1024

backend app_servers
    stick-table type ip size 1m expire 1h peers mypeers
    stick on src
    server node1 192.168.1.10:80 check

Configuration type de Keepalived

Voici à quoi ressemble la configuration sur le serveur Maître (/etc/keepalived/keepalived.conf) :

vrrp_script check_haproxy {
    script "killall -0 haproxy" # Vérifie si le processus HAProxy tourne
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101 # Priorité plus haute que le backup
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        10.0.0.100 # L'IP Virtuelle
    }
    track_script {
        check_haproxy
    }
}

Actif / Actif (Pour les très grosses charges)

Dans certains cas extrêmes, on veut que les deux HAProxy travaillent en même temps. On utilise alors :

• DNS Round Robin : Le nom de domaine pointe vers deux VIP différentes (une sur chaque nœud).
• Anycast BGP : Une solution réseau plus complexe où les routeurs distribuent le trafic vers le nœud HAProxy le plus “proche”.

Résumé des bénéfices

• Zéro interruption : Maintenance transparente (on coupe le maître, le backup prend le relais).
• Mise à jour sans risque : On met à jour le nœud passif, on bascule, puis on met à jour l’ancien maître.
• Intégrité des données : Grâce aux peers, les informations de bannissement (Security) ou de session sont préservées.

Conclusion

HAProxy n’est pas seulement un outil de répartition de charge ; c’est un véritable couteau suisse pour la haute disponibilité. Sa rigueur et sa légèreté en font un choix incontournable pour toute architecture microservices ou web moderne.