Cas d’usage d’Haproxy pour déporter du trafic en fonction de l’URI

Posted on 20/11/2017 by Seboss666

Cet article a été publié il y a 6 ans 4 mois 30 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Haproxy est un outil toujours plus intéressant à mesure que je met les mains dedans (même si c’est parfois pénible, quand on manipule deux versions différentes dans la même journée — coucou la page de stats). Ici, j’aimerai vous présenter un petit cas pratique de séparation de traitement sur une même ferme en fonction de l’URI. Eh oui, c’est possible, et c’est super simple en fait.

Contexte

Le client propose, au travers de son site Web, une API REST, via une URL de type /rest/*. Rien de choquant me direz-vous, à part que le système n’est pas des plus performants (code maison pas super maîtrisé), et tend à ralentir le reste du site complet (car c’est bien PHP le consommateur dans l’histoire, la base de données qui se trouve sur un serveur à part fait très bien son boulot, quand elle en a à faire). Il dispose déjà de deux frontaux webs (Apache +PHP-FPM), derrière un load-balancer haproxy donc. Une solution est proposée de monter un troisième front qui sera dédié à l’API, pour ne plus impacter la consommation de CPU des pools principaux. Mais comme tout ce petit monde travaille sur le même domaine, et passe donc par Haproxy, plutôt que de jouer au dégueulasse avec des ProxyPass dans Apache, on peut faire ça bien, propre, élégant, au bon endroit.

ACL : magie magie…

Une fois n’est pas coutume on crée deux « backends » : un pour l’API, l’autre pour le reste du site :

backend site-api
    server rest 3.3.3.3:80 check

backend site-back
    balance source
    server web1 1.1.1.1:80 check
    server web2 2.2.2.2:80 check

backend site-api

server rest 3.3.3.3:80 check

backend site-back

balance source

server web1 1.1.1.1:80 check

server web2 2.2.2.2:80 check

Voilà, rien de super choquant, c’est pas super complet mais c’est pour l’exemple. Attardons nous maintenant sur le « frontend », car c’est à son niveau que l’on va finalement intervenir :

frontend site
    bind *:80
    mode http
    acl rest path_beg /rest/
    use_backend site-api if rest
    default_backend site-back

frontend site

bind *:80

mode http

acl rest path_beg /rest/

use_backend site-api if rest

default_backend site-back

Voilà, c’est aussi simple que ça (oui bon faut savoir que ça existe et faut se fader la doc qui est pas la plus claire du monde, j’avoue). Il faudra juste, si vous ajoutez des conditions (ou par exemple, une redirection vers HTTPS), faire attention à l’ordre des directives, mais si vous testez correctement la configuration, Haproxy vous préviendra de ce qui ne lui plaira pas.

Pleins d’usages possibles en fonction des applications

Ici, j’utilise les ACL pour des raisons fonctionnelles, le concept pourrait être le même pour séparer un back-office d’un front-office, pour présenter une versions légèrement différente de l’application en fonction de certains critères (pour faire du beta testing, ou que sais-je d’autres)… Mais pendant que je testais la solution, un autre cas d’usage m’est apparu via le Journal du Hacker qui va s’avérer pratique pour un autre de mes projets clients : la gestion d’un certificat Let’s Encrypt avec Haproxy. C’est présenté sous OpenBSD, mais finalement la solution fonctionne parfaitement sous Linux (j’ai utilisé nginx-light sous Debian), il suffit d’adapter très peu de chose, tel que le rechargement de configuration qui est évidemment différent.

Et vous, quel usage des ACL faites-vous dans Haproxy ?

Sysadmin acl, haproxy, Lets Encrypt, load-balancing, séparation