Guide complet : installer et configurer HAProxy pour le load balancing

Configuration de base HAProxy (Frontend, Backend et Listen)

L’architecture de HAProxy repose sur trois blocs fondamentaux qui structurent toute la configuration dans le fichier /etc/haproxy/haproxy.cfg. Le frontend représente le point d’entrée : il écoute sur un port et reçoit le trafic entrant. Le backend définit le groupe de serveurs qui traiteront les requêtes. Le bloc listen combine les deux dans un seul espace, idéal pour les configurations simples ou les protocoles spécifiques comme le mode TCP.

Déclaration des blocs frontend, backend et listen

Le frontend agit comme une porte d’entrée unique. Il écoute sur les ports 80, 443 et 8404 selon vos besoins. Le mode HTTP est généralement activé par défaut pour l’analyse des requêtes. L’ordre des directives suit la logique du flux : le frontend reçoit, le backend répartit. Le bloc listen fusionne ces deux responsabilités, particulièrement utile pour les services qui n’ont pas besoin d’une séparation stricte.

La directrice mode http permet à HAProxy de comprendre et router le trafic web. En dessous, les paramètres timeout évitent les connexions bloquées. Le backend référence ensuite les serveurs disponibles via leur adresse IP, comme les endpoints 192.168.1.10 et 192.168.1.11. Cette déclaration simple suffit pour un équilibrage fonctionnel.

Exemple de configuration pas-à-pas pour deux backends

Voici une configuration minimale pour répartir le trafic HTTP entre 2 backends. Copiez ce bloc dans votre fichier de configuration, puis personnalisez les adresses IP et les ports selon votre infrastructure.

• frontend web : écoute sur le port 80, adresse * toutes interfaces
• backend servers : liste les serveurs 192.168.1.10 et 192.168.1.11
• balance roundrobin : répartit les requêtes à tour de rôle
• haproxy -c : valide la syntaxe de la configuration
• Test : les réponses alternent entre les deux backends

Après avoir enregistré le fichier, exécutez haproxy -c -f /etc/haproxy/haproxy.cfg pour vérifier qu’aucune erreur ne bloque le démarrage. Redémarrez ensuite le service. Pour tester, ouvrez plusieurs requêtes vers votre adresse publique : la réponse doit alterner régulièrement entre les deux serveurs, preuve que le load balancing fonctionne correctement. Cette architecture de base, créée à partir des fondations posées par HAProxy 2000, gère sans effort des millions de connexions simultanées dès lors que la configuration est correcte.

Concepts clés : load balancer, reverse proxy et architecture HAProxy

Créé en 2000 par Willy Tarreau, HAProxy est un load balancer et reverse proxy open source capable de gérer des millions de connexions simultanées. Des plateformes comme GitHub, Stack Overflow ou Reddit s’appuient dessus pour répartir leur trafic. Il agit comme un intermédiaire : il reçoit les requêtes des clients et les distribue vers un groupe de serveurs selon des règles précises.

Dans l’architecture HAProxy, le frontend définit le point d’entrée (adresse IP et port d’écoute), tandis que le backend regroupe les serveurs qui traitent réellement les requêtes. Le bloc listen combine ces deux fonctions en une seule déclaration, pratique pour les configurations simples. Cette séparation offre une grande flexibilité pour gérer le trafic entrant, qu’il soit HTTP ou TCP.

En tant que reverse proxy, HAProxy masque l’infrastructure interne et centralise la gestion des connexions. Cela permet d’appliquer des politiques de sécurité, d’ajouter des en-têtes ou d’effectuer des terminaisons TLS. Pour l’utilisateur, l’adoption de cette architecture est la première brique d’un déploiement scalable et résilient.

Installation de HAProxy sur Ubuntu ou Debian

Pour profiter d’un load balancing fiable, l’installation de HAProxy 3.2 est recommandée. Cette version LTS bénéficie d’un support officiel jusqu’en 2029, et la branche plus ancienne reste maintenue jusqu’en 2030. La version 3.2 a de plus été auditée par Almond ITSEF pour l’ANSSI, garantissant un niveau de sécurité certifié.

Installation depuis les dépôts officiels et prérequis système

Avant de lancer l’installation, vérifiez que votre système est compatible. Ubuntu 22.04+ ou Debian 12+ sont les versions minimales requises pour obtenir HAProxy 3.2 depuis les dépôts officiels.

• Prérequis système : Ubuntu 22.04+ ou Debian 12+
• Ports à libérer : 80, 443 et 8404
• Installation : apt install haproxy
• Vérification : haproxy -v doit afficher 3.2
• Sécurité : branche auditée par Almond ITSEF

La commande sudo apt install haproxy suffit dans la majorité des cas. Une fois installé, vérifiez la version avec haproxy -v vous devez obtenir la 3.2 ou une version supérieure pour bénéficier des fonctionnalités récentes comme les logs JSON natifs.

Compilation depuis les sources officielles

La compilation depuis les sources s’impose si vous avez besoin des toutes dernières fonctionnalités non encore packagées. Cette méthode offre un contrôle total sur les options de compilation et les modules intégrés.

Téléchargez d’abord les sources officielles depuis le site de HAProxy. La configuration se fait avec make TARGET=linux-glibc ajustez TARGET selon votre noyau. Pour activer SSL/TLS, ajoutez USE_OPENSSL=1 et USE_PROMEX=1 pour le support Prometheus. Les variables comme CPU=native et ARCH=x86_64 permettent d’optimiser les performances.

Lancez ensuite make puis sudo make install. L’installation place les binaires dans /usr/local/sbin/haproxy. Avant de démarrer le service, validez votre configuration avec haproxy -c -f /etc/haproxy/haproxy.cfg. La compilation complète prend entre 5 et 10 minutes sur une machine standard.

Monitoring, statistiques et résolution d’erreurs courantes

Une fois votre configuration HAProxy en place, il est essentiel de surveiller la santé de vos backends. Le logiciel embarque un tableau de bord de statistiques riche et accessible via une simple page web. Pour l’activer, ajoutez un bloc listen stats dans votre fichier /etc/haproxy/haproxy.cfg, en écoutant sur le port 8404. Cette page vous affiche en temps réel l’état de chaque serveur : les serveurs actifs apparaissent en vert (UP), tandis que les serveurs indisponibles sont marqués en rouge (DOWN).

Accéder au tableau de bord de statistiques HAProxy

Pour visualiser ces précieuses métriques, pointez simplement votre navigateur vers http://votre-ip:8404/stats. Vous y trouverez des indicateurs clés comme les connexions actives, les requêtes par seconde et la latence de chaque backend. Cette interface est le premier réflexe à avoir pour diagnostiquer un déséquilibre de charge ou un serveur défaillant.

Pour une supervision plus poussée, la version HAProxy 3.2 prend en charge les logs JSON natifs. Cette fonctionnalité facilite grandement l’intégration avec des outils comme Prometheus et Grafana, vous permettant de construire des dashboards de supervision complets et historisés, bien au-delà de l’instantané fourni par la page stats.

Dépannage : erreurs courantes et serveurs marqués DOWN

• bind: cannot bind socket : un autre processus occupe déjà le port 80, 443 ou 8404. Libérez le port ou changez l’adresse d’écoute.
• Serveur DOWN : vérifiez que l’endpoint /health de votre application répond bien avec un code 200. C’est la cause la plus fréquente de retrait automatique du pool.
• Codes 503 Service Indisponible : cela signifie qu’aucun backend n’est en mesure de répondre. Assurez-vous que vos serveurs sur 192.168.1.10 et 192.168.1.11 sont bien démarrés et joignables.
• Timeouts frontend et backend : des timeouts trop courts peuvent interrompre des requêtes légitimes. Contrôlez les valeurs timeout connect et timeout server dans votre configuration.
• Logs JSON pour diagnostic : si le problème persiste, activez les logs JSON (HAProxy 3.2+) et analysez les réponses HTTP détaillées pour identifier la cause racine exacte.

Algorithmes de répartition, health checks et haute disponibilité

Le choix de l’algorithme de répartition détermine la manière dont les requêtes sont distribuées entre vos serveurs backend. La configuration s’effectue dans le bloc `backend` via la directive `balance`. Voici les trois mécanismes principaux à connaître.

Le Round Robin reste le choix par défaut le plus simple : chaque requête est envoyée au serveur suivant dans la liste, de manière cyclique. Pour des backends aux performances hétérogènes, pensez à ajuster le poids de chaque serveur avec l’option weight.

Health checks : la clé de la fiabilité

Un health check permet à HAProxy de vérifier en continu l’état de santé de vos serveurs. Par défaut, un simple TCP check confirme que le port est ouvert. Pour une validation plus fine, l’option httpchk envoie une requête HTTP et attend un code 200 en retour. Si votre endpoint /health ne répond plus, le serveur est automatiquement marqué DOWN et retiré du pool. Les requêtes sont alors redirigées vers les serveurs restants UP, sans interruption de service.

Haute disponibilité avec Keepalived

Pour éviter un point de défaillance unique, déployez 2 serveurs HAProxy en mode actif/passif. L’outil Keepalived gère une adresse IP virtuelle partagée entre les deux nœuds. La configuration repose sur deux paramètres critiques : le virtual_router_id, qui doit être identique sur les deux machines, et la priorité, qui définit le nœud maître. En cas de panne, le basculement vers le nœud secondaire s’effectue en quelques secondes. Pour la répartition de charge sur une base de données, vous pouvez appliquer le même principe avec 2 serveurs PostgreSQL en lecture seule, le trafic étant dirigé vers le nœud le plus disponible.

Sticky sessions et sécurisation des échanges avec SSL/TLS

Pour garantir qu’un utilisateur conserve sa session sur le même serveur, activez l’option stickiness via un cookie ou le hash de l’IP source. Cette approche est essentielle pour les applications nécessitant un état persistant, comme les paniers d’achat. L’algorithme source constitue une alternative simple et efficace, renvoyant systématiquement le même client vers le même backend sans gestion de cookie.

Côté sécurité, HAProxy agit comme point unique de terminaison TLS. Configurez une version minimale de TLS 1.2 et privilégiez les suites de chiffrement AES-GCM ou ChaCha20. Pour une robustesse maximale, utilisez les courbes elliptiques X25519, P-256 et P-384 dans votre configuration. Le certificat se charge sur le frontend, déchargeant ainsi les serveurs web de la cryptographie et centralisant la gestion des certificats. La configuration s’effectue en ajoutant bind *:443 ssl crt /etc/haproxy/certs/ dans le bloc frontend dédié au trafic HTTPS.