• 1 Votes
    1 Messages
    39 Vues
    I. Présentation

    Protégez vos services web avec Tinyauth : une solution open source légère, simple à déployer et idéale pour centraliser l’authentification dans votre Home Lab ou votre environnement Docker. Ce tutoriel explique comment installer et configurer Tinyauth en tant que middleware pour Traefik.

    Dans un Home Lab, multiplier les services web rime souvent avec multiplier les écrans de connexion, enfin, quand ils existent. Pour ajouter une authentification centralisée à toutes les applications, vous pouvez opter pour des solutions comme Authentik ou Keycloak. Au-delà de ces deux applications très connues, il y a Tinyauth : une approche légère et épurée de l’authentification, pensée pour protéger facilement vos services derrière un reverse proxy (Traefik, Nginx Proxy Manager, Caddy).

    Que ce soit dans un Home Lab, une petite infrastructure ou un environnement de dev, on peut rapidement se retrouver avec une multitude de services web : interfaces d’administration, outils internes, dashboards… C’est là que Tinyauth intervient. Couplé à Traefik, il permet d’unifier l’authentification sans mettre en place une usine à gaz. Tinyauth se place entre les utilisateurs et les conteneurs Docker pour afficher une page de login.

    Pour authentifier les utilisateurs, Tinyauth peut s’appuyer sur une base de comptes locale, utiliser OAuth (sur Google ou GitHub, par exemple) et même s’interfacer avec un annuaire LDAP (LLDAP, OpenLDAP, Active Directory).

    Note: l’intégration de Tinyauth avec vos services web Docker est basée sur le mécanisme de ForwardAuth de Traefik.

    II. Principe de fonctionnement : Traefik + Tinyauth

    Avant la partie pratique, clarifions le rôle de chacun des composants utilisés :

    Traefik : reverse proxy / load balancer qui reçoit les requêtes HTTP(S) et les route vers vos services (une boite à outils, un wiki, un site web, etc.). Tinyauth : service d’authentification et d’autorisation. Il reçoit les requêtes “à valider” de la part de Traefik en agissant comme un middleware, puis il authentifie l’utilisateur avant de répondre à Traefik.

    Le lien entre Traefik et Tinyauth se fait grâce au mécanisme ForwardAuth :

    Le client demande l’accès à un service web, par exemple : https://it-tools.it-connectlab.fr. Traefik intercepte la requête et l’envoie d’abord à Tinyauth (ForwardAuth). Tinyauth entre en action si l’utilisateur : n’est pas connecté, renvoie une redirection vers une page de login ; est connecté mais n’a pas les autorisations, renvoie une erreur (403 par exemple) ; est connecté et autorisé, il renvoie un 2xx avec éventuellement des en-têtes HTTP spécifiques. Traefik relaie alors la requête au service cible, en y ajoutant les en-têtes reçus.

    Vos applications n’ont pas besoin de gérer elles-mêmes l’authentification, c’est Tinyauth qui s’en charge en proposant un portail d’authentification.

    III. Installation de Tinyauth avec Docker

    Point de départ de cette démonstration : un serveur Linux (Debian) sur lequel Docker est installé. Un conteneur avec le reverse proxy Traefik est déjà en cours d’exécution, tout comme un conteneur avec l’application IT-Tools. Cette application est accessible, sans authentification, à l’adresse suivante : https://it-tools.it-connectlab.fr. Si vous souhaitez utiliser ce point de départ, suivez mon guide d’introduction à Traefik.

    L’objectif : protéger l’accès à IT-Tools en ajoutant une page de connexion gérée par Tinyauth.

    A. Créer le dossier pour le projet

    Nous allons commencer par créer un répertoire pour stocker les fichiers du projet Tinyauth :

    mkdir /opt/docker-compose/tinyauth B. Docker Compose Tinyauth

    À l’intérieur du répertoire créé précédemment, nous allons créer un fichier docker-compose.yml. Voici le code à insérer dans ce fichier :

    services: tinyauth: image: ghcr.io/steveiliop56/tinyauth:v4 container_name: tinyauth restart: unless-stopped networks: - frontend environment: - APP_URL=https://tinyauth.it-connectlab.fr - USERS=${USERS} - SECRET=${SECRET} - LOG_LEVEL=debug labels: - traefik.enable=true - traefik.http.routers.tinyauth.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth.entrypoints=web - traefik.http.routers.tinyauth-https.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth-https.entrypoints=websecure - traefik.http.routers.tinyauth-https.tls=true - traefik.http.routers.tinyauth-https.tls.certresolver=ovhcloud - traefik.http.services.tinyauth.loadbalancer.server.port=3000 - traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik networks: frontend: external: true

    Cette configuration crée un conteneur nommé tinyauth, connecté au réseau Docker frontend sur lequel est déjà connecté Traefik. L’application Tinyauth sera accessible via l’adresse https://tinyauth.it-connectlab.fr (APP_URL), à laquelle deux routers Traefik sont associés (un en HTTP, l’autre en HTTPS). Un certificat TLS Let’s Encrypt sera obtenu via le fournisseur de certificat ovhcloud, qui est configuré dans Traefik (c’est une interaction avec l’API OVHcloud pour gérer le challenge DNS du processus ACME).

    J’attire votre attention sur deux variables d’environnement pour lesquelles les valeurs seront stockées dans un fichier distinct :

    USERS = sert à déclarer, de façon statique, un ou plusieurs utilisateurs. SECRET = sert à signer et chiffrer les sessions ou les jetons (cookies) générés par Tinyauth.

    Enregistrez et fermez ce fichier.

    Vous devez générer une valeur aléatoire pour la variable SECRET. En ligne de commande, vous pouvez le faire à l’aide d’OpenSSL comme ceci : openssl rand -base64 32 | tr -dc 'a-zA-Z0-9' | head -c 32.

    Pour créer un utilisateur statique, vous avez besoin de deux informations : un nom d’utilisateur et un mot de passe, ou plutôt le hash BCrypt d’un mot de passe. Vous pouvez utiliser un outil en ligne pour obtenir cette information ou en ligne de commande, avec la commande mkpasswd, par exemple.

    apt install whois -y mkpasswd --method=bcryptPassword:# Saisissez le mot de passe en mode interactif et copiez la valeur obtenue.

    Voici un exemple de valeur obtenue (le point final fait partie de la valeur) : $2b$05$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.

    Vous pouvez alors constituer une chaine sous cette forme : <nom utilisateur>:<hash bcrypt>. Dans l’exemple ci-dessous, le nom du compte sera adm_fb.

    Créez un fichier nommé .env et ajoutez ce contenu :

    USERS=<nom utilisateur>:<hash bcrypt>SECRET=<la valeur obtenue avec la commande openssl> # Par exemple :USERS=adm_fb:$2b$05$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.SECRET=2BBUv0YFcZRoWMndmG9kaI3US5QU7u6Z

    J’ai eu des cas où il fallait doubler les $ dans la valeur du mot de passe pour que ça fonctionne. Ce qui donnerait :

    $$2b$$05$$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.

    Enregistrez et lancez la création du conteneur Docker TinyAuth :

    cd /opt/docker-compose/tinyauthdocker compose up -d IV. Protéger un service web avec Tinyauth

    Pour ajouter une page d’authentification à un service web exécuté dans un conteneur Docker, vous devez éditer le fichier Docker Compose de l’application en question. Ici, nous prenons l’exemple du service IT-Tools, donc nous allons éditer le fichier /opt/docker-compose/it-tools/docker-compose.yml.

    Dans la section dédiée aux labels Traefik, vous devez ajouter cette ligne pour lui associer le middleware Tinyauth :

    - traefik.http.routers.it-tools-https.middlewares=tinyauth

    Ce qui donne cette configuration complète :

    labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web - traefik.http.routers.it-tools-https.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools-https.entrypoints=websecure - traefik.http.routers.it-tools-https.tls=true - traefik.http.routers.it-tools-https.tls.certresolver=ovhcloud - traefik.http.routers.it-tools-https.middlewares=tinyauth

    Suite à cette modification, relancez le conteneur applicatif :

    cd /opt/docker-compose/it-toolsdocker compose downdocker compose up -d --build

    Tentez d’accéder à l’application web, ici représentée par l’adresse : https://it-tools.it-connectlab.fr. Au lieu d’avoir l’interface d’IT-Tools, la page de connexion Tiny Auth s’affiche :

    Donc, là, il n’y a plus le choix : il faut s’authentifier avec le compte renseigné dans le fichier .env.

    Une fois l’authentification réussie, le reverse proxy Traefik nous redirige vers l’application IT-Tools. La configuration est opérationnelle !

    V. Tinyauth et l’authentification OAuth

    Plutôt que d’utiliser une base de comptes locale, nous allons utiliser la méthode OAuth couplée à GitHub. Ainsi, il sera possible de s’authentifier auprès du portail Tinyauth à l’aide d’un compte GitHub.

    La première étape consiste à créer une nouvelle application OAuth sur GitHub (à partir de votre compte GitHub). Vous pouvez créer une application OAuth sur GitHub via la page github.com/settings/developers. Cliquez sur le bouton “New OAuth app”.

    – Vous devez ensuite :

    Spécifier un nom pour l’application Définir la Homepage URL, c’est-à-dire l’adresse de votre Tinyauth. Spécifier la callback URL, en utilisant l’adresse de Tinyauth + /api/oauth/callback/github.

    Voici un exemple :

    Vous arrivez sur la page de votre application. Cliquez sur le bouton “Generate a new client secret” pour générer un secret permettant d’utiliser cette application. Copiez le “Client ID” et “Client secret” car nous allons en avoir besoin par la suite.

    Éditez le fichier de configuration du conteneur Tinyauth :

    nano /opt/docker-compose/tinyauth/docker-compose.yml

    Puis, ajoutez ces trois variables d’environnement :

    - PROVIDERS_GITHUB_CLIENT_ID=${PROVIDERS_GITHUB_CLIENT_ID} - PROVIDERS_GITHUB_CLIENT_SECRET=${PROVIDERS_GITHUB_CLIENT_SECRET} - OAUTH_WHITELIST=${OAUTH_WHITELIST}

    Quelques explications s’imposent :

    PROVIDERS_GITHUB_CLIENT_ID : la valeur Client ID obtenue précédemment. PROVIDERS_GITHUB_CLIENT_SECRET : la valeur Client secret obtenue précédemment. PROVIDERS_GITHUB_CLIENT_ID : la liste des adresses e-mail de comptes GitHub autorisés à se connecter. Sinon, n’importe qui avec un compte GitHub peut s’authentifier sur votre portail.

    Puis, dans le fichier .env, configurez les variables d’environnement avec vos valeurs (ajoutez ces lignes à la suite de celles déjà présentes) :

    PROVIDERS_GITHUB_CLIENT_ID=Ov23liQVitconnectPROVIDERS_GITHUB_CLIENT_SECRET=e78bf94fb2ab4f16ditconnectitconnectOAUTH_WHITELIST=mon-utilisateur@it-connect.fr

    Enregistrez, puis relancez le conteneur Tinyauth :

    cd /opt/docker-compose/tinyauth/dodocker compose downdocker compose up -d --build

    Désormais, quand nous tentons une connexion à l’application, un nouveau bouton apparaît sur la page de connexion Tinyauth ! Il permet de s’authentifier avec GitHub, ce qui est plutôt de bonne augure !

    Il convient alors de préciser son nom d’utilisateur et son mot de passe.

    Puis, d’autoriser l’application Tinyauth à obtenir l’adresse e-mail et les informations du profil (en lecture seule). Ces informations peuvent aussi être relayées à l’application sur laquelle une connexion est tentée.

    Une fois l’authentification GitHub réussie, vous accédez à votre application !

    VI. Personnaliser l’interface de Tinyauth

    Tinyauth prend en charge plusieurs variables d’environnement que vous pouvez utiliser pour configurer votre instance, y compris pour personnaliser l’apparence. Vous pouvez notamment changer le titre et le fond d’écran. Voyons comment effectuer ces deux modifications.

    Ouvrez le fichier /opt/docker-compose/tinyauth/docker-compose.yml. Dans la section environment, ajoutez la variable APP_TITLE avec la valeur souhaitée pour le titre visible au-dessus du formulaire. Par exemple :

    - APP_TITLE=IT-Connect Lab

    Pour utiliser un fond d’écran personnalisé, vous avez deux options :

    Stocker l’image sur votre serveur et la monter dans le conteneur Tinyauth. Pointer vers l’image via une URL web, ce qui peut être une ressource externe hébergée sur un autre domaine.

    Dans le cas où vous souhaitez stocker l’image sur votre serveur, vous devez positionner le fichier sous /opt/docker-compose/tinyauth/ puis le monter dans le conteneur via l’ajout d’une ligne sous volumes. Par exemple :

    volumes: - ./wallpaper.jpg:/data/resources/wallpaper.jpg:ro

    Puis, dans la section environment, ajoutez deux lignes pour préciser le chemin vers le dossier disposant des ressources personnalisées (RESOURCES_DIR), puis le chemin vers le fichier image en lui-même (BACKGROUND_IMAGE). Voici un exemple (respectez bien ce format).

    - RESOURCES_DIR=/data/resources - BACKGROUND_IMAGE=/resources/wallpaper.jpg

    Relancez le conteneur avec la nouvelle configuration :

    docker compose downdocker compose up -d --build

    VII. Le contrôle d’accès avec Tinyauth

    Tinyauth intègre des fonctions pour le contrôle d’accès, notamment pour limiter l’accès à certains sous-domaines (ou certaines URL / chemins) uniquement à certains utilisateurs. Vous pouvez créer des règles basées sur les utilisateurs, les comptes OAuth, les chemins et les adresses IP (autoriser uniquement les connexions depuis une liste blanche d’adresses IP, par exemple).

    Dans tous les cas, Tinyauth doit pouvoir surveiller vos conteneurs et lire les labels (comme le fait Traefik). Vous devez donc ajouter ce volume dans la configuration de Tinyauth :

    volumes: - /var/run/docker.sock:/var/run/docker.sock:ro

    La configuration s’effectue ensuite au niveau de chaque application, grâce à un système de labels Tinyauth. Vous devez rajouter une ligne pour préciser le nom de domaine de l’application (bien que ce soit facultatif car Tinyauth prend par défaut le sous-domaine) et ensuite ajouter les ACL Tinyauth.

    L’exemple ci-dessous, positionné sur l’application IT-Tools, permet d’autoriser uniquement le compte adm_fb à accéder à cette application. Ici, on autorise explicitement un utilisateur (on peut aussi en préciser plusieurs), donc tous les autres seront interdits. Nous pouvons aussi faire l’inverse : tout autoriser et bloquer uniquement certains comptes, mais j’aime moins cette approche.

    labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web - traefik.http.routers.it-tools-https.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools-https.entrypoints=websecure - traefik.http.routers.it-tools-https.tls=true - traefik.http.routers.it-tools-https.tls.certresolver=ovhcloud - traefik.http.routers.it-tools-https.middlewares=tinyauth - tinyauth.apps.it-tools.config.domain=it-tools.it-connectlab.fr - tinyauth.apps.it-tools.users.allow=adm_fb

    Relancez les deux conteneurs… Puis, testez. Pour l’occasion, j’ai ajouté un second utilisateur nommé flo et qui, en principe, doit se voir l’accès refusé. Voici le résultat obtenu :

    D’autres exemples sont précisés dans la documentation officielle.

    VIII. Docker Compose Tinyauth - Exemple complet

    Pour finir, voici la configuration complète avec l’authentification GitHub et la personnalisation de l’interface Tinyauth :

    services: tinyauth: image: ghcr.io/steveiliop56/tinyauth:v4 container_name: tinyauth restart: unless-stopped networks: - frontend environment: - APP_URL=https://tinyauth.it-connectlab.fr - APP_TITLE=IT-Connect Lab - RESOURCES_DIR=/data/resources - BACKGROUND_IMAGE=/resources/wallpaper.jpg - USERS=${USERS} - SECRET=${SECRET} - PROVIDERS_GITHUB_CLIENT_ID=${PROVIDERS_GITHUB_CLIENT_ID} - PROVIDERS_GITHUB_CLIENT_SECRET=${PROVIDERS_GITHUB_CLIENT_SECRET} - OAUTH_WHITELIST=${OAUTH_WHITELIST} - LOG_LEVEL=debug volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - ./wallpaper.jpg:/data/resources/wallpaper.jpg:ro labels: - traefik.enable=true - traefik.http.routers.tinyauth.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth.entrypoints=web - traefik.http.routers.tinyauth-https.rule=Host(`tinyauth.it-connectlab.fr`) - traefik.http.routers.tinyauth-https.entrypoints=websecure - traefik.http.routers.tinyauth-https.tls=true - traefik.http.routers.tinyauth-https.tls.certresolver=ovhcloud - traefik.http.services.tinyauth.loadbalancer.server.port=3000 - traefik.http.middlewares.tinyauth.forwardauth.address=http://tinyauth:3000/api/auth/traefik networks: frontend: external: true

    Ainsi que le fichier .env associé :

    USERS=adm_fb:$2b$05$4K/ulQau1w1v/mR5UzwaOu8UQFAa/bT.DbnrbRK6ed0OFY.KucIQ.SECRET=2BBUv0YFcZRoWMndmG9kaI3US5QU7u6ZPROVIDERS_GITHUB_CLIENT_ID=Ov23liQVitconnectPROVIDERS_GITHUB_CLIENT_SECRET=e78bf94fb2ab4f16ditconnectitconnectOAUTH_WHITELIST=e-mail@it-connect.fr IX. Conclusion

    À condition d’être un minimum à l’aise avec Docker, Tinyauth se présente comme une solution simple et efficace pour protéger n’importe quelle application par un portail d’authentification. L’association avec Traefik est très intéressante pour mettre en place une authentification centralisée.

    Ce type d’architecture reste relativement simple à maintenir, tout en offrant un bon contrôle sur qui accède à quoi. Vous pouvez ensuite affiner les politiques d’accès, ajouter des groupes ou intégrer d’autres services, tout en conservant le même socle : Traefik en frontal, Tinyauth comme brique d’authentification partagée.

    En complément de ce tutoriel, vous pouvez consulter la documentation de Tinyauth.

    FAQ Qu’est-ce que Tinyauth et à quoi sert-il ?

    Tinyauth est une solution légère permettant d’ajouter un portail d’authentification à une application web sans mettre en place une infrastructure complexe. C’est un outil open source codé majoritairement en Go et TypeScript.

    Tinyauth est-il compatible avec toutes les applications web ?

    Oui, dès lors que l’application peut être protégée derrière un reverse proxy ou une redirection HTTP/HTTPS. L’intégration avec Traefik est possible, mais ce n’est pas la seule possibilité. Certaines applications peuvent être plus difficiles à intégrer s’il y a des en-têtes spécifiques à gérer.

    Tinyauth fonctionne-t-il avec Nginx ou Traefik ?

    Oui. Nginx, Traefik et Caddy peuvent être configurés pour rediriger l’utilisateur vers Tinyauth avant d’accéder à l’application.

    Comment activer HTTPS pour Tinyauth ?

    On peut activer TLS en passant par Traefik ou Caddy, ou en configurant Nginx avec un certificat Let’s Encrypt. L’utilisation du HTTPS avec un certificat TLS est plus que recommandée puisqu’il est question d’authentification.

    Peut-on personnaliser l’interface du portail Tinyauth ?

    Oui, l’apparence peut être modifiée, notamment le titre de l’instance et le fond d’écran, grâce à deux variables d’environnement prévues à cet effet (APP_TITLE et BACKGROUND_IMAGE).

    Est-il possible de connecter Tinyauth à un Active Directory ou un LDAP ?

    Oui, la documentation de Tinyauth met en évidence la possibilité de connecter un annuaire LDAP pour l’authentification. Plusieurs champs sont proposés, comme l’adresse du serveur LDAP, le Bind DN, etc… C’est suffisant pour envisager une connexion AD.

    Comment consulter les logs de Tinyauth ?

    Si Tinyauth est déployé par l’intermédiaire d’un conteneur Docker, vous pouvez exécuter la commande docker compose logs -f --tail 100 depuis le répertoire du projet pour afficher les journaux en temps réel.

    – Source :

    https://www.it-connect.fr/tinyauth-traefik-ajoutez-un-portail-authentification-a-vos-applications-web/

  • 1 Votes
    1 Messages
    43 Vues
    I. Présentation

    Traefik est un reverse proxy (et un load balancer) open source conçu pour les applications web (HTTP/HTTPS) et la gestion des connexions TCP. Créé par le Français Émile Vauge, Traefik s’est imposé comme une solution incontournable pour publier des applications exécutées au sein de conteneurs Docker, bien que ce ne soit pas le seul cas d’utilisation. Comment fonctionne-t-il ? Comment installer Traefik ? Réponse dans ce guide complet.

    Dans un environnement basé sur Docker, il est fréquent d’héberger plusieurs applications web sur un même serveur. Chaque conteneur peut exposer un port différent, mais il devient vite difficile d’organiser les accès, de gérer les certificats TLS, et d’ajouter ou retirer des services sans casser les autres. La solution naturelle pour publier ces applications et mieux s’y retrouver, c’est d’utiliser un reverse proxy. Et parmi les reverse proxy capables de tirer parti de Docker de manière dynamique, Traefik s’est imposé comme une référence en tant que reverse proxy pour microservices.

    La force de Traefik, c’est notamment sa capacité à détecter automatiquement vos conteneurs et à simplifier l’intégration d’applications avec de simples labels. À cela s’ajoute la possibilité d’obtenir automatiquement des certificats TLS via Let’s Encrypt (ACME).

    Dans ce tutoriel, nous allons installer Traefik sur un serveur Linux (Debian 13) avec Docker Compose, puis déployer une première application pour valider que tout fonctionne correctement. Cette application sera publiée avec Traefik en HTTP puis en HTTPS (avec l’obtention automatique d’un certificat TLS). L’objectif est de comprendre les briques fondamentales de Traefik.

    II. Les composants de Traefik

    Avant même d’écrire un fichier Docker Compose et de foncer dans le déploiement du reverse proxy Traefik, il est nécessaire de comprendre comment il est structuré. Le schéma ci-dessous met en évidence le positionnement central de Traefik dans l’accès aux applications web et aux API. Du côté backend, même si ce tutoriel est axé sur l’intégration avec Docker, il est envisageable de router le trafic vers d’autres destinations (Kubernetes, machine virtuelle, etc.).

    Traefik a quatre briques fondamentales :

    Élément Rôle Entrypoint Représente un point d’entrée, c’est-à-dire un port sur lequel Traefik écoute (par exemple, du classique : HTTP sur 80, HTTPS sur 443) Router Décide vers quel service envoyer une requête, en fonction de règles. Par exemple, une correspondante avec un nom d’hôte : app1.it-connect.fr. Service Représente réellement l’application cible, le conteneur Docker qui doit recevoir les requêtes Middleware Permet d’appliquer une transformation sur une requête (par exemple : ajout d’authentification HTTP, redirection, headers, etc.)

    Bien qu’il y ait une partie de la configuration de Traefik qui soit statique, il y a aussi une partie de la configuration qui est vivante, voire même dynamique. En pratique, comme nous le verrons par la suite, pour exposer une app via Traefik, nous devons simplement ajouter les labels qu’il faut sur le conteneur, et Traefik récupère la configuration via Docker.

    III. Prérequis pour Traefik

    Pour la suite, il faut un serveur (Linux) sur lequel Docker et Docker Compose sont installés. Le tutoriel s’applique aussi bien sur un VPS cloud que sur un serveur physique local. Vous devez aussi disposer d’un nom de domaine : it-connectlab.fr sera utilisé pour cette démonstration. Un enregistrement DNS a été fait pour une application dont l’adresse IP correspond au serveur Traefik, ce dernier étant en charge de router le trafic (principe du reverse proxy).

    Pour installer Docker sur Linux, vous pouvez suivre ce tutoriel :

    Installation de Docker sur Linux IV. Prise en main de Traefik A. Créer la racine du projet

    Nous allons commencer par créer un dossier pour stocker les données de l’application Traefik.

    mkdir /opt/docker-compose/traefikcd /opt/docker-compose/traefik

    À la racine de ce dossier, nous allons créer le fichier docker-compose.yml.

    En guise de point de départ, nous allons utiliser le** fichier Docker Compose** disponible dans la documentation de Traefik. La version 3.6 de Traefik sera utilisée, il s’agit de la dernière version stable actuelle. Deux ports sont exposés au niveau de ce conteneur : 80, pour bénéficier d’un entryPoint en HTTP (pour publier une application en HTTP) et 8080 pour l’accès au tableau de bord de Traefik.

    # docker-compose.ymlservices: traefik: image: traefik:v3.6 command: - "--api.insecure=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" ports: - "80:80" - "8080:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock

    Trois commandes sont aussi associées à l’exécution de ce conteneur en tant qu’arguments :

    Argument Signification --api.insecure=true Active le dashboard web de Traefik, sans authentification (sur le port 8080 par défaut). --providers.docker=true Active le Provider Docker de Traefik pour découvrir automatiquement les services / labels. --entrypoints.web.address=:80 Déclare un entryPoint nommé web, qui écoute sur port 80 dans le conteneur. Idéal pour les accès HTTP.

    Enfin, une dernière ligne importante est intégrée à ce fichier : /var/run/docker.sock:/var/run/docker.sock. Elle permet à Traefik d’accéder au socket Docker pour “voir” en temps réel les autres conteneurs. C’est important pour l’intégration de Traefik avec Docker, notamment pour lire les labels.

    B. Créer un réseau Docker pour Traefik

    Vous remarquerez que ce Docker Compose ne contient pas de directives pour la connexion au réseau du conteneur. C’est la première évolution que nous allons lui apporter. Nous allons créer un réseau Docker nommé frontend, ce qui me semble être un nom adapté dans le contexte d’un reverse proxy.

    docker network create frontend

    Une fois le réseau créé, vérifiez qu’il est bien présent :

    docker network ls

    Dans le fichier Docker Compose, nous allons associer ce réseau au conteneur Traefik. Il sera déclaré comme un réseau externe (external: true) pour ne pas que Docker cherche à le créer.

    # docker-compose.ymlservices: traefik: image: traefik:v3.6 command: - "--api.insecure=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" ports: - "80:80" - "8080:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock networks: - frontendnetworks: frontend: external: true

    Note: le port HTTPS, à savoir 443, n’est pas exposé pour le moment. Si vous envisagez dès maintenant de publier une application HTTPS, vous pouvez ajouter le port dès maintenant via l’ajout d’une ligne supplémentaire.

    C. Le fichier traefik.yml

    La configuration globale et statique de Traefik se déclare par l’intermédiaire du fichier traefik.yml, au format YAML.

    Nous allons ajouter une ligne sous volumes pour déclarer le fichier de configuration de Traefik, afin qu’il soit persistant et modifiable, tout en étant lu par le conteneur. Par la suite, nous manipulerons à plusieurs reprises le fichier traefik.yml pour ajouter différentes directives.

    volumes: - /var/run/docker.sock:/var/run/docker.sock - ./traefik.yml:/etc/traefik/traefik.yml:ro

    Le fichier doit donc être créé à cet emplacement : /opt/docker-compose/traefik/traefik.yml.

    Éditez le fichier et ajoutez le code précisé ci-dessous pour définir les bases de Traefik en mode proxy inverse pour HTTP et HTTPS.

    Nous désactivons l’envoi de statistiques anonymisées (sendAnonymousUsage) et la vérification automatique de nouvelles versions (checkNewVersion). Nous activons le tableau de bord interne (port 8080) en mode non sécurisé (pas adapté à la production !) afin de pouvoir y accéder dans un premier temps pour visualiser les routes de Traefik. Enfin, on déclare deux entryPoints : un pour le trafic HTTP classique sur le port 80 (nommé web), et un second pour le trafic HTTPS sécurisé sur le port 443 (nommé websecure). Cela prépare Traefik à écouter sur ces deux ports et à accepter des requêtes entrantes que l’on pourra ensuite router vers nos conteneurs.

    # Configuration statique de Traefikglobal: checkNewVersion: false sendAnonymousUsage: false api: dashboard: true # Dashboard Traefik : 8080 insecure: true entryPoints: web: address: ":80" # EntryPoint pour HTTP websecure: address: ":443" # EntryPoint pour HTTPS

    Enregistrez et fermez le fichier.

    Pour éviter les doublons entre la configuration statique et les arguments en ligne de commande, je vous invite à supprimer la ligne command et les trois lignes associées dans le fichier Docker Compose, à savoir :

    command: - "--api.insecure=true" - "--providers.docker=true" - "--entrypoints.web.address=:80" D. Intégrer Docker à Traefik

    Dans le fichier Docker Compose, le nécessaire a été fait pour que le conteneur Traefik dispose d’un accès au socket de Docker (/var/run/docker.sock). Mais ce lien n’est pas exploité en l’état actuel de la configuration. Dans le fichier de configuration⁣ traefik.yml, il est nécessaire d’ajouter un nouveau fournisseur (Provider) correspondant à Docker.

    Éditez de nouveau le fichier traefik.yml et ajoutez ce bloc à la fin du fichier :

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

    La directive exposedByDefault joue un rôle important ! Si elle est sur false comme ici, cela signifie que Traefik va détecter les conteneurs Docker sans les exposer automatiquement : seuls les conteneurs qui auront des labels Traefik seront pris en compte et routés, ce qui évite d’exposer par erreur un service qui ne devrait pas être accessible depuis l’extérieur.

    Désormais, enregistrez la configuration et lancez la construction du conteneur Traefik (depuis le répertoire /opt/docker-compose/traefik).

    docker compose up -d E. Accéder au tableau de bord Traefik

    Ouvrez un navigateur web et accédez au tableau de bord de Traefik via l’adresse IP de l’hôte Docker sur le port 8080. Par exemple : http://192.168.10.200:8080. Ce tableau de bord ne permet pas d’effectuer la configuration en ligne, mais il présente l’avantage d’afficher l’état de la configuration actuelle. Vous devriez notamment visualiser les 3 entryPoints de notre configuration Traefik (celui du dashboard est automatique quand ce dernier est activé).

    F. Associer un service HTTP à Traefik

    Traefik tourne sur notre serveur, c’est une bonne chose. Mais, pour le moment, il ne sert pas à grand-chose car aucun service n’est exposé par son intermédiaire. Pour commencer, nous allons exposer une application facile à héberger : IT-Tools, une boite à outils en ligne. Dans un premier temps, l’accès sera effectué en HTTP, puisque la gestion du certificat rajoute une couche de complexité supplémentaire.

    Créez un dossier pour ce projet :

    mkdir /opt/docker-compose/it-tools

    Dans ce répertoire, créez un fichier docker-compose.yml et insérez le code ci-dessous. Ce service lance l’application IT-Tools à partir de l’image officielle ghcr.io/corentinth/it-tools:latest et nomme le conteneur it-tools. Il est important de noter aussi que ce conteneur est rattaché au réseau Docker externe frontend, le même réseau que Traefik : c’est ce qui permet à Traefik de le découvrir et de router le trafic vers lui (grâce au montage du socket Docker côté Traefik et au provider Docker activé). Il n’y a donc pas de port exposé sur l’hôte pour ce conteneur.

    services: it-tools: image: ghcr.io/corentinth/it-tools:latest container_name: it-tools restart: unless-stopped networks: - frontend labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web networks: frontend: external: true

    Il y a aussi une section labels essentielle pour permettre la découverte par Traefik.

    Les Labels Traefik : ce qu’ils font

    **traefik.enable=true **: nécessaire car, dans notre config Traefik, il y a l’instruction exposedByDefault: false. Ce label autorise explicitement Traefik à gérer ce service. traefik.http.routers.it-tools.rule=Host(\it-tools.it-connectlab.fr): crée un routeur HTTP nommé it-tools qui ne s’active que lorsque la requête du client Web est à destination de l’hôte it-tools.it-connectlab.fr (soit un enregistrement DNS à associer). traefik.http.routers.it-tools.entrypoints=web : indique que ce routeur écoute sur l’entrypPoint intitulé web donc celui qui écoute sur le port 80.

    Petite parenthèse : il est à noter que Traefik va automatiquement associer un service à ce routeur. Chaque service est associé à un module load balancer Traefik (équilibrage de charge), car c’est une fonction indispensable pour chaque reverse proxy pour distribuer la charge en plusieurs serveurs de backends. Même s’il n’y a qu’un seul serveur de backend, comme c’est le cas ici avec un seul conteneur, il y a le load balancer. Dans le cas présent, afin de compléter la configuration, nous pourrions ajouter ce label supplémentaire (c’est important sur les conteneurs où plusieurs ports sont en écoute) :

    - traefik.http.services.it-tools.loadbalancer.server.port=80

    Enregistrez le fichier et lancez le déploiement de l’application :

    docker compose up -d

    À partir d’un navigateur Web, vous devriez pouvoir accéder à l’application :

    L’application a été correctement publiée par l’intermédiaire de Traefik !

    V. Traefik HTTPS : comment ça marche ? A. ACME avec Traefik

    Un accès en HTTP en 2025, ce n’est pas l’idéal tant le HTTPS s’est démocratisé depuis plusieurs années. Surtout, il n’est pas nécessaire de payer pour obtenir un certificat TLS valide : merci Let’s Encrypt. La bonne nouvelle, c’est que Traefik supporte deux Certificate Resolvers : **ACME **(donc Let’s Encrypt) et **Tailscale **pour les services internes et accessibles via cette solution.

    Dans le contexte de la méthode ACME, Traefik prend en charge plusieurs types de challenges pour demander automatiquement le certificat. Il y a le challenge HTTP (httpChallenge) qui est surement le plus classique, mais qui implique que l’hôte soit accessible en HTTP sur le port 80. Surtout, il y a le challenge DNS (dnsChallenge) grâce à l’intégration de Lego, ce qui permet de jouer sur les enregistrements DNS de façon automatique en ciblant les API des gestionnaires de zones DNS.

    Par exemple : vous disposez d’un domaine enregistré chez OVHCloud, vous pouvez effectuer des demandes de certificats Let’s Encrypt via le composant ACME intégré à Traefik, le tout via l’API de OVHCloud. Autrement dit, c’est un processus pleinement automatisé. Cela est aussi vrai pour des dizaines d’autres providers DNS compatibles Traefik, comme Cloudflare, Azure DNS, Gandi, Hostinger ou encore Ionos (voir cette page).

    Pour la suite de cet article, l’objectif sera le suivant : obtenir un certificat TLS pour le domaine it-tools.it-connectlab.fr afin de publier l’application en HTTPS. Ce domaine étant enregistré chez OVHCloud, nous devrons utiliser leur API.

    B. Traefik : exposer le port 443

    Vous devez commencer par exposer le 443 au niveau du conteneur Traefik en éditant le fichier docker-compose.yml de ce projet.

    ports: - "80:80" - "8080:8080" - "443:443" C. Créer une clé d’API OVHCloud pour Traefik

    Vous devez commencer par créer une nouvelle API d’application à partir du portail OVHCloud. Pour l’Europe, il faut accéder à la page eu.api.ovh.com/createApp/, tandis que pour les États-Unis et le Canada, c’est sur la page ca.api.ovh.com/createApp/.

    Donnez un nom à l’application et précisez une description. Par exemple :

    En retour, vous obtenez une clé d’application et un secret associé. Vous devez garder précieusement ces deux informations.

    Ensuite, à l’aide d’une console PowerShell (passez par PowerShell ISE ou VSCode, ce sera plus pratique), vous devez envoyer une requête sur l’API pour donner des droits à cette application. Utilisez le code ci-dessous, en adaptant le nom DNS pour cibler le bon domaine, ainsi que la valeur à la suite de X-Ovh-Application en précisant la clé d’application.

    curl -XPOST -H "X-Ovh-Application: 3f6ed0ayzxyz" -H "Content-type: application/json" https://eu.api.ovh.com/1.0/auth/credential -d '{ "accessRules":[ { "method":"POST", "path":"/domain/zone/it-connectlab.fr/record" }, { "method":"POST", "path":"/domain/zone/it-connectlab.fr/refresh" }, { "method":"DELETE", "path":"/domain/zone/it-connectlab.fr/record/*" } ], "redirection":"https://www.it-connectlab.fr"}'

    L’exécution de cette commande retourne deux informations importantes :

    consumerKey : vous devez conserver la valeur associée à ce champ, car elle sera nécessaire pour la suite de la configuration. validationUrl : vous devez copier cette URL et y accéder avec votre navigateur préféré pour valider l’autorisation. {"consumerKey":"cf5b9e91fffff21233464135","validationUrl":"https://www.ovh.com/auth/sso/api?credentialToken=04fa6c66011dc8498ab80814b140d6b1eea133e520612228fc3620747de0cfdc","state":"pendingValidation"}

    L’URL à laquelle vous avez accédé précédemment affiche une demande de confirmation comme celle ci-dessous. Pensez à ajuster la durée de validité de cet accès et cliquez sur le bouton “Authorize”.

    5bbf2121-2cc0-476a-bc54-da96bb1d384a-image.png

    Vous serez redirigé vers la page indiquée lors de l’exécution de la commande curl. Même si le domaine ne renvoie vers rien, ce n’est pas gênant.

    Voilà, l’accès est prêt au niveau de l’API OVHCloud et de votre compte.

    D. Utiliser OVHCloud avec Traefik

    Puisque Traefik intègre Lego, vous devez consulter la documentation du fournisseur DNS correspondant à vos besoins pour savoir comment le configurer. Vous pouvez consulter, par exemple, la page concernant ovh. Ici, nous allons ajouter 4 variables d’environnement au fichier docker-compose.yml de Traefik :

    OVH_ENDPOINT : définit le point d’accès de l’API OVH (par exemple : ovh-eu), afin que Traefik sache vers quelle région OVH communiquer. OVH_APPLICATION_KEY : identifie l’application (ici Traefik) auprès de l’API OVH. OVH_APPLICATION_SECRET : sert à authentifier de façon sécurisée l’application auprès de l’API OVH. OVH_CONSUMER_KEY : autorise l’application à agir au nom de ton compte OVH, selon les droits accordés lors de la création de la clé.

    Dans le fichier Docker Compose, ces variables sont introduites sans valeur directe, car nous allons utiliser un fichier externe. En même temps, dans la section volumes, rajoutez le montage du dossier ./certs (soit /opt/docker-compose/traefik/certs/ que vous devrez créer).

    # docker-compose.ymlservices: traefik: image: traefik:v3.6 restart: unless-stopped environment: - OVH_ENDPOINT=${OVH_ENDPOINT} - OVH_APPLICATION_KEY=${OVH_APPLICATION_KEY} - OVH_APPLICATION_SECRET=${OVH_APPLICATION_SECRET} - OVH_CONSUMER_KEY=${OVH_CONSUMER_KEY} ports: - "80:80" - "8080:8080" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock - ./traefik.yml:/etc/traefik/traefik.yml:ro - ./certs:/var/traefik/certs:rw networks: - frontendnetworks: frontend: external: true

    Enregistrez et fermez ce fichier. Aux côtés du fichier Docker Compose, créez le fichier .env et associez les bonnes valeurs aux variables. Mise à part pour la première variable, pour les autres, ce sont des informations confidentielles spécifiques à votre environnement.

    OVH_ENDPOINT=ovh-euOVH_APPLICATION_KEY=3f6ed77777777OVH_APPLICATION_SECRET=f6f8d623bf73abcdefghxyzzzzOVH_CONSUMER_KEY=cf5b9e913c5776itconnect2025 E. Ajouter un résolveur ACME

    Pour autant, la configuration ne s’arrête pas là. Ensuite, vous allez devoir ouvrir le fichier de configuration traefik.yml. Vérifiez la présence d’un entryPoint HTTPS, comme websecure dans l’exemple ci-dessous.

    Dans cette configuration, nous devons définir un nouveau résolveur de certificats ACME pour OVHCloud utilisé par Traefik pour obtenir automatiquement des certificats SSL/TLS via Let’s Encrypt.

    Dans cet exemple, le résolveur sera simplement nommé ovhcloud, une adresse e-mail ([email protected]) est associée au compte ACME, tandis que le fichier /var/traefik/certs/ovh-acme.json stocke les certificats et clés générés. Le paramètre caServer indique l’URL de l’API Let’s Encrypt, ici en mode production (avec une alternative en mode staging, moins limitée). Vous pouvez tout à fait utiliser le mode staging pour tester la configuration, puis basculer en mode production ensuite.

    Enfin, la section dnsChallenge précise que la validation du domaine s’effectue via OVHCloud, en créant automatiquement un enregistrement DNS (demandé par Let’s Encrypt au cours du processus). Le delayBeforeCheck de 10 secondes associé laisse le temps à la propagation DNS avant la vérification du certificat. Si vous indiquez 0, cela améliore la réactivité mais c’est aussi une source d’erreur, ce qui est contreproductif.

    # Configuration statique de Traefikglobal: checkNewVersion: false sendAnonymousUsage: false api: dashboard: true # Dashboard Traefik : 8080 insecure: true entryPoints: web: address: ":80" # EntryPoint pour HTTP websecure: address: ":443" # EntryPoint pour HTTPS certificatesResolvers: ovhcloud: acme: email: "[email protected]" storage: "/var/traefik/certs/ovh-acme.json" caServer: "https://acme-v02.api.letsencrypt.org/directory" # Production #caServer: "https://acme-staging-v02.api.letsencrypt.org/directory" dnsChallenge: provider: ovh delayBeforeCheck: 10 providers: docker: endpoint: "unix:///var/run/docker.sock" exposedByDefault: false

    Enregistrez et fermez le fichier. La configuration de Traefik est terminée ! Pensez à faire un Down/Up sur le conteneur pour recharger la configuration.

    F. Ajouter un routeur HTTPS à Traefik

    Pour que notre application IT-Tools soit accessible en HTTPS, sa configuration doit être adaptée. Je vous rappelle que ses labels actuels s’appuient sur l’entryPoint en HTTP. Ouvrez le fichier Docker Compose de l’application, puis ajoutez quatre lignes supplémentaires dans les labels regroupées avec le nom de routeur it-tools-https :

    services: it-tools: image: ghcr.io/corentinth/it-tools:latest container_name: it-tools restart: unless-stopped networks: - frontend labels: - traefik.enable=true - traefik.http.routers.it-tools.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools.entrypoints=web - traefik.http.routers.it-tools-https.rule=Host(`it-tools.it-connectlab.fr`) - traefik.http.routers.it-tools-https.entrypoints=websecure - traefik.http.routers.it-tools-https.tls=true - traefik.http.routers.it-tools-https.tls.certresolver=ovhcloudnetworks: frontend: external: true

    Ces directives configurent le routeur HTTPS de Traefik pour l’application it-tools. L’entrée entrypoints=websecure indique que ce routeur utilise le point d’entrée HTTPS. Le paramètre tls=true active le chiffrement TLS pour sécuriser les connexions. Enfin, tls.certresolver=ovhcloud précise que les certificats TLS/SSL doivent être obtenus automatiquement via le résolveur ACME nommé ovhcloud (nom précisé dans traefik.yml).

    Arrêter ce projet et relancez-le (Down/Up).

    Il ne reste plus qu’à tester l’accès en HTTPS à l’application : https://it-tools.it-connectlab.fr. Si vous êtes en mode STAGING sur Let’s Encrypt, il y aura bien un certificat mais il n’est pas valide (ce qui est normal). Cela permet de valider le bon fonctionnement de la configuration.

    G. Traefik : redirection HTTP vers HTTPS

    Pour finaliser la configuration, il me semble judicieux de configurer la redirection HTTP vers HTTPS. De ce fait, les applications publiées seront accessibles uniquement au travers d’une connexion sécurisée. Les requêtes HTTP seront redirigées, plutôt que de finir dans le vide…

    À ce sujet, il y a une technique évoquée dans la documentation de Traefik et que nous pouvons appliquer. Au sein du fichier traefik.yml, nous allons éviter l’entryPoint web pour ajouter une redirection en HTTPS vers l’entryPoint websecure.

    entryPoints: web: address: ":80" # EntryPoint pour HTTP http: redirections: entryPoint: to: websecure scheme: https websecure: address: ":443" # EntryPoint pour HTTPS

    Ce qui correspond à l’ajout de ces lignes :

    Vous n’avez plus qu’à relancer le conteneur Traefik et à tester !

    VI. Les journaux de debug de Traefik

    Dans le cas où la configuration ne fonctionne pas, vous devez aller faire un tour dans les journaux de Traefik. Par défaut, seules les erreurs sont retournées, ce qui peut être trop limite pour du troubleshooting Traefik.

    Ouvrez le fichier traefik.yml et ajoutez ces lignes pour ajuster le niveau de logs. Ici, nous configurons le mode DEBUG qui est le plus verbeux.

    log: level: DEBUG # Niveau de log

    Ensuite, arrêtez et relancez le conteneur. Attention, les journaux ne sont pas persistants, donc le redémarrage implique un effacement des journaux.

    Consultez les journaux du conteneur Traefik, vous devriez voir de nombreuses informations passer dans la console. Si tout se passe bien, il y aura quand même des informations dans les logs, c’est aussi tout l’intérêt du mode debug.

    /opt/docker-compose/traefik$ docker compose logs -f --tail 100

    Je vous encourage aussi à vérifier :

    La syntaxe de vos fichiers de configuration : attention au copier-coller, au formatage et aux erreurs de frappe. La configuration des entryPoints et des ports exposés au niveau du conteneur Traefik. Les permissions sur les répertoires associés aux données persistantes de Traefik. VII. Conclusion

    Grâce à ce guide d’introduction à Traefik, vous devriez être capable de mettre en place un reverse proxy dans des environnements basés sur Docker. Vous disposez des bases nécessaires pour bien comprendre le fonctionnement de Traefik, afin de l’adapter à vos besoins et votre contexte.

    Pour aller plus loin, consultez la documentation officielle de Traefik et notamment cette page qui regroupe tous les labels Docker. Aimeriez-vous d’autres tutoriels sur Traefik ? N’hésitez pas à partager vos suggestions en commentaire.

    FAQ Qu’est-ce que Traefik et à quoi sert-il ?

    Traefik est un reverse proxy et un load balancer qui simplifie la gestion du trafic réseau vers des applications, conteneurs ou services, tout en automatisant la configuration grâce à l’intégration avec Docker, Kubernetes, ou d’autres orchestrateurs. Il a été créé par Émile Vauge, un Français.

    Comment fonctionne l’auto-discovery des services dans Traefik ?

    Traefik se connecte à un “provider” (tel que Docker ou Kubernetes) et détecte les conteneurs ou services exposés. Il crée automatiquement les routes et règles associées selon les labels configurés. La découverte automatique peut être désactivée pour éviter que des services inappropriés soient exposés. Le provider agit comme une source de configuration dynamique.

    Comment Traefik gère-t-il les certificats SSL/TLS ?

    Traefik prend en charge Let’s Encrypt et plus particulièrement l’ACME. Ainsi, il peut demander, renouveler et gérer automatiquement les certificats SSL/TLS pour les domaines associés à vos applications, garantissant un accès HTTPS avec un certificat valide et sans configuration complexe.

    Traefik peut-il gérer plusieurs domaines ou sous-domaines ?

    Oui. Chaque domaine ou sous-domaine peut être routé vers un service différent grâce aux règles (comme Host()) dans la configuration ou via des labels Docker.

    À quoi sert le tableau de bord de Traefik ?

    Le tableau de bord (Dashboard) de Traefik permet de visualiser en temps réel la configuration active : routes, middlewares, services, certificats et métriques. Il aide au diagnostic et à la supervision du trafic. Mais, il ne permet pas de faire la configuration en ligne : c’est uniquement de la lecture seule.

    Comment fonctionnent les middlewares dans Traefik ?

    Les middlewares servent à transformer les requêtes : ajout d’en-têtes, authentification avant de pouvoir accéder à une application, filtrage applicatif (WAF), etc. On peut dire qu’ils ajoutent des capacités supplémentaires à Traefik.

    Quels sont les journaux (logs) générés par Traefik ?

    Traefik produit deux types de logs : les access logs (requêtes HTTP) et les logs applicatifs (erreurs, warnings, événements internes). Comme l’explique cet article, il y a notamment un paramètre permettant d’ajuster le niveau de log.

    Comment monitorer Traefik ?

    Traefik expose des métriques au format OpenTelemetry et dans des formats adaptés pour des solutions comme Prometheus et InfluxDB2. Il y a également un tableau de bord prêt à l’emploi pour Grafana. Un bloc de configuration metrics: permet d’ajuster la configuration des métriques exposées et leur accès.

    – Source :

    https://www.it-connect.fr/tuto-traefik-reverse-proxy-avec-docker/