HAProxy sous Debian 10 Buster

Topologie :

Configuration du réseau sur Virtual Box

Pour que notre backend puisse fonctionner correctement, il va falloir que toutes les machines backend soient dans le même réseau. Si on utilise VirtualBox comme ici, on va devoir spécifier dans la configuration réseau de nos machines, le mode d’accès réseau en réseau interne et lui donné un nom, on utilisera backend.

On va ajouter une 2ème carte réseau au serveur HAProxy qui sera dans le réseau interne backend, on fera de même pour les serveurs webs. Comme ceci :

Configuration réseau et Installation de HAProxy

Pour mettre en place l’infrastructure du réseau, il faut que le serveur HAProxy ait 2 cartes réseau car on veut segmenter notre infrastructure entre le frontend qui aura pour adresse 172.16.200.10 et notre backend qui aura pour adresse 10.0.0.1. On ajoutera une 2ème carte réseau.

# The loopback network interface  
auto lo  
iface lo inet loopback  

# Frontend  
allow-hotplug enp0s3  
auto enp0s3  
iface enp0s3 inet static  
address 172.16.200.10/16  
gateway 172.16.0.1  

# Backend  
allow-hotplug enp0s8  
auto enp0s8  
iface enp0s8 inet static  
address 10.0.0.1/8

On peut installer HAProxy :

Pour connaître la version :

Description générale des éléments de configuration

Exemple du fichier de configuration

Voici le fichier de configuration qui est utilisé dans notre exemple :

global  
log /dev/log local0  
log /dev/log local1 notice  
chroot /var/lib/haproxy  
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners  
stats timeout 30s  
user haproxy  
group haproxy  
daemon  

defaults  
log global  
mode http  
option httplog  
option dontlognull  
timeout connect 5000  
timeout client 50000  
timeout server 50000  
errorfile 400 /etc/haproxy/errors/400.http  
errorfile 403 /etc/haproxy/errors/403.http  
errorfile 408 /etc/haproxy/errors/408.http  
errorfile 500 /etc/haproxy/errors/500.http  
errorfile 502 /etc/haproxy/errors/502.http  
errorfile 503 /etc/haproxy/errors/503.http  
errorfile 504 /etc/haproxy/errors/504.http  

frontend test  
bind 172.16.200.10:80  
default_backend web_servers  
option httpclose  

backend web_servers  
balance roundrobin  
option httpchk HEAD / HTTP/1.0  
server ha-proxy-client1 10.10.10.2:80 check  
server ha-proxy-client2 10.10.10.3:80 check  
stats uri /statshaproxy  
stats auth admin:admin  
stats refresh 30s

Description de global

log : Le paramètre de journal garantit que les avertissements émis lors du démarrage et les problèmes qui surviennent pendant l’exécution sont consignés dans syslog. Il enregistre également les demandes à mesure qu’elles arrivent. Vous pouvez cibler le socket UNIX traditionnel où Syslog ou journald, listen, / dev / log, ou spécifier un serveur rsyslog distant afin que les données de journal soient conservées en externe sur votre serveur d’équilibrage de charge

chroot : Le paramètre ‘chroot’ autorise à changer la racine du processus une fois le programme lancé, de sorte que ni le processus, ni l’un de ses descendants ne puissent remonter de nouveau à la racine.

stats socket : La ligne de socket stats active l’API Runtime, que vous pouvez utiliser pour désactiver dynamiquement les serveurs et les vérifications d’état, modifier les poids d’équilibrage de charge des serveurs et utiliser d’autres leviers utiles.

user / group : Les lignes utilisateur et groupe indiquent à HAProxy de supprimer les privilèges après l’initialisation. Linux exige que les processus soient root pour écouter sur les ports inférieurs à 1024. Vous souhaiterez également généralement que vos clés privées TLS ne soient lisibles que par root. Sans définir un utilisateur et un groupe pour continuer le processus, HAProxy conservera les privilèges root, ce qui est une mauvaise pratique. Sachez que HAProxy lui-même ne crée pas l’utilisateur et le groupe et qu’ils doivent donc être créés au préalable.

Description de defaults

log global : Le paramètre global de journal est un moyen d’indiquer à chaque interface suivante d’utiliser le paramètre de journal que vous avez défini dans la section globale. Cela n’est pas nécessaire pour la journalisation, car de nouvelles lignes de journal peuvent être ajoutées ici ou dans chaque interface. Cependant, dans la plupart des cas où un seul serveur syslog est utilisé, c’est courant.

mode : Le paramètre de mode définit si HAProxy fonctionne comme un simple proxy TCP ou s’il est capable d’inspecter les messages HTTP de niveau supérieur du trafic entrant. L’alternative à la spécification du mode http est d’utiliser le mode tcp.

option httplog : L’option httplog, ou plus rarement l’option tcplog, indique à HAProxy d’utiliser un format de journal plus détaillé lors de l’envoi de messages à Syslog. Vous préférerez généralement l’option httplog à l’option tcplog dans votre section par défaut car lorsque HAProxy rencontre un frontend qui utilise le mode tcp, il émettra un avertissement et le rétrogradera de toute façon vers l’option tcplog.

option dontlognull : HAProxy se connecte régulièrement aux systèmes pour s’assurer qu’ils sont toujours en vie. Par défaut, même une simple sonde ou analyse de port produira un journal. Si ces connexions polluent les logs trop, il est possible d’activer l’option “dontlognull” pour indiquer qu’une connexion sur laquelle aucune donnée n’a été transférée ne sera pas enregistrée, ce qui correspond généralement à ces sondes. Notez que les erreurs seront toujours retourné au client et pris en compte dans les statistiques. Si ce n’est pas ce que souhaité, l’option http-ignore-probes peut être utilisée à la place.

timeout connect / timeout client / timeout server : Le paramètre de connexion au délai d’expiration configure la durée pendant laquelle HAProxy attendra qu’une connexion TCP à un serveur principal soit établie. Le suffixe «s» désigne les secondes. Sans suffixe, l’heure est supposée être en millisecondes. Le paramètre de délai d’expiration du client mesure l’inactivité pendant les périodes pendant lesquelles on s’attend à ce que le client parle, ou en d’autres termes envoie des segments TCP. Le paramètre de serveur de temporisation mesure l’inactivité lorsque nous nous attendons à ce que le serveur principal parle. Lorsqu’un délai expire, la connexion est fermée. Le fait d’avoir des délais d’expiration raisonnables réduit le risque que des processus bloqués bloquent des connexions qui pourraient autrement être réutilisées.

errorfile : Spécifie les message d’erreurs à retourner en cas d’erreur http 400 ou 500.

Description de frontend

bind : Un paramètre de liaison affecte un écouteur à une adresse IP et un port donnés. L’IP peut être omis pour se lier à toutes les adresses IP sur le serveur et un port peut être un port unique, une plage ou une liste délimitée par des virgules. Vous utiliserez souvent les arguments ssl et crt pour indiquer à HAProxy de gérer les terminaisons SSL / TLS, plutôt que de laisser vos serveurs Web le faire.

use_backend : Ce paramètre choisit un pool de serveurs backend pour répondre aux demandes entrantes si une condition donnée est vraie. Il est suivi d’une instruction ACL, telle que if path_beg / api /, qui permet à HAProxy de sélectionner un backend spécifique en fonction de certains critères, comme vérifier si le chemin commence par / api /. Ces lignes ne sont pas obligatoires et de nombreuses sections frontend n’ont qu’une ligne default_backend et aucune règle de sélection spéciale. (Cette option n’est pas utilisée dans l’exemple ci-dessus.)

default_backend : Le paramètre default_backend donne le nom d’un backend auquel envoyer le trafic si une règle use_backend ne l’envoie pas ailleurs en premier. Si une demande n’est pas acheminée par une directive use_backend ou default_backend, HAProxy renverra une erreur 503 Service non disponible.

option httpclose : Si cette option est défini, HAProxy fermera les connexions avec le serveur et le client dès réception de la demande et de la réponse. Il sera vérifié également si un en-tête “Connection: close” est déjà défini dans chaque direction, et en ajoutera un s’il manque. Tout en-tête “Connection” différent de “close” sera également supprimé.

Description de backend

balance : Le paramètre de balance contrôle la manière dont HAProxy sélectionnera le serveur pour répondre à la demande si aucune méthode de persistance ne remplace cette sélection. Une méthode de persistance peut consister à toujours envoyer un client particulier au même serveur en fonction d’un cookie. Les valeurs d’équilibrage de charge courantes incluent roundrobin, qui sélectionne simplement le serveur suivant et recommence en haut de la liste, et leastconn, où HAProxy sélectionne le serveur avec le moins de sessions actives.

option httpchk : Le paramètre d’option httpchk oblige HAProxy à envoyer des vérifications de l’état de la couche 7 (HTTP) au lieu des vérifications de la couche 4 (TCP) à vos serveurs principaux. Les serveurs qui ne répondent pas ne reçoivent plus de demandes. Alors que les vérifications TCP réussissent s’ils sont en mesure de se connecter à l’IP et au port du serveur principal, les vérifications d’intégrité HTTP s’attendent à obtenir une réponse HTTP réussie. Des vérifications de l’état plus intelligentes sont essentielles pour supprimer les serveurs qui ne répondent pas, même s’ils ne répondent pas, cela signifie simplement obtenir une mauvaise réponse HTTP comme 500 Server Error.

server : Le paramètre du serveur est au cœur du backend. Son premier argument est un nom, suivi de l’adresse IP et du port du serveur principal. Vous pouvez spécifier un nom de domaine au lieu d’une adresse IP. Dans ce cas, il sera résolu au démarrage ou, si vous ajoutez un argument résolveurs, il sera mis à jour pendant l’exécution. Si l’entrée DNS contient un enregistrement SRV, le port et le poids seront également renseignés à partir de celui-ci. Si le port n’est pas spécifié, HAProxy utilisera le même port que celui sur lequel le client s’est connecté, ce qui est utile pour les ports utilisés de manière aléatoire, comme pour le FTP en mode actif.

stats : HAProxy permet d’obtenir une page web de statistique définit avec l’option stats. L’uri permet de spécifier avec quel nom d’url, on aura accès à cette ressource. Cet accès est protégé par un login et un mot de passe définit avec l’option “auth” et le “refresh” permet de déterminer le temps de rafraichissement. On pourra définir plusieurs pages de statistiques en fonction des backend.

sources : haproxy.com