Un petit état des lieux

Donc depuis hier soir j'ai progressé et j'ai donc maintenant deux solutions qui fonctionnent :)

Solution 1 - celle que j'avais déjà

La solution "avoir un Traefik en face de chaque conteneur final" fonctionne.

Pour ce faire je dois juste jouer avec le paramètre --providers.docker.constraints de Traefik pour que les configurations dynamiques soient interceptées par la bonne instance de Traefik.

Dans les grandes lignes :

• Traefik expose un port : exemple 6000
• l'application finale écoute sur son port interne (non exposé) : 5000
• Jupyter écoute sur son port interne (non exposé) : 8888

Traefik redirige :

• les requêtes de /jupyter-notebook vers le port 8888
• les autres requêtes vers le port 5000

Les avantages :

• un seul fichier docker-compose.yml à gérer par application : on est plutôt aligné avec la philosophie
• c'est relativement simple et efficace à mettre en œuvre : aucune bidouille de DNS, peu de fichiers de configuration à manipuler, etc

• peu de changement du côté de l'application :

  • seule les commandes docker exécutées sont à remplacer
  • nous pouvons requêter sur 127.0.0.1: comme aujourd'hui

• s'il devait y avoir un autre besoin un peu "tordu" ce serait assez flexible (vu que le Traefik est décié à une application en backend) pour gérer d'autres backends

Les inconvénients :

• ça fait démarrer un Traefik par conteneur (donc potentiellement une consommation de ressources inutiles bien qu'au repos ça doit être faible)

Solution 2 - un Traefik commun + un FQDN qui résout 127.0.0.1

Ici l'idée est d'avoir un domain (app-container.local) qui, quelque soit l'entrée, réponds toujours 127.0.0.1 :

• exemple1.app-container.local -> 127.0.0.1
• exemple2.app-container.local -> 127.0.0.1
• etc

Pour ce faire j'ai utilisé dnsmasq :

• j'ai désactivé systemd-resolved
• j'ai supprimé le lien symbolique /etc/resolv.conf qui pointait sur ../run/systemd/resolve/stub-resolv.conf
• j'ai installé + configuré dnsmasq :

address=/app-container.local/127.0.0.1

J'ai créé un fichier docker-compose dédié à Traefik + j'ai démarré une instance de Traefik.

Ensuite j'ai démarré mon application avec docker-compose :

• en settant une variable COMPOSE_PROJECT_NAME qui me sert à :

  • forcer un peu le destin du nom du conteneur
  • avoir un nom "unique" (à condition que la valeur passée soit unique) dans Traefik :

 labels:
 - "traefik.enable=true"
 - "traefik.http.routers.processor.rule=Host(`${COMPOSE_PROJECT_NAME}.app-container.local`)"
 - "traefik.http.routers.processor.entrypoints=web"
 - "traefik.http.routers.processor.service=svc-${COMPOSE_PROJECT_NAME}-processor"
 - "traefik.http.routers.processor.priority=10"
 - "traefik.http.services.svc-processor.loadbalancer.server.port=5000"
 - "traefik.http.routers.jupyter-notebook.rule=Host(`${COMPOSE_PROJECT_NAME}.app-container.local`) && PathPrefix(`/jupyter-notebook`)"
 - "traefik.http.routers.jupyter-notebook.entrypoints=web"
 - "traefik.http.routers.jupyter-notebook.service=svc-${COMPOSE_PROJECT_NAME}-jupyter-notebook"
 - "traefik.http.routers.jupyter-notebook.priority=20"
 - "traefik.http.services.svc-jupyter-notebook.loadbalancer.server.port=8888"

Les avantages :

• Traefik est commun et donc consomme moins de ressources
• même s'il y a une bidouille de résolution, chaque application possède maintenant sa propre URL
• c'est un peu plus compliqué à mettre en œuvre que la solution n°1 à cause du DNS mais j'ai l'impression que ça reste encore acceptable

Les inconvénients :

• ça implique des changements en terme de DNS qui pourrait devenir lourds sur les quelques serveurs qui utilisent ifupdown

• nous ajoutons 2 dépendances majeurs à notre écosystème logiciel :

  • si Traefik est down : nos applications sont down
  • si dnsmasq est down : nos applications sont down

• peut-être que côté développeur c'est plus lourd / compliqué que ce que j'imagine