Par contre ça rejoint ce que je disais plus haut à propos de boundaryproject : c'est cool mais pour un autre cas d'usage :/
Ici mon post concerne une plateforme FTP car c'est la partie que je dois revoir pour proposer mieux "rapidement" car la stack SFTP est vraiment vilaine + j'ai les contraintes avec le fournisseur qui ne m'ouvre pas le port…
Mais j'ai aussi suggérer à mon chef de gérer d'autres protocoles.
L'idée proposée serait de proposer à l'utilisateur de pousser ses données dans différents canaux :
FTP
S3
etc etc
Et ces canaux pourraient être soit chez nous soit directement chez eux. Exemple : l'utilisateur a son propre bucket S3 quelque part, il nous donne les credentials et nous on s'y connecte pour pousser les données.
En d'autres termes, l'utilisateur qui lance ses traitements dans notre logiciel choisirait où il veut les envoyer en fonction de ce avec quoi il est compatible / ce qu'il veut en faire / etc.
Du coup dans cette optique clairement une brique comme minio pourrait m'aider dans les étapes d'après (et je te remercie encore pour la proposition car je ne connaissais pas).
Mais malheureusement ici j'ai surtout besoin de voir quelle magie je peux faire en FTP standard. Je ne sais pas si le bon smiley serait " :) " ou " :( " :-D
Alors je peux aussi gérer des utilisateurs FTP sur le côté (donc indépendant de Keycloak) : ça je sais faire. C'est juste que je voulais m'éviter de me faire ***** avec une gestion des utilisateurs si j'arrive à me connecter à Keycloak :D
Je n'ai plus d'activité dans le fichier de log /var/log/pamAuthenticationWithKeycloak.log : comme si le module PAM n'était plus appelé.
J'ai pourtant vérifié dans builddefs.h et le support de PAM est activé :
#define VSF_BUILD_PAM
Après peut-être que VSFTPd est une mauvaise idée aussi.
Si je dois commencer à patcher du code C que je ne comprends pas et compiler moi même les sources pour arriver à quelque chose, je me demande si c'est une bonne idée pour déployer en production…
Merci pour le partage : je ne connaissais pas et ça peut être sympa à suivre effectivement :)
Alors je n'ai pas encore regardé donc je vais sûrement répondre à côté.
Par contre du descriptif que tu en as fait, on est d'accord que des logiciels standards type FileZilla seront de facto incompatibles s'il faut ouvrir une session en https avant ?
Car si c'est bien ça, mon exemple avec FileZilla devient vrai pour tous les utilisateurs qui ont des logiciels / scripts uniquement compatibles avec le vrai protocol SFTP non ?
J'ai eu une discussion avec mon manager hier et il s'est rendu compte d'un petit détail : il s'est trompé en exprimant son besoin :D
Du coup avoir une instance de Jupyter dans nos conteneurs existants n'est pas ce qu'il veut.
Je dois donc laisser tomber ce sujet pour me concentrer sur son vrai besoin qui n'est peut-être pas plus simple :-)
En conclusion si ça peut aider quelqu'un qui aurait un besoin similaire, personnellement mes recommandations seraient :
1/ si besoin de démarrer X daemons dans un conteneur, d'utiliser supervisor
2/ si besoin d'un reverse proxy magique pour router vers X ports, d'utiliser Traefik
Dans mon cas j'aurais probablement poussé pour avoir une instance de Traefik pour chaque conteneur backend pour profiter au maximum du côté dynamique.
Je remercie toutes les personnes qui ont pris du temps pour me répondre :)
C'était un échange constructif et bien que le besoin ait changé j'ai appris pas mal de choses intéressantes de mon côté
Je n'ai pas relu tous mes messages mais il me semble que j'avais considéré cette option effectivement :)
En théorie ça devrait fonctionner mais je ne l'ai pas testé réellement.
Le problème avec une instance Traefik commune est que si Traefik est redémarré pour X ou Y raisons après les conteneurs "backends", alors Traefik ne sera pas configuré pour router des flux vers ces backends.
Du coup pour l'instant j'ai eu une petite préférence pour la solution "un Traefik par backend" à défaut de mieux.
J'avoue ne pas avoir cherché explicitement s'il était possible de forcer une sorte de "refresh" de Traefik car lors de mes autres recherches je n'ai rien vu en ce sens :/
Non je n'ai pas "masqué" l'IP : c'était bien de 127.0.0.1 dont je parlais :)
Mais dans ce cas de figure, à savoir UNE instance de Traefik commune à tous les conteneurs, je me retrouve avec :
conteneur1
conteneur2
conteneur3
Comment les distinguer ?
Comment savoir que la requête qui arrive sur "localhost:5000" est pour conteneur1 et pas conteneur2 ?
C'était ça l'idée derrière le FQDN propre à chaque conteneur :)
Avec un FQDN tel que "conteneur1.container.local" j'ai pu créer une règle qui dit à Traefik :
si Host == conteneur1.container.local alors envoie moi le trafic stp
Ça fonctionne mais cette solution a un gros inconvénient finalement : si Traefik est redémarré, il n'y a plus aucune règle dedans et donc tous les backends deviennent injoignables sauf si je les redémarre
Alors à cet instant T c'est assez "vilain" : les conteneurs sont démarrés dans le réseau "bridge" créé par défaut.
Ça ne fait que 6 mois que je suis dans l'entreprise donc je ne peux pas être partout en même temps. Du coup j'ai profité de ce besoin pour gratter un peu et voir quels seraient les axes d'amélioration possibles.
Un des axes a été de créer un réseau dédié (docker network create) pour plugger les conteneurs dedans car j'ai trouvé une documentation officielle qui :
explique les différences entre le réseau "bridge" par défaut et un réseau créé avec docker network create
recommande quand même de monter les conteneurs dans ce réseau dédié (comme tu l'as souligné dans ton message)
Comme c'est une solution qui fonctionne je vais évidemment la proposer à mon manager mais parfois j'ai des tocs :-D
Hier quand j'ai posté mon message initial j'ai focus en me disant "ce n'est pas la bonne approche, revoir l'approche".
Mais en continuant à travailler sur le sujet aujourd'hui, après coup, je pense qu'effectivement la solution est une candidate sérieuse qui n'est pas si sale / vilaine que cela :-)
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 :
Ajouter des conf avec un reload du proxy ne me semble pas être problématique dans le sens où il me semble que tu active/désactive pas des containers toute les 2min (ou j'ai mal compris le besoin).
Je comprend pas bien le lien entre ce que tu veux mettre en place et le dev de votre app.
En faites j'ai pensé bien faire en ne donnant pas tout le contexte pour éviter de trop perdre les personnes qui, comme toi, ont pris de leur temps pour me lire et surtout me répondre :)
Je vais tenter de donner plus de détails en évitant de trop perdre tout le monde quand même (c'est compliqué même pour moi :-D). Nous avons une interface web développée en interne par nos développeurs.
Cette interface permets à nos utilisateurs de lancer des traitements informatisés.
Chaque traitement est finalement un algorithme disponible au travers de notre interface web.
On va parler de "processor" ou "d'application".
Chaque "application" est à l'arrivée un conteneur Docker.
Si un utilisateur veut lancer un traitement X existant dans le logiciel :
on a déjà tout ce qu'il faut sous la main
l'interface démarre le conteneur (docker run …) si nécessaire
l'interface exécute les requêtes dans le conteneur
l'interface remonte les informations / données résultantes à l'utilisateur à l'origine de la requête
Si un utilisateur en a les capacités, il peut écrire son propre algorithme (exemple : si c'est quelque chose dont il a besoin et qu'on ne le propose pas) en utilisant nos API.
Dans ce cas il upload un fichier compressé (on explique ce qu'il doit contenir, etc) et notre logiciel va tenter de construire le conteneur pour après rentrer dans le workflow d'exécution.
Donc le lien fort entre développeurs / moi / tout ce bims il est là :
une bonne partie des choses sont réalisées par le logiciel donc par du code
code géré par des développeurs
je n'ai donc pas la main à 100% :-)
Alors comme tu as pu le comprendre en me lisant dans ce post, je ne suis fermé à aucune approche et donc je test plusieurs pistes pour voir laquelle est la meilleure :)
La définition de meilleure est évidemment très personnelle.
Je cherche le "keep it simple" :
le moins d'effort possible pour tout le monde
ce qui sera le plus simple à maintenir sur le long terme
Le tout dans un écosystème assez compliqué car j'ai des serveurs chez plusieurs fournisseurs donc avec une installation de base qui diffère.
Je parlais dans certains de mes messages du réseau sur certains serveurs.
Pour être concret :
j'ai des serveurs qui semblent utiliser Netplan + systemd-networkd sur lesquels changer les serveurs DNS est assez facile en étant prudent
mais j'ai aussi des serveurs qui utilisent ifupdown et pour lesquels le DHCP m'écrasent le /etc/resolv.conf au démarrage : alors oui je peux y aller à coup de chattr -i mais voilà quoi :-D
Du coup une belle équation bien tordue avec plein de contraintes :) Même si parfois de la fumée sort de la tête, c'est ce qui fait que j'aime beaucoup mon job :)
En réponse globale je vais poster un message qui ne sera pas une réponse à ton message ou à un message en particulier pour donner un état des lieux car évidemment depuis hier soir j'ai progressé un peu :-)
Pour la résolution à l'intérieur des conteneurs docker : c'est réglé.
Hier lors de mon premier test je n'avais pas fais trop attention mais dnsmasq écoutait sur 127.0.0.1:53 au lieu de *:53
Alors ça ça l'air juste génial pour éviter un dnsmasq qui fait à peu près tout sauf le café :-)
Par contre il faut que je vois car le fonctionnement reste le même que dnsmasq et donc :
je dois dégager SystemD Resolved : ça c'est faisable
j'ai toujours un problème avec certains serveurs pour lesquels ça utilise je ne sais quelle "solution" pour le réseau mais qui fait que les serveurs DNS sont écrasés par le DHCP :-/
j'ai toujours ce fameux problème de résolution à l'intérieur des conteneurs Docker :/
Alors sur le papier ça semble une bonne idée mais je t'avoue que de bon matin elle m'effraie / n'est pas totalement claire dans ma tête.
Je te réponds maintenant mais j'ai besoin d'y réfléchir un peu plus pour voir comment je pourrais faire ça.
Car là ce serait un mix des deux mondes :
côté développeur ils continuent de ne connaître qu'un seul port exposé : celui du Traefik / Apache / Nginx / HAProxy pour n'avoir à requêter que 127.0.0.1:
côté sysadmin (mon côté donc) moi il faut que je me débrouille à manipuler les X ports (dans ce cas de figure 2 ports) par conteneur + à reconfigurer le proxy dynamiquement
En théorie je ne vois rien qui fait que ça ne fonctionnerait pas. Par contre en pratique ça n'a pas l'air trop trop simple à gérer si ?
Car justement si j'ai préféré tester Traefik c'est que je connaissais la théorie à propos de son côté "dynamique" : pas de fichier de configuration à gérer pour ajouter un backend.
Avec un produit plus classique (Apache / Nginx / HAProxy) il faut que je trouve le moyen de rajouter / supprimer des vhosts dynamiquement quand un nouveau conteneur apparaît et le tout sans faire faire trop de changement aux développeurs.
Tu sais si Docker permets d'exécuter des scripts pre/post déploiement ? J'avoue je n'ai pas encore cherché par moi même.
Ce que je cherchais déjà c'était de voir si l'ami Docker serait assez aimable pour me fournir des variables qui contiennent des choses comme l'IP, le nom du conteneur déployé, etc mais je n'ai pas encore trouvé ça…
Concernant le fichier /etc/hosts :
si c'est fait côté développeur alors c'est chaud car :
ça rentrerait en conflit avec mon automation Ansible à moi : je déploie des entrées /etc/hosts (très peu certes, mais j'en ai quelques unes) qui seraient donc potentiellement écrasées et/ou c'est moi qui écraseraient celles des développeurs
le client est exécuté en tant que Tomcat (bon ok possible de faire du sudo, etc)
si c'est fait de mon côté alors on en revient à la détection d'un changement :/
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 :)
Désolé j'ai complètement raté ton message… : merci pour les suggestions que je garde précieusement de côté.
Alors à ma connaissance il n'y a aucune résolution DNS inverse : que de la résolution DNS directe ou des adresses IP directes.
Ce qui est étrange c'est que le problème est apparu du jour au lendemain sur un serveur qui a été mis en production il y a un presque un an (je me fie à ce que l'on me dit vu que moi je suis arrivé il y a un mois :-D)
Pour l'instant je touche du bois : depuis que j'ai mis à jour la JDK vers la dernière mise à jour mineure + ajouté le paramètre acceptorThreadCount="2" dans server.xml le soucis n'est pas réapparu (d'où le fait que j'ai été silencieux dans ce post : j'attendais de voir) :-)
Alors je vais faire une réponse complète à tout le monde sur ce fil :)
Je viens de mettre en place un script qui prends quelques mesures toutes les 60 secondes :
- w
- top
- free
- ping d'une ip publique bien connue pour être un serveur DNS d'un célèbre moteur de recherche
- ping de la gateway
- wget de l'application sur son adresse externe
- wget de l'application sur 127.0.0.1:8080 pour bypasser le load balancer nginx en frontal
- iotop
J'espère capturer quelque chose pendant le problème…
Concernant la détection du type d'hyperviseur je reçois un "vm-other" et je n'ai aucun agent qui tourne : je vais essayer de me renseigner.
Concernant le script schedlat: je l'ai testé localement, il m'a l'air intéressant (merci beaucoup), mais je voudrais le ralentir un peu car il va me produire un peu beaucoup de logs :D Du coup je l'ai pas encore mis sur la machine qui a le problème.
[^] # Re: pip install X; pip install Y vs pip install X Y
Posté par kortex . En réponse à la dépêche L'installation et la distribution de paquets Python (2/4). Évalué à 2. Dernière modification le 29 décembre 2023 à 17:45.
Merci beaucoup pour les précisions :)
# pip install X; pip install Y vs pip install X Y
Posté par kortex . En réponse à la dépêche L'installation et la distribution de paquets Python (2/4). Évalué à 4.
Merci pour l'article très intéressant.
A un moment tu dis :
C'est une partie qui m'intéresse :-)
Pourrais-tu détailler stp ?
C'est quoi la différence concrètement du coup ?
[^] # Re: minio?
Posté par kortex . En réponse au message Keycloak + PAM + vsftpd. Évalué à 1.
Merci pour la suggestion :)
Par contre ça rejoint ce que je disais plus haut à propos de boundaryproject : c'est cool mais pour un autre cas d'usage :/
Ici mon post concerne une plateforme FTP car c'est la partie que je dois revoir pour proposer mieux "rapidement" car la stack SFTP est vraiment vilaine + j'ai les contraintes avec le fournisseur qui ne m'ouvre pas le port…
Mais j'ai aussi suggérer à mon chef de gérer d'autres protocoles.
L'idée proposée serait de proposer à l'utilisateur de pousser ses données dans différents canaux :
Et ces canaux pourraient être soit chez nous soit directement chez eux. Exemple : l'utilisateur a son propre bucket S3 quelque part, il nous donne les credentials et nous on s'y connecte pour pousser les données.
En d'autres termes, l'utilisateur qui lance ses traitements dans notre logiciel choisirait où il veut les envoyer en fonction de ce avec quoi il est compatible / ce qu'il veut en faire / etc.
Du coup dans cette optique clairement une brique comme minio pourrait m'aider dans les étapes d'après (et je te remercie encore pour la proposition car je ne connaissais pas).
Mais malheureusement ici j'ai surtout besoin de voir quelle magie je peux faire en FTP standard. Je ne sais pas si le bon smiley serait " :) " ou " :( " :-D
Alors je peux aussi gérer des utilisateurs FTP sur le côté (donc indépendant de Keycloak) : ça je sais faire. C'est juste que je voulais m'éviter de me faire ***** avec une gestion des utilisateurs si j'arrive à me connecter à Keycloak :D
# Petite progression
Posté par kortex . En réponse au message Keycloak + PAM + vsftpd. Évalué à 1.
Avant mes congés j'avais trouvé ceci : https://askubuntu.com/questions/406486/vsftpd-hanging-when-using-pam-exec-or-pam-script
Mais ça m'était sorti de la tête.
Ce matin j'ai creusé cette piste et j'ai une petite progression.
Test 1
J'ai :
Résultat : échec total
Test 2
J'ai :
Résultat : échec total
Test 3
J'ai :
Résultat : échec partiel
Dans les logs de VSFTPd j'ai :
Je n'ai plus d'activité dans le fichier de log /var/log/pamAuthenticationWithKeycloak.log : comme si le module PAM n'était plus appelé.
J'ai pourtant vérifié dans builddefs.h et le support de PAM est activé :
Après peut-être que VSFTPd est une mauvaise idée aussi.
Si je dois commencer à patcher du code C que je ne comprends pas et compiler moi même les sources pour arriver à quelque chose, je me demande si c'est une bonne idée pour déployer en production…
[^] # Re: boundary project
Posté par kortex . En réponse au message Keycloak + PAM + vsftpd. Évalué à 1.
Je vais m'intéresser à cette partie dès que j'ai du temps mais plus pour mon accès SSH que pour le serveur SFTP :)
Pour la partie SFTP c'est trop contraignant pour les utilisateurs qui sont dépendants de leur IT au niveau des outils qu'ils ont à disposition :/
Merci encore pour le partage
[^] # Re: boundary project
Posté par kortex . En réponse au message Keycloak + PAM + vsftpd. Évalué à 1.
Merci pour le partage : je ne connaissais pas et ça peut être sympa à suivre effectivement :)
Alors je n'ai pas encore regardé donc je vais sûrement répondre à côté.
Par contre du descriptif que tu en as fait, on est d'accord que des logiciels standards type FileZilla seront de facto incompatibles s'il faut ouvrir une session en https avant ?
Car si c'est bien ça, mon exemple avec FileZilla devient vrai pour tous les utilisateurs qui ont des logiciels / scripts uniquement compatibles avec le vrai protocol SFTP non ?
[^] # Re: linux magazine 259
Posté par kortex . En réponse au message Keycloak + PAM + vsftpd. Évalué à 1.
J'en ai fait 3 et aucun ne l'avait. Quand tu as la poisse… :)
[^] # Re: linux magazine 259
Posté par kortex . En réponse au message Keycloak + PAM + vsftpd. Évalué à 2.
Merci beaucoup :)
Je crois que je vais filer chez le marchand de journaux voir si je le trouve car j'en perds mon latin :)
# Conclusion
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 2.
J'ai eu une discussion avec mon manager hier et il s'est rendu compte d'un petit détail : il s'est trompé en exprimant son besoin :D
Du coup avoir une instance de Jupyter dans nos conteneurs existants n'est pas ce qu'il veut.
Je dois donc laisser tomber ce sujet pour me concentrer sur son vrai besoin qui n'est peut-être pas plus simple :-)
En conclusion si ça peut aider quelqu'un qui aurait un besoin similaire, personnellement mes recommandations seraient :
1/ si besoin de démarrer X daemons dans un conteneur, d'utiliser supervisor
2/ si besoin d'un reverse proxy magique pour router vers X ports, d'utiliser Traefik
Dans mon cas j'aurais probablement poussé pour avoir une instance de Traefik pour chaque conteneur backend pour profiter au maximum du côté dynamique.
Je remercie toutes les personnes qui ont pris du temps pour me répondre :)
C'était un échange constructif et bien que le besoin ait changé j'ai appris pas mal de choses intéressantes de mon côté
[^] # Re: Un petit état des lieux
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 1.
Je n'ai pas relu tous mes messages mais il me semble que j'avais considéré cette option effectivement :)
En théorie ça devrait fonctionner mais je ne l'ai pas testé réellement.
Le problème avec une instance Traefik commune est que si Traefik est redémarré pour X ou Y raisons après les conteneurs "backends", alors Traefik ne sera pas configuré pour router des flux vers ces backends.
Du coup pour l'instant j'ai eu une petite préférence pour la solution "un Traefik par backend" à défaut de mieux.
J'avoue ne pas avoir cherché explicitement s'il était possible de forcer une sorte de "refresh" de Traefik car lors de mes autres recherches je n'ai rien vu en ce sens :/
[^] # Re: Un petit état des lieux
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 1.
Oui mais comme je le disais dans un de mes messages ça vient avec un sacré problème du côté de Jupyter-Notebook :-/
[^] # Re: Un petit état des lieux
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 1.
Non je n'ai pas "masqué" l'IP : c'était bien de 127.0.0.1 dont je parlais :)
Mais dans ce cas de figure, à savoir UNE instance de Traefik commune à tous les conteneurs, je me retrouve avec :
Comment les distinguer ?
Comment savoir que la requête qui arrive sur "localhost:5000" est pour conteneur1 et pas conteneur2 ?
C'était ça l'idée derrière le FQDN propre à chaque conteneur :)
Avec un FQDN tel que "conteneur1.container.local" j'ai pu créer une règle qui dit à Traefik :
Ça fonctionne mais cette solution a un gros inconvénient finalement : si Traefik est redémarré, il n'y a plus aucune règle dedans et donc tous les backends deviennent injoignables sauf si je les redémarre
[^] # Re: Un petit état des lieux
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 2.
Nouvel inconvénient de la solution 2 (un Traefik commun) que je n'avais pas vu venir :
De plus en plus j'ai l'impression que dans mon cas d'usage bien précis, la solution élégante consiste à utiliser une instance Traefik par backend.
[^] # Re: Pour le souci de wildcard dans le hosts
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 2.
Alors à cet instant T c'est assez "vilain" : les conteneurs sont démarrés dans le réseau "bridge" créé par défaut.
Ça ne fait que 6 mois que je suis dans l'entreprise donc je ne peux pas être partout en même temps. Du coup j'ai profité de ce besoin pour gratter un peu et voir quels seraient les axes d'amélioration possibles.
Un des axes a été de créer un réseau dédié (docker network create) pour plugger les conteneurs dedans car j'ai trouvé une documentation officielle qui :
[^] # 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é à 2.
Comme c'est une solution qui fonctionne je vais évidemment la proposer à mon manager mais parfois j'ai des tocs :-D
Hier quand j'ai posté mon message initial j'ai focus en me disant "ce n'est pas la bonne approche, revoir l'approche".
Mais en continuant à travailler sur le sujet aujourd'hui, après coup, je pense qu'effectivement la solution est une candidate sérieuse qui n'est pas si sale / vilaine que cela :-)
# Un petit état des lieux
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 3.
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 redirige :
Les avantages :
peu de changement du côté de l'application :
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 :
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 :
Pour ce faire j'ai utilisé dnsmasq :
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 à :
Les avantages :
Les inconvénients :
nous ajoutons 2 dépendances majeurs à notre écosystème logiciel :
peut-être que côté développeur c'est plus lourd / compliqué que ce que j'imagine
[^] # Re: Proxy frontal + mappage de port
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 2. Dernière modification le 26 mai 2022 à 14:20.
En faites j'ai pensé bien faire en ne donnant pas tout le contexte pour éviter de trop perdre les personnes qui, comme toi, ont pris de leur temps pour me lire et surtout me répondre :)
Je vais tenter de donner plus de détails en évitant de trop perdre tout le monde quand même (c'est compliqué même pour moi :-D). Nous avons une interface web développée en interne par nos développeurs.
Cette interface permets à nos utilisateurs de lancer des traitements informatisés.
Chaque traitement est finalement un algorithme disponible au travers de notre interface web.
On va parler de "processor" ou "d'application".
Chaque "application" est à l'arrivée un conteneur Docker.
Si un utilisateur veut lancer un traitement X existant dans le logiciel :
Si un utilisateur en a les capacités, il peut écrire son propre algorithme (exemple : si c'est quelque chose dont il a besoin et qu'on ne le propose pas) en utilisant nos API.
Dans ce cas il upload un fichier compressé (on explique ce qu'il doit contenir, etc) et notre logiciel va tenter de construire le conteneur pour après rentrer dans le workflow d'exécution.
Donc le lien fort entre développeurs / moi / tout ce bims il est là :
Alors comme tu as pu le comprendre en me lisant dans ce post, je ne suis fermé à aucune approche et donc je test plusieurs pistes pour voir laquelle est la meilleure :)
La définition de meilleure est évidemment très personnelle.
Je cherche le "keep it simple" :
Le tout dans un écosystème assez compliqué car j'ai des serveurs chez plusieurs fournisseurs donc avec une installation de base qui diffère.
Je parlais dans certains de mes messages du réseau sur certains serveurs.
Pour être concret :
Du coup une belle équation bien tordue avec plein de contraintes :) Même si parfois de la fumée sort de la tête, c'est ce qui fait que j'aime beaucoup mon job :)
En réponse globale je vais poster un message qui ne sera pas une réponse à ton message ou à un message en particulier pour donner un état des lieux car évidemment depuis hier soir j'ai progressé un peu :-)
[^] # Re: Pour le souci de wildcard dans le hosts
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 2.
Pour la résolution à l'intérieur des conteneurs docker : c'est réglé.
Hier lors de mon premier test je n'avais pas fais trop attention mais dnsmasq écoutait sur 127.0.0.1:53 au lieu de *:53
[^] # Re: Pour le souci de wildcard dans le hosts
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 1.
Alors ça ça l'air juste génial pour éviter un dnsmasq qui fait à peu près tout sauf le café :-)
Par contre il faut que je vois car le fonctionnement reste le même que dnsmasq et donc :
[^] # Re: Proxy frontal + mappage de port
Posté par kortex . En réponse au message Docker + Traefik: besoin d'avis extérieurs pour un besoin un peu spécifique. Évalué à 1.
Alors sur le papier ça semble une bonne idée mais je t'avoue que de bon matin elle m'effraie / n'est pas totalement claire dans ma tête.
Je te réponds maintenant mais j'ai besoin d'y réfléchir un peu plus pour voir comment je pourrais faire ça.
Car là ce serait un mix des deux mondes :
En théorie je ne vois rien qui fait que ça ne fonctionnerait pas. Par contre en pratique ça n'a pas l'air trop trop simple à gérer si ?
Car justement si j'ai préféré tester Traefik c'est que je connaissais la théorie à propos de son côté "dynamique" : pas de fichier de configuration à gérer pour ajouter un backend.
Avec un produit plus classique (Apache / Nginx / HAProxy) il faut que je trouve le moyen de rajouter / supprimer des vhosts dynamiquement quand un nouveau conteneur apparaît et le tout sans faire faire trop de changement aux développeurs.
Tu sais si Docker permets d'exécuter des scripts pre/post déploiement ? J'avoue je n'ai pas encore cherché par moi même.
Ce que je cherchais déjà c'était de voir si l'ami Docker serait assez aimable pour me fournir des variables qui contiennent des choses comme l'IP, le nom du conteneur déployé, etc mais je n'ai pas encore trouvé ça…
Concernant le fichier /etc/hosts :
si c'est fait côté développeur alors c'est chaud car :
si c'est fait de mon côté alors on en revient à la détection d'un changement :/
[^] # 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 :)
[^] # Re: on sait jamais, le grand classique
Posté par kortex . En réponse au message Tomcat - Application qui devient lente sans raison apparente. Évalué à 1. Dernière modification le 29 novembre 2021 à 08:31.
Désolé j'ai complètement raté ton message… : merci pour les suggestions que je garde précieusement de côté.
Alors à ma connaissance il n'y a aucune résolution DNS inverse : que de la résolution DNS directe ou des adresses IP directes.
Ce qui est étrange c'est que le problème est apparu du jour au lendemain sur un serveur qui a été mis en production il y a un presque un an (je me fie à ce que l'on me dit vu que moi je suis arrivé il y a un mois :-D)
Pour l'instant je touche du bois : depuis que j'ai mis à jour la JDK vers la dernière mise à jour mineure + ajouté le paramètre acceptorThreadCount="2" dans server.xml le soucis n'est pas réapparu (d'où le fait que j'ai été silencieux dans ce post : j'attendais de voir) :-)
[^] # Re: Sécu
Posté par kortex . En réponse au message Tomcat - Application qui devient lente sans raison apparente. Évalué à 1.
Je suis fatigué je n'avais même pas pensé à ça :D
[^] # Re: limite mémoire de la JVM
Posté par kortex . En réponse au message Tomcat - Application qui devient lente sans raison apparente. Évalué à 1.
Je vais regarder / lire tout ça au plus vite : merci :)
[^] # Re: service de virtualisation
Posté par kortex . En réponse au message Tomcat - Application qui devient lente sans raison apparente. Évalué à 2.
Alors je vais faire une réponse complète à tout le monde sur ce fil :)
Je viens de mettre en place un script qui prends quelques mesures toutes les 60 secondes :
- w
- top
- free
- ping d'une ip publique bien connue pour être un serveur DNS d'un célèbre moteur de recherche
- ping de la gateway
- wget de l'application sur son adresse externe
- wget de l'application sur 127.0.0.1:8080 pour bypasser le load balancer nginx en frontal
- iotop
J'espère capturer quelque chose pendant le problème…
Concernant la détection du type d'hyperviseur je reçois un "vm-other" et je n'ai aucun agent qui tourne : je vais essayer de me renseigner.
Concernant le script schedlat: je l'ai testé localement, il m'a l'air intéressant (merci beaucoup), mais je voudrais le ralentir un peu car il va me produire un peu beaucoup de logs :D Du coup je l'ai pas encore mis sur la machine qui a le problème.