idealement
conteneurX.domain.tld:8888/ l'enverra sur le jupyter,
conteneurX.domain.tld:5000/ l'enverra sur l'app
C'est justement celle que je cherche à éviter pour 3 raisons principales :
quand l'équipe de dev a formulé sa demande, ils m'ont dit "tu peux nous mettre un Nginx pour qu'on ait pas à tout changer de notre côté et que l'on continue de requêter sur un seul port ?" (nous parlons ici du client web). Alors à force de négociation évidemment je peux leur faire changer du code mais si je trouve une solution élégante de mon côté je pense qu'ils seront contents :)
j'ai expliqué l'idée générale avec 3 conteneurs mais nous avons déjà une bonne vingtaine de conteneur montés en permanence + au travers du client il est possible d'en monter à la demande sans que j'ai le contrôle la dessus. Du coup ça peut vite devenir le bims dans les ports à gérer pour les développeurs :-/
je trouvais l'idée d'un point d'entrée un peu plus sexy quand même
Concernant celle-ci :
ou bien
conteneurX.domain.tld/app => envoie sur le contenerX port 5000 et
conteneurX.domain.tld/jupyter => envoie sur le conteneur, port 8888
C'est celle que je vise et que j'ai pu obtenir avec Traefik mais à condition d'avoir une instance Traefik en face de chaque conteneurX :-/
Alors :
ça fonctionne
je n'ai bien qu'un port en écoute pour exposer et mon app et mon Jupyter : je trouve ça plus évolutif pour la suite si on me demande un troisième daemon
Mais je trouve qu'avoir une instance de Traefik par conteneur est un peu overkill non ?
Évidemment si je n'ai pas mieux cette option sera conservée puisqu'elle fonctionne :-)
ngnix, haproxy en sont d'autres,
l'un d'eux permet peut-etre de faire ce que tu veux
Comme je le disais précédemment, la demande initiale de l'équipe de développement était un Nginx.
Ce à quoi j'ai répondu quelque chose comme "laissez moi jouer avec Traefik d'abord : sur le papier ça m'a l'air plus adapté". Je ne connaissais pas Traefik donc j'ai découvert au travers de ce petit projet et c'est franchement pas mal :-)
Nginx et HAProxy sont des produits que je connais assez bien (peut-être pas à 100%) et malheureusement je ne vois pas trop trop comment je pourrais faire mieux.
Car justement le gros avantage de Traefik c'est qu'il se configure tout seul sur base des labels que l'on défini sur les conteneurX + qu'il trouve l'ip du conteneurX cible tout seul.
Si je trouve une solution propre pour avoir *.domain.tld -> 127.0.0.1 de manière dynamique (aucune entrée à créer) alors en théorie l'approche conteneurX.domain.tld/<endpoint> fonctionnera dans Traefik.
Maintenant si je considère HAProxy et/ou Nginx je ne vois pas comment je règlerais les problèmes en faites :-/
Imaginons que l'on ne prenne que Nginx (ça facilite l'explication du fait d'un seul vocabulaire du fait que HAProxy et Nginx n'utilisent pas forcément les même terminologies).
Soit il me faut quand même une URL par conteneur et donc je me retrouve avec un VirtualHost par conteneur :
comment régler ce fichu problème de DNS ?
comment déployer ces configurations dynamiquement sans avoir à demander aux équipes de développement de produire des VirtualHost à chaque fois qu'un conteneur est ajouté ?
Soit je joue avec les "location" de Nginx mais c'est pareil :
conteneurX réponds à "/app" et c'est codé comme ça : ce n'est pas configurable
Jupyter lui permets de configurer le point de terminaison (endpoint) via un paramètre "base_url". Moi j'ai configuré ça sur "/jupyter-notebook" mais par défaut c'est "/". Le problème c'est que Jupyter a dans son code des redirections vers "". Donc dès que je tente de joindre 127.0.0.1:/jupyter-notebook ça fonctionne. Mais si je rajoute un paramètre fictif (niveau Traefik donc) comme 127.0.0.1:/conteneur1/jupyter-notebook alors Jupyter redirige vers 127.0.0.1:/jupyter-notebook et donc l'ami Traefik ne comprends plus la requête
Est-ce que tu avais quelque chose en tête que je n'ai pas vu ? Désolé c'est le matin :-D
Quand je dis que c'est à s'arracher les cheveux ;-)
Une approche qui pourrait fonctionner serait de définir le "base_url" de Jupyter sur /conteneurX/jupyter-notebook.
Il faut que je test mais dans l'idée :
je créé une variable d'environnement qui contient le nom du conteneur (conteneur1, conteneur2, conteneur3)
je réutilise cette variable pour la passer à Jupyer via quelque chose comme "--NotebookApp.base_url ${MA_VARIABLE}/jupyter-notebook"
côté Traefik idem j'utilise ${MA_VARIABLE} pour amener un chemin dynamique
Je vais tester et voir ce que si ça fonctionne :-)
Dans tous les cas aucune solution n'est parfaite et toutes mes approches demandent des changements côté développeur. C'est juste que les changements sont plus ou moins compliqués / profonds. Par exemple j'utilise Docker Compose pour jouer avec Traefik là ou pour l'instant le client (l'application web) exécute des commandes Docker natives. Je PENSE (je n'ai pas encore annoncé la bonne nouvelle à mes collègues développeurs) que ce changement est relativement minime car il est assez ciblé / centralisé contrairement aux requêtes sur les conteneurs :)
[^] # Re: des pistes et sinon faut changer de reverse proxy
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 3.
Merci pour ton retour :)
Alors concernant cette approche :
C'est justement celle que je cherche à éviter pour 3 raisons principales :
quand l'équipe de dev a formulé sa demande, ils m'ont dit "tu peux nous mettre un Nginx pour qu'on ait pas à tout changer de notre côté et que l'on continue de requêter sur un seul port ?" (nous parlons ici du client web). Alors à force de négociation évidemment je peux leur faire changer du code mais si je trouve une solution élégante de mon côté je pense qu'ils seront contents :)
j'ai expliqué l'idée générale avec 3 conteneurs mais nous avons déjà une bonne vingtaine de conteneur montés en permanence + au travers du client il est possible d'en monter à la demande sans que j'ai le contrôle la dessus. Du coup ça peut vite devenir le bims dans les ports à gérer pour les développeurs :-/
je trouvais l'idée d'un point d'entrée un peu plus sexy quand même
Concernant celle-ci :
C'est celle que je vise et que j'ai pu obtenir avec Traefik mais à condition d'avoir une instance Traefik en face de chaque conteneurX :-/
Alors :
Mais je trouve qu'avoir une instance de Traefik par conteneur est un peu overkill non ?
Évidemment si je n'ai pas mieux cette option sera conservée puisqu'elle fonctionne :-)
Comme je le disais précédemment, la demande initiale de l'équipe de développement était un Nginx.
Ce à quoi j'ai répondu quelque chose comme "laissez moi jouer avec Traefik d'abord : sur le papier ça m'a l'air plus adapté". Je ne connaissais pas Traefik donc j'ai découvert au travers de ce petit projet et c'est franchement pas mal :-)
Nginx et HAProxy sont des produits que je connais assez bien (peut-être pas à 100%) et malheureusement je ne vois pas trop trop comment je pourrais faire mieux.
Car justement le gros avantage de Traefik c'est qu'il se configure tout seul sur base des labels que l'on défini sur les conteneurX + qu'il trouve l'ip du conteneurX cible tout seul.
Si je trouve une solution propre pour avoir *.domain.tld -> 127.0.0.1 de manière dynamique (aucune entrée à créer) alors en théorie l'approche
conteneurX.domain.tld/<endpoint>fonctionnera dans Traefik.Maintenant si je considère HAProxy et/ou Nginx je ne vois pas comment je règlerais les problèmes en faites :-/
Imaginons que l'on ne prenne que Nginx (ça facilite l'explication du fait d'un seul vocabulaire du fait que HAProxy et Nginx n'utilisent pas forcément les même terminologies).
Soit il me faut quand même une URL par conteneur et donc je me retrouve avec un VirtualHost par conteneur :
Soit je joue avec les "location" de Nginx mais c'est pareil :
Est-ce que tu avais quelque chose en tête que je n'ai pas vu ? Désolé c'est le matin :-D
Quand je dis que c'est à s'arracher les cheveux ;-)
Une approche qui pourrait fonctionner serait de définir le "base_url" de Jupyter sur /conteneurX/jupyter-notebook.
Il faut que je test mais dans l'idée :
Je vais tester et voir ce que si ça fonctionne :-)
Dans tous les cas aucune solution n'est parfaite et toutes mes approches demandent des changements côté développeur. C'est juste que les changements sont plus ou moins compliqués / profonds. Par exemple j'utilise Docker Compose pour jouer avec Traefik là ou pour l'instant le client (l'application web) exécute des commandes Docker natives. Je PENSE (je n'ai pas encore annoncé la bonne nouvelle à mes collègues développeurs) que ce changement est relativement minime car il est assez ciblé / centralisé contrairement aux requêtes sur les conteneurs :)