Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:docker:general:traefik [2020/10/07 20:42] – qduchemi
+++ technique:docker:general:traefik [2021/11/16 00:45] (Version actuelle) – supprimée qduchemi
@@ Ligne 1: / Ligne 1: @@
-{{indexmenu_n>50}}
-# Traefik, un reverse-proxy pour Docker
-Une des pièces centrales de l'infrastructure des services de Picasoft est Traefik.
-<bootnote>
-    * La documentation officielle peut être retrouvée ici : https://doc.traefik.io/traefik/
-    * La configuration spécifique pour Picasoft est versionnée ici : https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/tree/master/pica-traefik
-</bootnote>
-## Problématique
-Sur chaque machine, Picasoft héberge plusieurs services web accessibles via une URL. Lors de la consultation sur un navigateur web, cette URL est traduite en adresse IP (grâce au DNS), et permet de trouver la machine qui correspond à l'URL.
-Chaque service tourne dans un conteneur Docker. En prenant un exemple, la situation est la suivante :
-{{ :technique:docker:general:without_traefik_443.png |}}
-Le navigateur contacte naturellement le port `443` car l'URL est en HTTPS, dans cet exemple.
-<bootnote question>Comment est-ce-que la machine sait quel conteneur correspond à quelle URL ?</bootnote>
-En réalité, elle n'a **aucun moyen de le savoir**.
-<bootnote question>Comment faire ?</bootnote>
-## Utiliser les ports
-Une technique traditionnelle, lorsque plusieurs services tournent sur une même machine et doivent être accessibles via Internet, est d'utiliser les ports pour la destination. Ainsi, chaque conteneur écoute sur un port particulier de la machine. Par exemple, on aurait la situation suivante :
-{{ :technique:docker:general:without_traefik_ports.png |}}
-Ainsi, chaque conteneur écoute sur un port spécifique :
-* `team.picasoft.net:4000` envoie sur le port 4000 de la machine, sur lequel le conteneur Mattermost écoute
-* `pad.picasoft.net:5000` envoie sur le port 5000 de la machine, sur lequel le conteneur Mattermost écoute
-<bootnote question>Quel est le problème avec cette configuration ?</bootnote>
-C'est une solution simple, néanmoins elle nécessite d'utiliser les ports dans l'URL, et ce n'est vraiment pas pratique pour les utilisateurices. Les sites web que l'on consulte tous les jours n'ont pas d'URL dans leur numéro de port, en général.
-## Utiliser un reverse proxy
-L'autre technique traditionnelle, c'est d'utiliser un *reverse proxy*.
-* Un *proxy* est un serveur vers lequel sont redirigées toutes les requêtes qui **sortent** d'un ordinateur (par exemple, dans une entreprise, une université...)
-* Un *reverse proxy* est un serveur vers lequel sont redirigées toutes les requêtes qui **entrent** vers un ordinateur.
-L'idée est donc qu'un reverse proxy écoute sur les port 80 et 443 (qui n'ont pas besoin d'être spécifiés dans l'URL), et qu'il redirige automatiquement vers le bon conteneur, grâce à l'URL de la requête.
-<bootnote question>Comment associer une URL à un conteneur ?</bootnote>
-Il y a plusieurs solutions. `nginx` peut tout à faire être [utilisé comme reverse proxy](https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/). L'inconvénient, c'est qu'il va falloir lui fournir une configuration statique qui associe une URL à un conteneur, et cette configuration devra être modifiée à chaque nouveau service. Il faudra aussi gérer les certificats SSL pour chaque service, par exemple.
-C'est pourquoi nous utilisons Traefik, un outil clé en main pour Docker. Traefik fonctionne comme un reverse proxy traditionnel, mais ajoute quelques fonctionnalités bien pratiques :
-{{ :technique:docker:general:traefik.png |}}
-* L'association entre URL et conteneur se fait grâce aux [labels Docker](https://docs.docker.com/config/labels-custom-metadata/), ce qui évite de modifier la configuration du reverse-proxy à l'ajout d'un nouveau service.
-* Traefik découvre automatiquement les nouveaux services en "surveillant" Docker, regarde les labels, et crée des routes automatiquement
-* Traefik gère automatiquement la création et le renouvellement des certificats des services
-* Comme tout reverse-proxy, on peut lui demander d'ajouter des headers de sécurité dans les requêtes HTTP
-En somme, pour ajouter un nouveau service accessible depuis internet via HTTPS, il suffit d'ajouter quelques labels sur le conteneur, et à son lancement, il est accessible *automagiquement*, sans configuration supplémentaire.