Depuis 7 ou 8 ans j’utilise HAProxy sur mon infra perso. Il y a peu, je me suis lancé dans le remplacement de HAProxy par Caddy, voici quelques notes concernant ce choix.

Initialement, ce choix était motivé par plusieurs raisons:

  • j’envisageais de distribuer la charge de certains services sur plusieurs backends;
  • je souhaitais tester certaines configurations de HAProxy;
  • je voulais utiliser ce dernier pour exposer d’autres services que des services Web.

Finalement, c’est surdimensionné et peu adapté à mes besoins. Par exemple, dans ma configuration HAProxy, j’ai plusieurs frontend avec un seul backend, et je n’ai aucun besoin de HA sur mes services perso.

De plus lors de la mise en place de HAProxy, j’avais dû réaliser quelques bidouilles pour la gestion des certificats. Pour la mise en place des terminaisons TLS, j’avais utilisé des ACL pour répondre au challenge ACME (de Let’s Encrypt, cette solution semble aussi utilisée par d’autres).

frontend http-in
    ...
    option forwardfor
    acl letsencrypt-acl path_beg /.well-known/acme-challenge/
    use_backend letsencrypt-backend if letsencrypt-acl
    default_backend http-redirect
...
backend letsencrypt-backend
    mode http
    option forwardfor
    server letsencrypt 127.0.0.1:8888 check port 8888

L’idée était de rediriger les requêtes de validation vers un serveur web local dont l’unique responsabilité était d’exposer les réponses aux challenges ACME.

Par curiosité et pour me simplifier la tâche, j’ai décidé de remplacer HAProxy par Caddy. En effet ce dernier permet, de base, d’intégrer la gestion des certificats, de configurer automagiquement la partie HTTPs et est utilisable en tant que “simple” serveur HTTP. Avec Caddy, fini la gymnastique avec un backend dédié à Let’s Encrypt.

Pour être honnête, les versions récentes de HAProxy permettent de gérer le protocole ACME nativement, mais cela nécessite un peu + de configuration qu’avec Caddy.

Par exemple, avec Caddy définir un vhost avec du https corredpond à la configuration minimale suivante :

    blog.piweb.be {
      reverse_proxy wwwstatic-prod-virtsrv-01.prod.machin.local
    }

Ensuite, de base, Caddy va se charger de la partie certificat en utilisant l’approche suivante:

  • Génération d’une clé privée locale et une demande de signature de certificat (CSR)
  • Choix de l’autorité de certification (CA), par défaut Let’s Encrypt
  • Résolution du challenge (via HTTP-01, sur le port 80 dans mon cas)
  • Enregistrement du certificat et mise en place de la terminaison SSL

Avec mon ancienne configuration, ces divers étapes étaient réalisées par plusieurs composants:

  • dehydrated pour la partie génération des demandes certificats;
  • HAProxy + NGINX pour la partie challenge;
  • un script (dans un cron) maison pour mettre les certificats au bon endroit et rechargé HAProxy.

Pour conclure, je pense que HAProxy est une excellente option pour des configurations avancées, mais il me semble un peu trop complexe pour les quelques services que j’héberge ici. Pour l’instant, je suis satisfait de Caddy; on verra si je l’utilise aussi longtemps en « production » que j’ai utilisé HAProxy.