Traefik: la porte d'entrée du LABO

Docker nous permet maintenant d'exécuter nos services dans des conteneurs isolés. Mais il reste une question essentielle : comment une requête provenant d'Internet va-t-elle trouver le bon service ?
C'est le rôle de Traefik. Il constituera la porte d'entrée HTTP/HTTPS du LABO et assurera notamment le routage vers les différents services ainsi que la gestion des certificats TLS.

1. Les entryPoints

Traefik doit d'abord savoir sur quels ports il doit écouter. Pour notre architecture, les deux points d'entrée principaux sont web pour HTTP et websecure pour HTTPS.

Le port 80 reçoit les requêtes HTTP et le port 443 reçoit les requêtes HTTPS. Ces deux ports seront donc les points d'entrée publics de notre architecture.

entryPoints:
  web:
    address: ":80"

  websecure:
    address: ":443"

À ce stade, Traefik sait donc où écouter. Il ne sait pas encore quels services doivent recevoir les requêtes.

2. Traefik doit connaître Docker

Notre environnement est construit autour de Docker. Traefik doit donc pouvoir observer les conteneurs présents sur le serveur et récupérer les informations nécessaires pour construire son routage.
C'est le rôle du provider Docker.

providers:
  docker:
    endpoint: "unix:///var/run/docker.sock"
    exposedByDefault: false

Le paramètre exposedByDefault: false est important. Il signifie que Traefik ne considérera pas automatiquement tous les conteneurs comme accessibles depuis Internet. Nous choisirons explicitement les services qui doivent être exposés.

3. Le label traefik.enable

La communication entre Docker et Traefik devient particulièrement intéressante lorsque nous utilisons les labels Docker.

labels:
  - "traefik.enable=true"

Nous pouvons alors ajouter d'autres labels pour définir le domaine, le routeur, le service et le port interne à utiliser.
Cette approche évite de devoir modifier manuellement une configuration globale de Traefik chaque fois qu'un nouveau service Docker apparaît.

4. Comment Traefik sait-il quel domaine utiliser ?

Le navigateur ne demande pas simplement « donne-moi n8n ». Il demande une adresse précise, par exemple un domaine ou un sous-domaine.
Traefik peut utiliser cette information pour déterminer vers quel service la requête doit être envoyée.

labels:
  - "traefik.http.routers.n8n.rule=Host(`n8n.exemple.be`)"

Le routeur examine donc la requête entrante et applique la règle correspondant au domaine demandé.

Le principe est simple : le domaine demandé permet à Traefik de choisir la bonne route, puis cette route dirige la requête vers le service Docker correspondant.

5. Le réseau Docker proxy

Traefik doit maintenant pouvoir communiquer avec les services qu'il expose. Nous utilisons pour cela un réseau Docker dédié, appelé proxy.

Les conteneurs qui doivent être accessibles par Traefik rejoignent ce réseau. Les autres services peuvent rester sur leurs propres réseaux internes.

docker network create proxy

Dans notre architecture, Traefik et un service comme n8n pourront donc communiquer à travers ce réseau sans que n8n ait besoin d'exposer directement son port au serveur Internet.

6. Traefik et les ports des conteneurs

Il faut maintenant distinguer deux notions qui sont souvent confondues : le port public du serveur et le port interne du conteneur.

Par exemple, n8n utilise généralement son port interne 5678. Ce port n'a pas besoin d'être directement exposé sur Internet lorsque Traefik joue le rôle de reverse proxy.

labels:
  - "traefik.http.services.n8n.loadbalancer.server.port=5678"

Le port 443 peut donc être public, tandis que le port 5678 de n8n reste un port interne au réseau Docker.

7. HTTPS: le moment où Traefik devient vraiment intéressant

Jusqu'ici, nous avons surtout vu comment recevoir une requête et la diriger vers un conteneur. Mais un service accessible depuis Internet doit également pouvoir être servi en HTTPS.
Traefik peut automatiser la gestion des certificats grâce à ACME et à Let's Encrypt.

L'objectif est de permettre au navigateur d'établir une connexion HTTPS sécurisée avec notre service sans devoir créer manuellement chaque certificat.

8. Le challenge HTTP

Pour obtenir un certificat, l'autorité de certification doit vérifier que nous contrôlons réellement le domaine demandé.

Avec le challenge HTTP-01, cette validation passe par une requête HTTP sur le port 80.

Cela explique pourquoi le port 80 doit rester accessible depuis Internet même lorsque notre objectif final est de servir les applications en HTTPS.

9. Le certResolver

Traefik utilise un certResolver pour définir le mécanisme utilisé afin d'obtenir les certificats.
Dans notre configuration, nous utiliserons un resolver appelé le.

certificatesResolvers:
  le:
    acme:
      httpChallenge:
        entryPoint: web

Le nom le n'est pas imposé par Traefik. C'est simplement le nom que nous avons choisi pour identifier ce resolver dans notre configuration.

10. Où Traefik conserve-t-il les certificats ?

Les certificats obtenus automatiquement doivent être conservés de manière persistante. Ils ne doivent pas disparaître lorsque le conteneur Traefik est recréé.
Nous utiliserons donc un volume ou un répertoire persistant associé au stockage ACME.

volumes:
  - ./letsencrypt:/letsencrypt

Traefik peut ainsi conserver les informations nécessaires entre deux redémarrages ou recréations du conteneur.

11. Le chemin complet d'une requête

Nous pouvons maintenant réunir les différents éléments que nous venons de découvrir.

Le navigateur ne connaît donc pas le port interne de n8n. Il connaît uniquement son domaine HTTPS. C'est Traefik qui fait le lien entre les deux.

12. Pourquoi cette architecture va nous servir longtemps

Cette organisation ne concerne pas uniquement n8n.

Chaque nouveau service pourra être ajouté derrière Traefik en définissant son domaine, ses règles de routage et son port interne. Le même principe pourra donc être utilisé pour les différents composants du LABO : n8n, Qdrant, AnythingLLM, Ollama, WordPress ou d'autres services que nous ajouterons par la suite.

L'intérêt est surtout architectural: le point d'entrée public reste centralisé, tandis que les services restent isolés dans Docker.

13. Vérifions que Traefik fonctionne

Avant de poursuivre avec les autres services, nous devons pouvoir vérifier simplement l'état du conteneur Traefik et consulter ses journaux.

docker ps

docker logs traefik

docker logs -f traefik

14. Un premier diagnostic

Lorsqu'un service derrière Traefik ne répond pas, il est préférable de vérifier les différents éléments dans un ordre logique plutôt que de modifier immédiatement la configuration.

Ce que nous venons réellement de construire

Traefik n'est donc pas simplement un serveur web placé devant Docker.
Nous avons mis en place une architecture dans laquelle un point d'entrée public centralise les connexions HTTP et HTTPS, identifie le service demandé et transmet ensuite la requête au bon conteneur.

Le réseau Docker proxy permet à Traefik de communiquer avec les services concernés sans que chacun d'eux ait besoin d'être directement exposé sur Internet. Enfin, ACME permet d'automatiser l'obtention et le renouvellement des certificats TLS.

Le résultat est une porte d'entrée unique pour le LABO : les domaines arrivent sur Traefik, Traefik détermine leur destination, puis Docker fournit le chemin interne vers le service concerné.

À retenir

Traefik centralise l'accès HTTP/HTTPS au LABO. Les domaines, les règles de routage, le réseau Docker proxy et les certificats TLS forment ensemble la couche d'accès de notre architecture.