Cas d’usage d’Haproxy pour déporter du trafic en fonction de l’URI
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 :
1 2 3 4 5 6 7 |
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 :
1 2 3 4 5 6 |
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 ?