HAProxy 3.2 : déploiement LTS sur Ubuntu/Debian, compilation et systemd

Table des matières :

1. HAProxy 3.2 LTS en 2026 : ce que la “branche LTS” change vraiment sur Ubuntu/Debian
2. Installer HAProxy 3.2 sur Ubuntu/Debian sans compilation : dépôts, pinning et upgrades contrôlés
3. Compiler HAProxy 3.2 sur Ubuntu/Debian : quand c’est justifié, et comment éviter un binaire “non reproductible”
4. systemd : service file propre, reload sans coupure, limites noyau et journaux
5. Configuration minimale “production” : TLS, headers, health checks, timeouts, stickiness
6. Exploitation : métriques Prometheus, socket d’admin, tests, rollout/rollback en conditions réelles

HAProxy 3.2 LTS en 2026 : ce que la “branche LTS” change vraiment sur Ubuntu/Debian

HAProxy 3.2 est présenté comme une version “LTS” : ça ne veut pas “magiquement” dire zéro risque, ça veut dire une stratégie de patching plus stable (moins de churn fonctionnel) et une fenêtre de maintenance adaptée aux plateformes e-commerce qui ne peuvent pas se permettre de réapprendre un comportement à chaque montée de version. Concrètement, l’intérêt “LTS” se joue surtout sur trois points :

• Correctifs de sécurité et de stabilité backportés sans vous imposer un saut de version majeur au moindre patch.
• Moins de changements de comportement (par exemple dans le parsing HTTP, TLS, ou certaines options dépréciées) par rapport à une branche “feature”.
• Meilleure prévisibilité opérationnelle : vous pouvez planifier des upgrades réguliers (mensuels/trim.) sans “re-qualification complète” à chaque fois.

Le problème côté Debian/Ubuntu, c’est que les dépôts officiels privilégient la stabilité de l’OS, pas celle de HAProxy : vous vous retrouvez vite avec une version en retard de plusieurs minor/major par rapport à la branche que vous visez. Ce décalage n’est pas “mauvais” en soi (c’est même l’objectif de Debian stable), mais il devient contraignant si vous avez besoin d’un fix précis (HTTP/2, QUIC selon versions, TLS, bugs L7) ou d’une fonctionnalité récente.

Le point technique qui casse le plus souvent un déploiement “je mets à jour et ça passe” est l’écosystème crypto/TLS, car HAProxy est fortement couplé aux versions d’OpenSSL (et donc aux ABI/librairies de la distribution). Ubuntu 24.04 LTS et Debian 12 (“bookworm”) sont basés sur OpenSSL 3.x : c’est une bonne base, mais ça impose d’être cohérent entre compilation, modules (Lua, PCRE2), et runtime. Si vous compilez en liant dynamiquement contre des libs qui bougent (ex. backports OpenSSL), vous devez traiter HAProxy comme un artefact applicatif versionné, pas comme un paquet “oubliable”.

Un réflexe simple qui évite des heures de diagnostic : vérifier explicitement ce que vous exécutez, pas ce que vous croyez avoir installé.

haproxy -vv | sed -n '1,60p'
ldd "$(command -v haproxy)" | egrep -i 'ssl|crypto|pcre|lua|zlib' || true

Pour cadrer le rôle exact de HAProxy, la documentation upstream est sans ambiguïté. Le manpage décrit le binaire ainsi : “HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.” (source : haproxy(1), distribution upstream et paquets Linux). Cette définition est utile en pratique : vous n’êtes pas en train d’installer “un serveur web”, mais un proxy et load balancer qui va absorber la complexité réseau (TLS, HTTP/2, ACL, health checks, retries).

Côté “réalité e-commerce” (France/UE), le sujet n’est pas seulement technique : le proxy est une couche qui peut impacter directement votre taux de conversion. Un mauvais réglage (timeout, keep-alive, file descriptors, health checks trop agressifs) peut créer des erreurs sporadiques pendant un pic (soldes, Black Friday, campagne média), exactement au moment où la pression business est maximale. À titre d’ordre de grandeur, la FEVAD publie chaque année un bilan du e-commerce français ; les montants annuels se chiffrent en centaines de milliards d’euros, ce qui illustre pourquoi les incidents “edge” (reverse proxy/LB) sont disproportionnellement coûteux (FEVAD, bilan annuel du e-commerce, dernières éditions).

Pour les aspects “reverse proxy TLS, rate limiting, Prometheus”, vous pouvez compléter avec l’article interne : HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus. Et pour les options/bonnes pratiques à jour par version, gardez en favori la documentation officielle : https://docs.haproxy.org/.

Installer HAProxy 3.2 sur Ubuntu/Debian sans compilation : dépôts, pinning et upgrades contrôlés

Si votre objectif est un déploiement rapide et maintenable, privilégiez un paquet APT signé plutôt qu’une compilation “one-shot”. En 2026, la source la plus courante côté Debian/Ubuntu pour des versions récentes de HAProxy est le dépôt communautaire maintenu par Vincent Bernat : https://haproxy.debian.net/. L’intérêt est double : vous gardez une intégration standard (systemd, chemins, logrotate), et vous évitez de maintenir vous-même la chaîne de build à chaque correctif de sécurité.

Procédure type (à adapter à votre codename). Exemple pour Debian 12 (bookworm) ; remplacez bookworm par votre codename (jammy, etc.) et vérifiez sur haproxy.debian.net le suffixe exact de la suite HAProxy 3.2 :

sudo apt update
sudo apt install -y curl gpg ca-certificates

sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://haproxy.debian.net/bernat.debian.org.gpg \
  | sudo gpg --dearmor -o /etc/apt/keyrings/haproxy.debian.net.gpg

CODENAME=bookworm
# Exemple de suite ; validez la suite exacte sur haproxy.debian.net
echo "deb [signed-by=/etc/apt/keyrings/haproxy.debian.net.gpg] https://haproxy.debian.net ${CODENAME}-backports-3.2 main" \
  | sudo tee /etc/apt/sources.list.d/haproxy.list

sudo apt update
sudo apt install -y haproxy
haproxy -vv | head -n 30

Le point à ne pas rater : si vous introduisez un dépôt “plus récent” uniquement pour HAProxy, faites du pinning APT pour éviter d’aspirer d’autres paquets (OpenSSL, libc…) par effet de bord. Exemple minimaliste :

sudo tee /etc/apt/preferences.d/99-haproxy-pin <<'EOF'
Package: haproxy
Pin: origin haproxy.debian.net
Pin-Priority: 900
EOF

Dans la pratique, deux contrôles simples rendent les upgrades beaucoup plus sûrs :

• Vérifier l’origine et la version candidate, avant d’installer :

  apt-cache policy haproxy
  apt-cache madison haproxy | head

• Simuler une mise à jour (utile si vous avez plusieurs dépôts/backports) :

  sudo apt -s install haproxy

Si vous avez une contrainte forte de stabilité (ex. edge en production avec SLA interne), vous pouvez aussi encadrer le risque via une procédure “upgrade contrôlé” :

Checklist upgrade HAProxy (paquet APT)

• [ ] Export/commit de la config HAProxy (Git tag) avant intervention.
• [ ] haproxy -c -V -f /etc/haproxy/haproxy.cfg doit passer.
• [ ] Fenêtre de maintenance + plan de rollback (version N-1) documenté.
• [ ] apt-cache policy haproxy vérifié (candidat attendu).
• [ ] Reload (pas restart) si possible, puis monitoring 15–30 min (5xx, latences, erreurs TLS).

Côté ops, gardez en tête que les 503 et les timeouts “aléatoires” après upgrade sont souvent des regressions de config (timeouts, options HTTP, TLS) plus que des bugs HAProxy. Ayez une procédure de diagnostic : logs, saturation FD, backlog, health checks, et corrélation avec le backend. Sur ce volet, l’article interne Erreur HTTP 503 : diagnostic serveur, logs et ressources sert de checklist transposable au proxy.

Compiler HAProxy 3.2 sur Ubuntu/Debian : quand c’est justifié, et comment éviter un binaire “non reproductible”

La compilation a du sens dans trois cas : (1) vous voulez activer des features non présentes dans votre paquet (ex. options de build spécifiques, modules), (2) vous devez patcher/porter rapidement, (3) vous construisez un artefact pour une fleet homogène (image Packer, AMI, conteneur, etc.). Dans tous les autres cas, vous vous fabriquez une dette : chaque CVE OpenSSL, chaque update libpcre2, chaque changement d’ABI vous retombe dessus.

Un exemple très concret : sur un parc mixte (Debian 12 + Ubuntu 24.04), si vous compilez “à la main” sur une seule machine et que vous copiez le binaire ailleurs, vous pouvez créer des écarts subtils (OpenSSL, glibc, options de compilation). Résultat typique : un nœud fait du TLS correctement, un autre refuse des clients ou négocie différemment, et vous avez l’impression que “le réseau est instable” alors que vous avez simplement des artefacts différents.

Pré-requis recommandés (Debian 12 / Ubuntu 24.04, avec systemd) :

sudo apt update
sudo apt install -y \
  build-essential \
  libssl-dev \
  libpcre2-dev \
  zlib1g-dev \
  libsystemd-dev \
  liblua5.4-dev \
  pkg-config \
  wget

Téléchargement et build (exemple avec une 3.2.x ; remplacez la version par celle que vous visez) :

VER=3.2.1
wget https://www.haproxy.org/download/3.2/src/haproxy-${VER}.tar.gz
wget https://www.haproxy.org/download/3.2/src/haproxy-${VER}.tar.gz.sha256
sha256sum -c haproxy-${VER}.tar.gz.sha256

tar -xzf haproxy-${VER}.tar.gz
cd haproxy-${VER}

make -j"$(nproc)" \
  TARGET=linux-glibc \
  USE_OPENSSL=1 \
  USE_ZLIB=1 \
  USE_PCRE2=1 \
  USE_LUA=1 \
  USE_SYSTEMD=1

sudo make install PREFIX=/usr/local
/usr/local/sbin/haproxy -vv | head -n 40

Deux remarques importantes :

1) Vérification / provenance : validez hash et signature quand c’est possible, et archivez le tarball + hash dans votre chaîne CI. La discipline est la même que pour du code applicatif (voir l’approche “provenance” dans CI PrestaShop : provenance, SBOM et validation automatique des modules, transposable aux binaires infra).

2) Éviter le “/usr/local écrase tout” : conservez plusieurs versions (/usr/local/sbin/haproxy-3.2, symlink haproxy), documentez la marche arrière, et ne mélangez pas installation APT et binaire compilé sans une règle claire. Sur un e-commerce, un rollback rapide vaut plus qu’une optimisation marginale.

Un pattern simple (et très “ops-friendly”) consiste à isoler par version :

• binaire dans /opt/haproxy/3.2.1/sbin/haproxy
• symlink “courant” /opt/haproxy/current -> /opt/haproxy/3.2.1
• ExecStart=/opt/haproxy/current/sbin/haproxy ...

Ainsi, le rollback se résume à repointer un symlink + reload. Et vous pouvez garder N-1 en place sans toucher au système.

Enfin, gardez un œil sur les dépendances réellement embarquées : un binaire compilé sans OpenSSL statique va dépendre de libssl.so et libcrypto.so du système. Après une mise à jour de sécurité OpenSSL, c’est plutôt une bonne chose (vous bénéficiez du patch), mais cela signifie aussi qu’il faut tester rapidement le chemin TLS (négociation, chaînes, ciphers, tickets) sur un environnement de pré-prod.

systemd : service file propre, reload sans coupure, limites noyau et journaux

Si vous compilez HAProxy 3.2 avec USE_SYSTEMD=1, vous pouvez utiliser Type=notify et une intégration plus nette avec systemd (et donc des status plus fiables côté systemctl). Le manpage systemd rappelle l’intention du composant : “systemd is a system and service manager for Linux operating systems.” (source : systemd(1)). En clair : c’est systemd qui doit piloter le cycle de vie, pas des scripts ad hoc.

Exemple d’unité systemd (cas compilation /usr/local/sbin/haproxy). Le choix -W (master-worker) est pertinent en production : reload plus propre, gestion des sockets, et comportement stable sur HUP/USR2. Si vous utilisez Type=notify, vérifiez aussi le mode systemd côté HAProxy (selon versions, l’option -Ws est couramment utilisée pour le mode master-worker “systemd-aware”). Ajustez LimitNOFILE en fonction de votre trafic et des limites kernel (voir fs.file-max, net.core.somaxconn).

# /etc/systemd/system/haproxy.service
[Unit]
Description=HAProxy 3.2 LTS (reverse proxy / load balancer)
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
NotifyAccess=all

# Si vous n'utilisez pas le paquet distro, pensez à créer l'utilisateur/groupe haproxy.
User=haproxy
Group=haproxy

# Autoriser le bind sur ports <1024 (443) sans tourner root
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

# Validation stricte avant démarrage/reload
ExecStartPre=/usr/local/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg

# -W : master-worker ; -db : pas de daemonize (systemd gère) ; -p : pidfile
ExecStart=/usr/local/sbin/haproxy -W -db -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid

# Reload “soft” : valider puis demander au master de recharger (USR2)
ExecReload=/usr/local/sbin/haproxy -c -q -f /etc/haproxy/haproxy.cfg && /bin/kill -USR2 $MAINPID

Restart=on-failure
RestartSec=2s

RuntimeDirectory=haproxy
RuntimeDirectoryMode=0755

# À calibrer : connexion client + keep-alive + TLS = beaucoup de FD
LimitNOFILE=200000

[Install]
WantedBy=multi-user.target

Sur les limites noyau, l’objectif est d’éviter deux classes d’incidents très fréquents en pic de trafic :

• Backlog trop petit → connexions refusées/intermittentes (symptômes côté client : timeouts).
• Manque de file descriptors → erreurs “cannot open socket”, “too many open files”, et cascade de 5xx.

Commandes de vérification utiles (avant de “tuner”) :

sysctl net.core.somaxconn fs.file-max 2>/dev/null || true
ulimit -n
systemctl show haproxy -p LimitNOFILE
ss -s

Sur la partie logs, HAProxy historique parle syslog (/dev/log). Avec systemd, vous avez deux approches viables : (1) rester sur syslog/rsyslog pour conserver vos pipelines existants (ELK, Graylog), (2) loguer en stdout/journald si votre organisation est “systemd-first” (ou conteneurs). Quelle que soit l’approche, rendez le diagnostic trivialisable : journalctl -u haproxy -f doit vous permettre de corréler une vague de 5xx avec une saturation de backend, un timeout mal calibré, ou une explosion de connexions.

Astuce très pragmatique : ajoutez un identifiant de requête (si vous avez déjà une chaîne de logs applicatifs qui le supporte), afin de corréler proxy → PHP-FPM → MySQL. C’est souvent ce qui fait la différence entre “on soupçonne le réseau” et “on isole un endpoint lent”.

Configuration minimale “production” : TLS, headers, health checks, timeouts, stickiness

Une configuration HAProxy 3.2 “qui tourne” n’est pas une config “qui tient sous charge”. Pour un contexte PrestaShop, les erreurs classiques sont : (a) headers X-Forwarded-* incohérents → génération d’URLs HTTP au lieu de HTTPS, redirections en boucle, mixed content ; (b) timeouts trop agressifs côté client ou serveur → 504/499 (selon votre stack) sur des pages lourdes (checkout, recherche) ; (c) manque de stickiness si vous avez du state côté backend (sessions PHP non partagées).

Exemple minimal (terminaison TLS, HTTP/2, headers forward, health check) :

global
  log /dev/log local0
  user haproxy
  group haproxy
  master-worker
  stats socket /run/haproxy/admin.sock mode 660 level admin
  ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets

defaults
  mode http
  option httplog
  option http-keep-alive
  timeout connect 5s
  timeout client  60s
  timeout server  60s

frontend fe_https
  bind :443 ssl crt /etc/haproxy/certs/site.pem alpn h2,http/1.1

  option forwardfor
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-request set-header X-Forwarded-Port 443

  default_backend be_prestashop

backend be_prestashop
  balance roundrobin
  option httpchk GET /index.php
  http-check expect status 200
  server app1 10.0.0.11:80 check
  server app2 10.0.0.12:80 check

Quelques améliorations “production” qui valent souvent plus que des optimisations complexes :

• Health check réaliste mais léger : GET /index.php fonctionne, mais peut déclencher du traitement applicatif. Si vous pouvez exposer un endpoint très simple (ex. /healthz qui retourne 200 sans toucher la base), vos checks deviennent plus fiables et moins coûteux.
• Host header en check (si votre backend route par vhost) : certains stacks répondent 301/302 ou 404 sans Host.
• Timeouts basés sur des mesures : prenez 2–3 endpoints critiques (homepage cacheable, page produit, recherche, checkout) et mesurez p95/p99. Ensuite, choisissez des timeouts proxy qui ne coupent pas vos cas normaux tout en protégeant des backends “bloqués”.

Mini-scenario typique : pendant un pic (campagne Ads), la recherche interne devient lente (p95 à 2–3 s, p99 à 15–20 s). Avec timeout server 60s, vous tenez. Avec timeout server 10s, vous tenez pas et vous créez des erreurs côté clients qui ressemblent à un “bug PrestaShop”, alors que vous avez simplement un seuil trop bas au proxy.

Pour la stickiness, vous avez plusieurs stratégies. Si vous utilisez des sessions partagées (Redis, base), vous pouvez rester stateless au niveau proxy. Si ce n’est pas le cas, la stickiness par cookie est un compromis simple :

backend be_prestashop
  cookie SRV insert indirect nocache
  server app1 10.0.0.11:80 check cookie a1
  server app2 10.0.0.12:80 check cookie a2

Deux points d’attention souvent oubliés :

• La stickiness masque parfois un problème de fond (sessions non partagées, upload temporaire local, cache disque non mutualisé). Si vous l’activez, documentez pourquoi et fixez une cible (ex. “on retire la stickiness après migration sessions → Redis”).
• Si vous utilisez un CDN / WAF en amont, vérifiez la cohérence des IPs clients : option forwardfor aide, mais il faut aussi s’assurer que le backend n’interprète pas n’importe quel X-Forwarded-For si le trafic ne vient pas exclusivement du proxy.

Ne “devinez” pas vos timeouts : mesurez-les sur vos endpoints critiques. Un checkout peut dépasser 60s en cas de PSP lent, un rebuild d’index ou une recherche interne mal réglée peut exploser côté latence. Sur PrestaShop, ces symptômes ressemblent souvent à du “bug applicatif” alors que vous avez un timeout proxy ou backend mal dimensionné. Corrélez avec vos métriques PHP/MySQL (voir par exemple Performance PrestaShop : benchmarks et optimisation PHP-FPM, OPCache, MySQL pour la partie applicative, puis revenez calibrer HAProxy en conséquence).

Exploitation : métriques Prometheus, socket d’admin, tests, rollout/rollback en conditions réelles

En production, HAProxy 3.2 doit être observable comme n’importe quel composant critique : connexions actives, erreurs L7/L4, latences, saturation de queue, health checks. La socket d’admin (stats socket) est l’outil de base : vous pouvez interroger des stats, changer l’état d’un serveur, ou forcer un drain lors d’un déploiement. Protégez-la (permissions, groupe dédié) et évitez toute exposition réseau.

Deux commandes “terrain” (sans GUI) très utiles pour diagnostiquer vite :

• lister les frontends/backends et compteurs :

  echo "show stat" | sudo socat stdio /run/haproxy/admin.sock | head

• vérifier les erreurs par serveur (connect, response, etc.) :

  echo "show stat" | sudo socat stdio /run/haproxy/admin.sock | egrep 'be_prestashop|app1|app2' | head

Pour Prometheus, l’exporter intégré est pratique parce qu’il évite un sidecar fragile. Exemple d’endpoint local :

frontend fe_metrics
  bind 127.0.0.1:8404
  http-request use-service prometheus-exporter if { path /metrics }

Ensuite, vous branchez Prometheus et Grafana selon votre stack (sur VM, bare-metal, ou K8s). Si vous êtes déjà dans une approche “metrics-first”, les articles internes Prometheus sur Kubernetes OVHcloud : déployer kube-prometheus-stack avec Helm et Grafana sur Ubuntu : installation APT et configuration initiale posent des bases solides, même si HAProxy n’est qu’un des exporters.

En termes d’alerting, quelques signaux sont particulièrement actionnables (parce qu’ils pointent vers une cause probable) :

• montée de 5xx côté frontend → souvent backend saturé, timeout, ou erreur applicative
• qcur (queue current) qui augmente → manque de capacité backend ou maxconn trop bas
• erreurs de health checks → endpoint de check trop “lourd” ou dépendance (DB) indisponible
• conn_rate / sess_rate en explosion → campagne, bot, ou attaque (à corréler avec rate limiting/WAF)

Côté cycle de changement, imposez une discipline simple et fiable : (1) haproxy -c -V -f /etc/haproxy/haproxy.cfg en CI/CD avant déploiement, (2) reload systemd (USR2) avec un temps de drain raisonnable, (3) canary si vous avez plusieurs edge, (4) rollback binaire et rollback config (Git tag) en un seul geste.

Un rollout propre côté HAProxy, c’est aussi savoir “sortir” un backend sans casser les sessions en cours. Exemple (drain) via la socket admin :

# Mettre un serveur en maintenance (ne prend plus de nouvelles sessions)
echo "set server be_prestashop/app2 state maint" | sudo socat stdio /run/haproxy/admin.sock

# Le remettre en service
echo "set server be_prestashop/app2 state ready" | sudo socat stdio /run/haproxy/admin.sock

Ce n’est pas du luxe : en e-commerce, un proxy mal reloadé vous produit des 5xx en rafale et vous “tue” du CA avant même que l’équipe applicative comprenne ce qui se passe. Pour les architectures à trafic élevé (pics, soldes, campagnes), recoupez vos choix HAProxy avec votre stratégie globale d’HA et de capacité (voir PrestaShop pics de trafic : architecture cloud scalable et haute disponibilité).