blog.bressure.net

Depuis presque un an, mon finfra personnelle est passée à la conteneurisation avec Docker. Elle garde néanmoins un apache en guise de reverse proxy et terminaison TLS.

L’utilisation de apache seul permet de facilement discriminer sur nom de domaine pour rediriger le flux vers l’ip de la VM de production et le port exposé par le serveur qui est sous forme de conteneur docker. Exemple de configuration:

<VirtualHost *:443>
        ServerName  matomo.bressure.net
   
        SSLProxyEngine On
          ProxyPass "/" "http://192.168.122.30:8085/"
        ProxyPassReverse "/" "http://192.168.122.30:8085/"
        SSLCertificateFile    /etc/letsencrypt/live/matomo.bressure.net/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/matomo.bressure.net/privkey.pem
</VirtualHost>

Or un des objectifs de départ de la mise sous forme de conteneur était de permettre la scalabilité.

On voit sur le schéma précédent un exemple de scalabilité horizontale ou on ajoute des conteneurs au sein de la même VM pour répartir la charge sur plusieurs instances de l’application. On voit que un apache seul avec la configuration en exemple ne permettra pas d’adresser les multiples conteneurs qui exposent chacun un port différent sur la VM hôte.

L’extension de l’enveloppe d’une VM a des limites liées à l’OS comme par exemple le nombre de processus gérés. Il faudra pour aller plus loin déployer les conteneurs sur d’autres VM. On va donc avoir plusieurs IP. Encore une fois l’apache seul avec la configuration en exemple n’est pas adapté pour gérer cette répartition.

Certes il existe des configurations de type ferme de serveur qui permettent d’utiliser apache comme répartiteur de charge mais cela complexifie la configuration qui traite déjà 2 aspects: TLS et reverse proxy.

Répartiteur et routage intra VM par Traefik

Le premier type de scalabilité par extension de l’enveloppe de la VM peut être pris en charge par Traefik. Ce dernier pourrait être installé sous forme de conteneur qui s’exécute sur la VM en question. Le principe est que Traefik sera le seul à recevoir les requêtes et les routera vers les autres conteneurs en fonction du nom de domaine demandé ou de l’url. La plus value de Traefik est de gérer lui même la liaison avec les port exposées des conteneurs ce qui simplifie l’ajout de services. Un autre avantage est que Traefik sait faire de la répartition de charge. Ainsi si plusieurs conteneurs prétendent fournir le même service (via nom de domaine ou url), Traefik sera en mesure de répartir la charge entre ces conteneurs.

Répartiteur de charge inter VM par HAproxy

Cette fonction pourrait être occupé par Traefik par fichier de configuration mais je trouve que Traefik prend tout son sens par son mécanisme de découverte des services par écoute du démon docker. D’ailleurs il a été initialement fait pour ça, c’est-à-dire permettre d’accéder facilement sans configuration externe (comme avec mon reverse proxy apache) aux services exposés par des conteneurs.

HAproxy de sont côté offre des fonctionnalités poussées en terme de répartitions de charge au niveau TCP/HTTP. Ce qui ouvre plus de possibilités en terme de « proxification »

L’idée est d’utiliser un HAProxy pour faire la répartition entre plusieurs VM. L’ajout de VM étant une opération moins courante que l’ajout de services, la définition des fermes de serveurs pourra continuer à être manuelle dans mon infra.

Durant ces longues semaines de confinements, une migration de mon reverse proxy apache vers HAProxy/Traefik parait être une saine occupation à mes heures perdues.