Blog / Article #133

Traefik + Compose en plugin : et si on ajoutait un peu de piment à la stack ?

Traefik a récemment fait un petit clin d'œil à la communauté en intégrant docker compose directement en tant que plugin. Une bonne nouvelle pour ceux qui aiment garder leurs outils simples et efficaces, sans se lancer dans des usines à gaz. Mais une fois ce plugin installé, on se demande : et maintenant, quoi ? Parce que oui, Traefik est déjà un couteau suisse, mais comme tout couteau suisse qui se respecte, il a besoin de quelques lames supplémentaires pour briller vraiment.

Pourquoi des plugins, déjà ?

Traefik est conçu pour être léger et modulaire. Son approche par plugins permet d'ajouter des fonctionnalités sans alourdir le cœur du reverse proxy. C'est un peu comme acheter une voiture avec un moteur solide, puis choisir ses options : climatisation, sièges chauffants, ou pourquoi pas un système audio qui fait vibrer les voisins à trois rues à la ronde. Sauf qu'ici, on parle de monitoring, de logging, ou de gestion automatique des conteneurs. Moins fun, mais bien plus utile.

Le plugin docker compose est une première étape logique : il permet de gérer les services définis dans un docker-compose.yml directement depuis Traefik, sans avoir à jongler entre plusieurs outils. Mais une fois cette base posée, il est temps de se demander quels autres plugins méritent de rejoindre la stack. En realité tous ne valent pas le coup, et certains sont même à éviter comme la peste.

Watchtower : le majordome qui fait le sale boulot

Si vous avez déjà passé une soirée à mettre à jour manuellement vos conteneurs Docker, vous savez à quel point c'est aussi excitant que de regarder de la peinture sécher. Watchtower est là pour ça : ce plugin surveille vos images et met à jour vos conteneurs automatiquement dès qu'une nouvelle version est disponible. Pas de downtime, pas de stress, juste un petit docker pull en arrière-plan et hop, tout est à jour.

Pour l'installer, rien de plus simple : un conteneur Docker à lancer, et c'est parti. Voici un exemple de configuration basique :

version: '3.8'
services:
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - WATCHTOWER_CLEANUP=true
      - WATCHTOWER_POLL_INTERVAL=300
    restart: unless-stopped

Avec cette config, Watchtower vérifie toutes les 5 minutes si une nouvelle image est disponible pour vos conteneurs. Le paramètre WATCHTOWER_CLEANUP supprime les anciennes images après la mise à jour, histoire de ne pas encombrer votre disque. Simple, efficace, et surtout, ça évite de se réveiller un matin avec une stack obsolète parce qu'on a oublié de faire un docker pull.

Attention tout de même : Watchtower ne fait pas de magie. Si votre application a des breaking changes entre deux versions, vous risquez de vous retrouver avec un joli plantage. À utiliser avec parcimonie, donc, et idéalement en combinaison avec des tests automatisés.

Autoheal : le médecin de garde pour vos conteneurs

Parce que même les meilleurs conteneurs finissent par tomber en panne, Autoheal est là pour les relancer automatiquement quand ils décident de faire grève. Ce plugin surveille l'état de vos conteneurs et les redémarre si leur healthcheck échoue. C'est un peu comme avoir un médecin de garde qui passe toutes les 5 minutes pour vérifier que tout le monde respire encore.

Là encore, la configuration est minimaliste :

version: '3.8'
services:
  autoheal:
    image: willfarrell/autoheal
    container_name: autoheal
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - AUTOHEAL_CONTAINER_LABEL=all
    restart: unless-stopped

Avec cette config, Autoheal surveille tous les conteneurs qui ont un healthcheck défini. Si un conteneur échoue à son healthcheck, il est automatiquement redémarré. C'est simple, mais diablement efficace pour éviter les downtimes inutiles. Bien sûr, ça ne résout pas les problèmes de fond (si votre application plante à cause d'un bug, Autoheal ne fera que retarder l'inévitable), mais c'est un filet de sécurité bienvenu.

Un petit bémol : Autoheal ne fait pas de distinction entre un conteneur qui plante à cause d'un bug et un conteneur qui est volontairement arrêté pour maintenance. Si vous utilisez des outils comme docker stop pour des opérations manuelles, assurez-vous de désactiver temporairement Autoheal pour éviter les redémarrages intempestifs.

Logging et monitoring : parce que deviner, c'est has been

Si vous en êtes encore à deviner pourquoi votre application plante en regardant les logs avec docker logs -f, il est temps de grandir. Traefik propose des plugins pour centraliser les logs et le monitoring, et franchement, c'est une bénédiction.

Parmi les options les plus populaires, on trouve traefik-plugin-loki pour envoyer les logs vers Grafana Loki, et traefik-plugin-prometheus pour exposer des métriques à Prometheus. Ces outils permettent de visualiser ce qui se passe dans votre infrastructure, d'identifier les goulots d'étranglement, et surtout, de ne plus avoir à jouer aux devinettes quand quelque chose ne tourne pas rond.

Voici un exemple de configuration pour traefik-plugin-prometheus :

http:
  middlewares:
    prometheus:
      plugin:
        prometheus:
          buckets:
            - 0.1
            - 0.3
            - 1.2
            - 5.0

Avec cette config, Traefik expose des métriques au format Prometheus, que vous pouvez ensuite visualiser dans Grafana. C'est un peu technique, mais une fois en place, vous ne pourrez plus vous en passer. Parce que oui, deviner pourquoi votre API répond en 5 secondes au lieu de 50 millisecondes, c'est sympa cinq minutes, mais après, ça lasse.

Pour les logs, traefik-plugin-loki se configure de manière similaire :

http:
  middlewares:
    loki:
      plugin:
        loki:
          addr: http://loki:3100/loki/api/v1/push
          labels:
            - "traefik"

Ici, les logs sont envoyés vers un serveur Loki, que vous pouvez ensuite interroger avec LogQL pour retrouver ce fameux message d'erreur qui vous empêche de dormir depuis trois nuits. Parce que oui, les logs, c'est comme les chaussettes : si vous ne les rangez pas, vous finissez par en perdre une paire.

Les plugins à éviter : ceux qui promettent monts et merveilles (et livrent des cailloux)

Tous les plugins ne se valent pas. Certains sont mal maintenus, d'autres sont surcotés, et quelques-uns sont juste là pour faire joli. Parmi les plugins à éviter, on trouve :

• traefik-plugin-geoip : Théoriquement utile pour bloquer le trafic en fonction de la géolocalisation, mais en pratique, c'est souvent plus compliqué qu'efficace. Les bases de données GeoIP sont rarement à jour, et les faux positifs sont légion. Si vous voulez vraiment bloquer des pays, utilisez un WAF ou un CDN, pas un plugin Traefik.
• traefik-plugin-oauth2 : Intégrer OAuth2 directement dans Traefik, c'est tentant, mais c'est aussi une mauvaise idée. Les flux OAuth2 sont complexes, et les gérer dans un reverse proxy, c'est comme essayer de faire un nœud papillon avec une seule main : ça finit toujours en catastrophe. Utilisez plutôt un service dédié comme Keycloak ou Auth0.
• traefik-plugin-letsencrypt-cloudflare : Certes, c'est pratique pour automatiser les certificats Let's Encrypt avec Cloudflare, mais c'est aussi une usine à gaz. Si vous utilisez déjà cert-manager ou un autre outil dédié, ne vous embarquez pas dans cette aventure. La simplicité, c'est la clé.

En résumé : un plugin, c'est comme un bon vin. Certains se bonifient avec le temps, d'autres finissent en vinaigre. Choisissez-les avec soin, et surtout, testez-les avant de les intégrer à votre stack de production.

Conclusion : moins de plugins, plus de sérénité

Traefik est un outil puissant, et ses plugins permettent d'étendre ses fonctionnalités sans alourdir son cœur. Mais comme pour tout outil, la modération est de mise. Watchtower et Autoheal sont des valeurs sûres pour automatiser les tâches répétitives, tandis que les plugins de logging et de monitoring sont indispensables pour garder un œil sur ce qui se passe dans votre infrastructure. En revanche, évitez les plugins qui promettent de tout faire à votre place : ils finissent souvent par compliquer les choses plus qu'ils ne les simplifient.

En fin de compte, une stack bien pensée est une stack qui reste simple. Ajoutez des plugins quand ils apportent une réelle valeur, et laissez tomber ceux qui ne font que rajouter du bruit. Parce qu'au final, le but, c'est de passer moins de temps à gérer votre infrastructure, et plus de temps à coder, à boire du café, ou à regarder des vidéos de chats sur Internet. Et ça, aucun plugin ne pourra jamais le faire à votre place.