Reprise du message précédent :
Parce que c'est le port 5432 qu'il faut que tu utilises, que ce soit en interne à ton conteneur db (localhost), où depuis le réseau interne de Docker (donc depuis ton conteneur wog).

Tu n'a pas besoin d'exposer le port à l'extérieur (ton ports : - 5423:5432) pour avoir la connectivité wog <=> db, c'est uniquement pour rendre ton conteneur accessible de l'extérieur du réseau Docker, en l'exposant sur ton hote (l'IP de ta machine à toi).

Le soucis, dans mon cas, c'est que le port 5432 est déjà utilisé par une autre image Docker.
 
J'ai donc besoin de changer le port utilisé que ce soit pour mon local ou pour mon réseau Docker.
 
Après test j'accède effectivement bien à ma base docker depuis mon image wog (reste à comment créer une base par défaut depuis le docker-compose).
 
Et... je peux bien accéder depuis mon poste à mon serveur db via localhost:5423.
 
 
Donc... en fiat j'ai pas de bug ! o_O  
 
 
Merci de m'avoir mis sur la piste, je n'avais bien bien compris la portée de `ports`.

OSEF qu'un autre conteneur écoute sur son port 5432, chaque conteneur a son IP, donc c'est pas un problème.
 
La section "ports" du docker-compose ne sert qu'à exposer les ports des conteneurs sur ton hote.
Tu peux donc très bien mapper le port 5432 de ton conteneur sur un port 6666 de ton hote, ce qui importe c'est qu'en interne à ton réseau Docker, tes autres conteneurs accèderont toujours sur le port 5432 du conteneur, là où se trouve le service, et pas le 6666 qui lui est sur ton hote (c'est un simple NAT)
 
Dans la pratique, un conteneur de DB on n'expose très rarement son port.
Depuis ta machine tu peux très bien adresser l'IP du conteneur directement (même si c'est pas toujours simple à retrouver).
Et la bonne pratique c'est de lancer un autre conteneur avec le CLI si besoin, en le placant dans le même réseau que ta DB.

J'ai bien compris qu'en interne chaque conteneur à sa propre IP.
 
Dans mon cas, base de dev en local j'ai besoin d'accéder à mes containers via datagrip (par exemple), je dois donc exposer les ports (pour aller au plus simple).
 
Connaître l'IP interne (172....) je peux le voir rapidement avec Portainer mais l'idée est de faire un truc rapide pour mes collègues (localhost:<port exposé> ) et c'est fin i!  
 
 
Pour le fait d'exposer les ports d'une DB avec toi je suis totalement d'accord mais dans mon cas, comme dit plus haut c'est juste une base locale pour que chaque dev puisse bosser en local.

Oui, dans ce cas là pas de souci.
 
Par contre à ce moment là, le mieux c'est de définir :
ports:
  -localhost:5423:5432
 
Comme ça tu n'exposes pas ton conteneur sur le réseau
 
Bon, c'est du pinaillage, mais ça peut aider à comprendre le fonctionnement de l'exposition de port avec Docker qui est pas forcément évidente de premier abord.

Ha yes !
 
C'est pas mal ça !
 
Merci
 
EDIT :  
 
je n'arrive pas à mettre `localhost` dans mon docker

Comment ça ?
Y a pas à mettre localhost nulle part dans un conteneur, c'est uniquement pour ton accès "via datagrip par exemple"

Comme tu as dis plus haut :
 

 
 
Ok... en fait il attends 127.0.0.1 et non localhost... problem solved!

Ah oui, my bad

 
C'est de nouveau moi avec mes petites aventures de programmation
Dans une soucis d'optimisation d'image, j'ai découvert le multi-stage, et je me suis dit que c'était un bon cas pratique.
Je précise que j'ai aussi aussi effectué une division en modules de mon-script.py.
Mon Dockerfile:

 
Et biensur, j'ai une erreur  
Un module appelé par main.py n'arrive pas à importer feedparser, précédemment installé via pip. Je suspecte quelque chose au niveau de la copie "from builder".
Bon au final, c'est un gain de 10Mo donc pas dramatique si le multi-stage n'est pas présent, mais j'aimerais bien comprendre

Perso pour du multistage sur python je fais un virtualenv que je recopie dans la seconde image. Il y a des exemples sur le net.
 
Une alternative est d'utiliser les wheels.
 
Là difficile à dire, on n'a pas ton requirements.txt
 
Le gain peut être faible mais si certains modules ont besoin de compilation parce qu'ils contiennent du code en C alors tu t'économises une install de build-essential ou équivalent (+ tout un tas de paquets *dev), ce qui est un gain énorme ; si ton appli est amenée à évoluer ça vaut vraiment le coup.

Voici mon requirements.txt

Sinon je vais aller voir les deux pistes que tu m'as proposé. Merci

Ah j'ai pas vu que tu partais sur alpine aussi. Alpine est vraiment chiante à cause de la libc qu'elle utilise, ça pose plein de problèmes avec python et d'autres langages.
 
Essaie de partir d'une debian pour voir aussi.

Beh j'étais partis sur une python3.8, mais quand tu vois qu'elle fait plus de 900Mo juste faire tourner un pauvre script  
J'ai vite changé pour la 3.8.1-slim-buster, mais quand j'ai vu que je pouvais encore rogner quelques Mo avec alpine, je ne m'en suis pas trop privé
 
EDIT:
Arf, bordel il me manque le setup.py

Je n'arrive pas à build
Je reste coincé à l'étape:

Mon Dockerfile:

Mon setup.py:

C'est censé faire quoi ce `pip install . ` ?
 
Tu as déjà installé tes requirements dans `pip install -r requirements.txt` non ? Ou je rate quelque chose ?
 
Tu utilises le venv correctement j'ai l'impression (j'ai retrouvé l'article ici, j'ai mes sources au taf) : https://pythonspeed.com/articles/ac [...] ockerfile/
 
Mais j'ai l'impression que ta question est plus liée à python qu'à docker. Au passage tu es dans "/" d'où le "Processing /" qui doit prendre une plombe s'il essaie de faire un truc récursivement sur tout ton FS.

 
Justement, j'ai suivi le tuto multi-stage du même site que tu viens de me donner (solution avec les venv)
https://pythonspeed.com/articles/mu [...] er-python/

 
J'ai testé mon ancien docker build avec le script non modulaire (le paté de ligne de code ) et bordel mon script se lance Je comprends pas l'erreur que j'ai faite, j'ai juste split le code et importer les libs qui faut dans chaque module.
Et j'ai importé mes modules dans mon main.py.
 
Donc au final, j'ai la situation suivante:

• La modularisation de mon code fonctionne avec une build standard (sans multi-stage)
• Le multi-stage fonctionne avec tout dans un script.

Yop !
 
Je viens d'essuyer une belle perte de data sur mon swarm... je ne sais pas bien ce qu'il s'est passé entre la mauvaise manip' au niveau de l'interface chaise-clavier ou alors ma façon de stocker les volumes qui est foireuse
 
Bon j'ai des backup quotidiens et rien de bien vital dans ces données donc ça va.
 
Concrètement mes node accèdent à un partage NFS, comme ça tous les nodes ont accès aux mêmes volumes = que le conteneur se lance sur node1, node2 ou node3 le volume reste le même !
 
Mais il est possible que ça ne soit pas une solution idéale.
 
Vous avez des expériences à partager sur des solutions de stockage des volumes ?
 
Mon infra : 3 nodes Docker (Debian 10) qui ont accès à un serveur de stockage (NFS actuellement mais ça peut être autre chose si besoin !).
 
Voilà plus qu'à récupérer mes volumes et remonter mes stacks !

Oui ok mais ça depend de la conf !
Tu fais un docker volume, un bind d'un dossier nfs sur le host ? Il ressemble à quoi ton docker compose ?
Tu as bien vérifié que c'était dispo sur les 3 hosts tes datas ?

J'utilise le driver NFS comme suit :
 

 
En gros dans le dossier NFS ça me crée un dossier au format "stack-nomService" pour le volume.
 
Que je lance sur node1, 2 ou 3 pas de soucis les données sont récupérées.
 
Mais j'ai l'impression que le driver NFS délire de temps à autre et pour moi c'est lui qui a tout dégagé tout à l'heure...
 
Pour ça que j'aimerais passer à quelque chose de plus solide ^^

Tu peux monter le nfs sur chaque host et faire un bind de dossier, et donc plus besoin de volume.  
J’ai fais ça longtemps c’est stable.
Sinon je suis passé à k8s

J'ai effectivement prévu de m'intéresser à K8S, qu'est-ce qui est proposé dans cette situation de ce côté ?
 
Faudrait que je test en montant le share NFS et en bindant mes volumes dedans effectivement

 K8s gère le nfs mais c’est stable...  
le bind c’est moche mais ça fonctionne  swarm va mourir de toute façon autant migrer

Allé tu m'as chauffé j'ai créé des VM sur mon lab pour voir ce que donne K8S
 
Si jamais tu as des ressources à conseiller pour débuter ^^
 
Après quelques constats j'ai vraiment l'impression que c'est le driver NFS qui a mis la grouille... en gros j'ai déployé un service qui n'a pas réussis à créer son dossier dans le share NFS, du coup il a "vomit" ses fichiers à la racine du share #crado ! Et au passage on dirait bien qu'il a tout simplement vidé tout le reste Possible que l'image du service deployé fasse le ménage...
 
Donc oui des binds plus secure seraient de bonne augure et surtout abandonner ce driver NFS !

NFS c’est juste rock stable depuis 40 ans
 
Pourquoi ton service avait accès au root de l’export en rw.... that is the question

Oui NFS ok c'est du solide c'est certain, mais le driver Docker que j'utilise pas certain...

Ce n'est pas la première fois que je constate que des conteneurs ne créent pas leur "dossier" de volume et gerbent à la racine du share NFS !

Je vais déjà dégager ce driver "docker-volume-netshare"... pour moi le soucis est quelque part dans la déclaration du volume (voir ci dessus) qui pointe uniquement le share NFS avec le comportement attendu que le volume crée son propre dossier au format "stack-service" au lieu d'accéder à la racine...

 
Faut être root pour pourvoir écrire dans un volume?
 
J'ai créé un utilisateur lambda qui doit écrire dans un dossier situé dans /.
J'ai fait un chown -R utilisateur:utilisateur /dossier

Si tu bind, il faut utiliser le même uid/gid pour les permissions dans ton container et en dehors.

Effectivement, si je ne crée pas explicitement de user, je n'ai pas d'erreur d’écriture.
Je pensais bien faire en voulant sécuriser un minimum mon conteneur via les droits. Est ce qu'il existe un autre moyen?

 
Source ?

Toute la communauté passe sur kubernetes ... il n’y a plus que docker qui maintient Swarm en vie par perfusion ... et pour preuve ils ont intégrer kubernetes dans docker desktop pour éviter une fuite de tous les dev de leur plateforme;

Tu peux, il faut juste que l'id du user qui ecrit dans le container et l'id du user proprietaire des fichiers hors du container soient les memes.
 
C'est pour ca que j'evite de binder et que j'utilise des volumes le plus possible.

Salut à tous.
Je n'ai pas compris ta dernière phrase.
Si tu dois échanger ou lire des fichiers en dehors du contenu, la problématique d'UID reste la même qu'on utilise bind ou volume non ?
Quand tu dis volume, tu penses à la commande (qui permet d'avoir aussi un REP comme volume) ou un espace de stockage dédié à un conteneur ?
Contexte, je suis sysadmin mais quasi noob en docker (je manipule des conteneurs en VM pour me former pour l'instant).

Hello,
 
J'ai une question concernant Traefik.
 
J'ai un docker-compose de ce  type :

 
Et pourtant je ne le vois pas apparaitre dans mon Traefik.
 
Je précise que mon Traefik est fonctionnel pour d'autres docker. Je soupçonne le "network_mode: host".

Traefik v1 ou v2 ?

Les déclarations sont assez différentes entre ces 2 versions.

Aussi tu est en docker compose ou swarm ? Là aussi il faut une instruction pour indiquer que tu tournes en swarm.

Si ça fonctionne pour d'autres conteneurs une configuration "copier-coller" devrait passer en adaptant Le conteneur concerné se lance bien ?

Traefik 1.
 
Docker-compose.
 
Le conteneur tourne bien et est fonctionnel. La différence avec les autres ? Le network_mode: Host.

Tu n'as aucune réaction que ça soit côté "frontend" et "backend" ?
 
Est-ce qu'il ne faudrait pas un label du genre :
 

 
Mais pas certain que ça fonctionne...
 
Il faudrait peut être passer par un "file" pour déclarer à la main le service

Justement, je voudrais éviter de passer par un "file". J'aime bien le côté dynamique directement via les labels docker.
 
Sinon, vous savez s'il est possible en ligne de commande de lister tous les frontends / backends en cours dans Traefik ?
En gros, avoir les infos du dashboard, mais en ligne de commande, à la demande.

Quelle est la raison de mettre en mode Host ?
 
Pourquoi ne pas déclarer que les ports nécessaires ?

Mon docker est pour Home Assistant. Ils recommandent d’utiliser le mode host, j’imagine pour utiliser tous les services du rpi lié à la découverte de service ou autre.

Mouais, j'ai du Jeedom et du HA en Docker je ne les ai jamais mis en mode host
 
Tu redirige uniquement le nécessaire, d'ailleurs le service est plus souvent client que serveur (sauf pour le HTTP bien sûr)