Moby: Documenter comment se connecter à l'hôte Docker à partir du conteneur

lorsque vous regardez à l'intérieur de network.go, vous constatez que docker sonde les réseaux internes qui ne sont pas routés.

d'abord 172.16.42.1 est deviné comme adresse de pont puis les autres.

Donc documenter cela ne servira pas à grand chose. C'est un schéma dynamique sur lequel vous ne pouvez pas compter.

Je pense que ce dont vous avez besoin est davantage un moyen de définir les adresses utilisées pour le pont et le client.
cela pourrait-il être?

Je pense que l'exigence est claire dans le titre du problème. Il doit y avoir un moyen simple et bien documenté de parler à l'hôte à partir du conteneur, quelle que soit sa mise en œuvre.

+1 Ce serait vraiment bien d'avoir un bon moyen de se connecter au système hôte

+1, la branche 1.0 définira une API d'introspection afin que chaque conteneur puisse interagir avec l'hôte de manière ciblée et contrôlée.
​
Ceci est actuellement prévu pour 0.8.

—
@solomonstre
@getdocker

Le jeudi 8 août 2013 à 13h10, EJ Bensing [email protected]
a écrit:

+1 Ce serait vraiment bien d'avoir un bon moyen de se connecter au système hôte

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/dotcloud/docker/issues/1143#issuecomment -22351792

Alors, comment puis-je me connecter à l'hôte Docker depuis un conteneur ? J'essaie de me connecter à un conteneur Docker via le port hôte plutôt que l'adresse IP privée du conteneur.

@gerhard : une API d'introspection est prévue pour la 0.8. En attendant, si vous souhaitez accéder à l'API Docker à partir des conteneurs, vous pouvez configurer Docker pour écouter sur l'adresse IP du pont Docker.

Pour ce faire, vous devez :

• créer un pont

ip link add docker0 type bridge

• lui attribuer une adresse IP

ip link set docker0 up
ip addr add 172.17.0.1/16 dev docker0

• démarrer docker et lier l'API au pont

docker -d -H 172.17.0.1:4242

Vous pouvez désormais accéder à l'API Docker à partir de vos conteneurs.

Actuellement (version 0.7), docker ne prend pas en charge de manière fiable l'octroi d'un accès illimité à son propre socket de contrôle à l'un de ses conteneurs. Les solutions de contournement expliquées dans ce fil de discussion sont des hacks dont le fonctionnement n'est pas garanti, et s'ils peuvent se casser à tout moment - veuillez ne pas les utiliser en production ou attendre de nous que nous les soutenions. Puisqu'il n'y a pas de fonctionnalité officielle à documenter, ce problème de doc ne peut pas être résolu.

Pour discuter des hacks et des solutions de contournement pour les fonctionnalités manquantes, je recommande soit la liste de diffusion _docker-user_, soit le canal _#docker_ irc sur Freenode.

Bon piratage

@shykes Y a-t-il un autre problème qui suit la création d'une telle fonctionnalité, dans ce cas ?

Soit dit en passant, pour motiver une telle fonctionnalité : cela est utile lorsque vous testez localement un serveur (où j'aurais utilisé vagrant dans le passé) et que je souhaite connecter un serveur du conteneur à une base de données ou à un autre serveur s'exécutant sur ma machine de développement (l'hôte docker).

Je suis déjà vendu sur la valeur de cette fonctionnalité :)

Le lundi 2 décembre 2013 à 9h09, Caleb Spare [email protected]
a écrit:

Soit dit en passant, pour motiver une telle fonctionnalité : cela est utile lorsque vous testez localement un serveur (où j'aurais utilisé vagrant dans le passé) et que je souhaite connecter un serveur du conteneur à une base de données ou à un autre serveur s'exécutant sur ma machine de développement (l'hôte docker).

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/dotcloud/docker/issues/1143#issuecomment -29636528

Je suis sur Fedora 20 avec docker 0.7.2, en configurant Docker UI . J'ai dû ouvrir le port sur lequel écoute le démon docker pour que le pare-feu ne le bloque pas :

• firewall-cmd --permanent --zone=trusted --add-interface=docker0
• firewall-cmd --permanent --zone=trusted --add-port=4243/tcp

Après cela, _docker-ui_ a pu se connecter au socket de contrôle du démon docker.

HTH
Il s'agit d'un besoin clair et légitime pour une telle fonctionnalité.

Je suis désolé, si je garde un fil dur en vie.

Le titre de ce problème indique : "Comment se connecter à l'hôte à partir du conteneur Docker".
Je ne vois pas comment cela se rapporte à la fonctionnalité docker inspect . La fonction d'inspection est utilisée côté hôte pour trouver l'adresse IP du conteneur, si je ne me trompe pas.

Je pense que le problème de bkad est de trouver l'adresse IP de l'hôte à partir du conteneur. Certes, je ne suis pas un assistant réseau, mais il n'est pas assez sûr de supposer que la passerelle IP (depuis l'intérieur du conteneur) correspond à l'hôte.
(En supposant que l'on ne configure pas une configuration de pont ou quelque chose).

En utilisant la passerelle pour 0.0.0.0 partir de netstat -nr , je n'ai certainement eu aucun problème pour atteindre un serveur fonctionnant sur ma machine hôte. Je soupçonne que l'adresse IP de la passerelle est statique (une fois que Docker est démarré), quelqu'un peut-il le confirmer ?

Une alternative serait de transmettre l'adresse IP publique de mes hôtes au conteneur à l'aide de variables d'environnement, mais l'adresse IP publique peut ne pas être statique. Et bien que le nom d'hôte fonctionne mieux en production, il est difficile à utiliser localement.

Je préférerais toujours un moyen d'appeler du conteneur Docker pour héberger via le bouclage et apparaître comme 127.0.0.1 sur l'hôte. Ou si la sécurité est un problème, un autre périphérique de bouclage qui a toujours la même adresse IP.
Ou peut-être que la chose que j'ai trouvée n'expose pas ma communication au public ? Comme dit, je ne suis pas un assistant réseau :)
Remarque, si utiliser ip-gateway pour appeler l'hôte docker est la "bonne façon", ne pouvons-nous pas le documenter ?

Pour ceux qui cherchent à trouver l'adresse IP de la passerelle du conteneur /proc/net/route est probablement le bon endroit pour le lire.

La motivation , pour cette fonctionnalité, comprend divers services de métadonnées. Exposer des éléments du service de métadonnées ec2 serait bien. Distribution d'informations d'identification et de données structurées plus complexes qui ne correspondent pas aux variables d'environnement.

@jonasfj : il existe en fait un moyen plus simple, maintenant que Docker prend en charge les fichiers de montage de liaison de l'hôte au conteneur. Vous pouvez lier le socket de contrôle Docker, c'est-à-dire : docker run -v /var/run/docker.sock:/var/run/docker.sock … ; c'est plus facile que de jouer avec les règles de mise en réseau.

Je ne sais pas comment le socket docker aide. Je pense toujours que le problème devrait être rouvert, il n'y a pas de documentation pour le scénario suivant :

1) Sur 'l'hôte', un service s'exécute sur le port 8080 (disons 'etcd')
2) À partir de cet hôte, un conteneur docker est démarré
3) Comment accéder au service sur le port 8080 de l'hôte depuis le conteneur Docker ? Quelle serait l'URL/IP ?

@jpetazzo Comment la configuration de docker.sock intervient-elle pour résoudre le problème ci-dessus?

@vrvolle , exposer docker.sock ne résout pas le problème original décrit par @bkad.
Mais on exposerait un socket de domaine unix différent pour la communication entre l'hôte et le conteneur docker.

Par exemple, si vous vouliez exposer mysql depuis l'hôte, vous exposeriez le socket mysql : /tmp/mysql.sock .

Ou si vous avez comme moi une API de métadonnées à travers laquelle les conteneurs devraient pouvoir interroger l'hôte pour diverses choses utiles, vous créez votre propre socket de domaine Unix et l'exposez au conteneur. HTTP sur les sockets de domaine Unix devrait très bien fonctionner. De plus, vous n'avez pas tous les problèmes de configuration réseau et les problèmes de sécurité.

juste eu à lire sur les 'sockets de domaine unix'.
mais:

http://stackoverflow.com/questions/14771172/http-over-af-unix-http-connection-to-unix-socket

prétend qu'il n'y a pas d'URL et donc qu'aucun client habituel ne peut utiliser ce mécanisme prêt à l'emploi.

D'autre part:

http://stackoverflow.com/questions/14771172/http-over-af-unix-http-connection-to-unix-socket

montre qu'il est en quelque sorte possible d'utiliser une telle prise.

Mais j'aimerais quand même pouvoir avoir une adresse IP et un port, qu'un programme à l'intérieur d'un docker pourrait simplement utiliser. Je vais - pour l'instant - utiliser

 netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'

Dois-je créer un nouveau problème ou quelqu'un peut-il rouvrir celui-ci.

@vrvolle
Je ne suis pas un gars du réseau, mais j'imagine qu'il y a quelques astuces que l'on peut faire pour proxy localhost dans le conteneur via un socket unix, puis à l'intérieur du socket proxy unix du conteneur vers le containers-localhost (périphérique de bouclage) ...

Ce serait bien de documenter comment faire cela. Mais il semble que ce ne soit pas nécessairement une fonctionnalité dont le docker a besoin pour un support actif.

Il existe plusieurs façons d'aborder cela, en fonction de ce que vous voulez exactement atteindre.

Si vous souhaitez vous connecter à un service exécuté sur l'hôte (tout type de service, par exemple une API ou une base de données qui s'exécuterait directement sur l'hôte), vous devez déterminer l'adresse IP de l'hôte.

Une façon consiste à s'appuyer sur le fait que l'hôte Docker est accessible via l'adresse du pont Docker, qui se trouve être la passerelle par défaut du conteneur. En d'autres termes, une analyse intelligente de ip route ls | grep ^default pourrait être tout ce dont vous avez besoin dans ce cas. Bien sûr, cela repose sur un détail d'implémentation (la passerelle par défaut se trouve être une adresse IP de l'hôte Docker) qui pourrait changer à l'avenir.

Une autre façon consiste à utiliser l'API Docker pour récupérer ces informations. Ensuite, le problème devient "comment puis-je me connecter à l'API Docker à partir d'un conteneur ?", et une solution potentielle (utilisée par de très nombreux conteneurs !) consiste à lier le montage /var/run/docker.sock de l'hôte à le conteneur. Cela a un gros inconvénient : l'API devient disponible dans son intégralité pour le conteneur, ce qui peut en faire de mauvaises choses.

À long terme, Docker exposera une meilleure API d'introspection, permettant d'accéder à ces informations sans donner trop de privilèges aux conteneurs.

TL, DR : à court terme, vérifiez la route par défaut du conteneur. À long terme, il y aura une superbe API d'introspection.

J'ai aussi un problème dû à un parvenu. Je ne trouve rien dans /var/run/docker.sock. et utilisé la commande "-v /etc/run/docker.sock:/etc/run/docker.sock" mais rien ne s'est passé.
Je pense que le problème est dû à de nouvelles mises à jour sur les capacités du noyau. s'il vous plaît donnez-moi une brève note sur cette question. et commande complète pour résoudre ce problème. Merci

utilisez -v /var/run/docker.sock - pas /etc (qui est normalement réservé aux fichiers conf).

une mise à jour à ce sujet dans la nouvelle version 1.0.0 ?

Il y a nsenter - mais je pense que la manière encouragée est d'exécuter sshd à ce
étape.

Le vendredi 13 juin 2014, Camilo Aguilar [email protected] a écrit :

des nouvelles à ce sujet dans la nouvelle version 1.0.0 ?

—
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/dotcloud/docker/issues/1143#issuecomment -45958769.

Michael D. Neale
domicile : www.michaelneale.net
blog : michaelneale.blogspot.com

vrvolle, merci pour cela. Beaucoup de gens comme nous recherchent une petite friandise comme celle-ci

netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'

Docker met automatiquement à jour /etc/hosts sur chaque conteneur avec l'adresse IP de l'hôte, par exemple 172.17.42.1 et l'appelle par exemple dockerhost serait une solution pratique.
Je suppose que pour l'instant nous sommes coincés avec netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}'

+1 pour dockerhost en /etc/hosts

+1 pour dockerhost dans /etc/hosts, cela semble être une bonne idée

La modification d'un fichier dans une image ne doit jamais être effectuée SAUF si vous donnez spécifiquement un argument ou un indicateur pour le faire. De plus, il n'est pas obligatoire que 100% des images suivent le LSB, il se peut donc qu'il n'y ait même pas de répertoire /etc . Le nom de fichier à utiliser pour contenir l'adresse IP de l'hôte doit également être spécifié par l'argument de la commande.

docker --host /etc/hosts

+1 pour dockerhost dans /etc/hosts

+1 pour une entrée /ec/hosts

@Sepero docker remplit déjà /etc/hosts avec les conteneurs liés, donc vos arguments ne tiennent pas vraiment.

@matleh C'est vrai, mais je pense que la bonne façon n'est pas de remplir directement /etc/hosts, ou au moins de nous laisser spécifier l'emplacement au cas où nous ne l'aurions pas.

Quoi qu'il en soit, l'entrée dockerhost dans hosts.

J'aimerais aussi avoir l'adresse IP de l'hôte docker dans /etc/hosts .

+1 sur l'IP de l'hôte docker dans /etc/hosts

Une meilleure façon de faciliter l'accès aux services réseau sur l'hôte serait peut-être de faciliter la configuration des entrées iptables qui transmettent les ports en sens inverse, c'est-à-dire du conteneur vers l'hôte. Je pense que l'option -p ou --publish serait bien complétée par une option -s ou --subscribe qui a l'effet inverse. Je suppose que je les aurais appelés --forward et --reverse, cependant. Peu importe comment vous l'appelez, cela me semble une approche beaucoup plus cohérente que les autres suggestions ici.

Cela pourrait être une évidence, mais un moyen simple de le faire, qui fonctionne actuellement et qui dépend peut-être moins de l'implémentation, serait de déterminer l'adresse IP sur l'hôte avant de démarrer le conteneur et de définir une variable d'environnement dans le conteneur de manière appropriée. Le long de ces lignes:

#!/bin/bash
HOSTNAME=$(hostname)
HOST_IP=$(ip route | awk '/docker/ { print $NF }')
docker run -e HOST=$HOSTNAME -e HOST_PORT=tcp://$HOST_IP:8000 mycontainer

Ce serait essentiellement parallèle au fonctionnement de --link . Cela dépend toujours du pont ayant un nom qui correspond /docker/ et qu'il n'y ait qu'un seul pont de ce type, mais le pont est défini lorsque le démon docker est démarré. Ce serait bien si docker info nous donnait le nom du pont utilisé et/ou l'adresse IP de l'hôte. Une autre idée serait d'ajouter une option --link-host PORT à docker run qui ferait essentiellement ce qui précède.

OMI c'est la meilleure option. Avec --link-host , le conteneur n'aurait pas besoin de savoir si le service auquel il accède se trouve sur l'hôte ou dans un autre conteneur.

Je ne sais pas comment les autres invoquent leurs conteneurs, mais lorsque je les exécute avec le --net=host , je peux voir la même configuration réseau que mon hôte docker. Sans ce commutateur, j'obtiens une pile réseau autonome, comme décrit dans les pages de manuel docker-run .

$ docker run -i --net=host fedora ip route ls
default via 10.0.2.2 dev eth0  metric 1
10.0.2.0/24 dev eth0  proto kernel  scope link  src 10.0.2.15
127.0.0.1 dev lo  scope link
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1
192.168.59.0/24 dev eth1  proto kernel  scope link  src 192.168.59.103

courir sans le commutateur donne ceci:

$ docker run -i fedora ip route ls
default via 172.17.42.1 dev eth0
172.17.0.0/16 dev eth0  proto kernel  scope link  src 172.17.0.4

Ce que nous recherchons est une méthode pour obtenir l'adresse IP de 10.0.2.15 (l'IP de l'i/f eth0 de mon hôte docker) ou 172.17.42.1 (l'IP de l'i/f du pont docker0 de mon docker).

Je ne me soucie pas particulièrement de l'approche consistant à ajouter un hôte à mon fichier conteneurs /etc/hosts, cela me semble un peu hackey. Au lieu de cela, avoir ces informations exposées en interne afin que je puisse les saisir en cas de besoin semble être la manière la plus prudente d'aller ici.

+1 pour --link-host ou une autre manière intuitive

+1 pour une entrée /etc/hosts
Cela semble assez pratique et suit les conventions de communication actuelles.

Juste pour clarifier mes commentaires précédents : ce qui est génial avec --link <container>:<alias> , c'est qu'il expose un _service_ via un _alias_. De même, un mécanisme d'exposition de l'hôte au conteneur doit permettre d'accéder à un service spécifique, et pas seulement à une adresse IP. Le conteneur accéderait à ce service via un alias ; il ne devrait pas avoir besoin de savoir où se trouve réellement le service. L'option doit avoir la sémantique inverse de -p et se comporter comme --link . En d'autres termes, --link-host <ip address>:<port>:<alias> configurerait des variables env et une entrée /etc/hosts , et configurerait des entrées iptables si nécessaire, c'est-à-dire si le service sur l'hôte écoute sur une adresse IP qui est autrement inaccessible au conteneur.

@altaurog Que diriez-vous de quelque chose comme ça?

docker run --name someservice -d host-exposing-image --expose 8000

someservice serait simplement n'importe quel nom que vous pouvez ensuite --link , et host-exposing-image serait une image spéciale qui transmet les ports hôtes sur les ports exposés. L'idée serait probablement réalisable en partageant les /var/run/docker.sock de l'hôte avec l'image.

Peut-être que quelque chose comme ça existe déjà, je ne sais pas.

Éditer:

docker run --name someservice -d --expose 8000 host-exposing-image

Oubliez ce qui précède, n'avez pas lu tous les commentaires ici (toujours pas). C'est ce qui fonctionne pour moi sur docker-osx (et désolé de ne pas poster sur la liste de diffusion à la place):

docker run --rm -ti -e HOST_IP="$(docker-osx ssh -c 'route -n' 2> /dev/null |
  awk '/^0.0/ { print $2 }')" debian:jessie

+1. --link-host est une bonne idée ainsi que d'avoir juste une entrée dockerhost dans /etc/hosts

J'ai créé un nouveau problème car ce problème est clos (mais pas résolu) : #8395

+1 pour dockerhost ou tout autre moyen pratique.

+1 pour tout moyen pratique

Comme l'approche dockerhost a obtenu quelques votes ici, le moyen le plus simple que j'ai trouvé (des commentaires aux 3 problèmes liés #8395 #10023) pour avoir une telle entrée d'hôtes est d'ajouter l'argument --add-host=dockerhost:$(ip route | awk '/docker0/ { print $NF }') lors de l'exécution de l'image, par exemple :

run --add-host=dockerhost:$(ip route | awk '/docker0/ { print $NF }')  ubuntu ping -c2 dockerhost

Bien que cela ajoute l'entrée /etc/hosts requise, il est toujours dommage que dockerhost ne soit pas là par défaut. Lors de la distribution d'une image, j'ai le choix entre

• demander aux utilisateurs d'ajouter le paramètre ci-dessus
• exécuter des scripts dans le conteneur qui adaptent les fichiers de configuration en fonction de la table de routage

Personnellement, je ne comprends pas pourquoi dockerhost n'est pas là par défaut, cela rendrait la création et la distribution d'images qui accèdent aux services généralement sur l'hôte (XServer, CUPS, Puleaudio) tellement plus pratiques.

+1 pour dockerhost. En fait, je l'exposerais à la fois comme une variable env, une entrée /etc/hosts et un indicateur cli. Il est lié à être utilisé de plusieurs façons.

:+1: pour dockerhost

à l'intérieur de votre conteneur :

cat << EOF > /etc/profile.d/dockerhost.sh
 grep dockerhost /etc/hosts || echo $(ip r ls | grep ^default | cut -d" " -f3) dockerhost >> /etc/hosts
EOF

fonctionne pour moi chaque fois que je me connecte (avec un compte root)

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost :miam:

+1 pour dockerhost

+1 pour dockerhost :+1:

J'ai fini par écrire ce script, quelqu'un pourrait le trouver utile :

#!/bin/bash

SED="$(which sed)"
NETSTAT="$(which netstat)"
GREP="$(which grep)"
AWK="$(which awk)"
CAT="$(which cat)"


$SED '/dockerhost$/d' /etc/hosts > /etc/hosts.tmp
DOCKERHOST="$($NETSTAT -nr | $GREP '^0\.0\.0\.0' | $AWK '{print $2}')"

echo "$DOCKERHOST dockerhost" >> /etc/hosts.tmp

$CAT /etc/hosts.tmp > /etc/hosts

rm -rf /etc/hosts.tmp

+1 hôte docker

Comme il y a beaucoup d'intérêt pour ce sujet, je pense qu'il serait logique, au lieu de discuter d'un ticket fermé, d'ouvrir une nouvelle demande de fonctionnalité.

J'ai ouvert https://github.com/docker/docker/issues/8395 il y a quelque temps - fermé également. Toujours pas de solution documentée

ok, bien qu'il existe des solutions de contournement, je pense que la raison principale est probablement que l'accès à l'hôte est un cas d'utilisation partiellement isolé.

comme il existe une fonctionnalité de liens docker, je dirais qu'il est logique de pouvoir fournir un lien vers l'hôte.

Peut-être que https://github.com/docker/docker/pull/10902 le résout

Bonjour!

Pour info c'est maintenant documenté :

Remarque : Parfois, vous devez vous connecter à l'hôte Docker, ce qui signifie obtenir l'adresse IP de l'hôte. Vous pouvez utiliser les commandes shell suivantes pour simplifier ce processus :

$ alias hostip="ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print \$2 }'"
$ docker run --add-host=docker:$(hostip) --rm -it debian

Merci, @icecrime.

Une personne docker peut-elle verrouiller ce problème afin que les gens arrêtent de le mettre à jour ?

+1 pour dockerhost

+1 pour dockerhost - devoir exécuter une commande locale alias hostip n'est pas compatible avec, par exemple, docker-compose, docker-swarm, etc., etc.

+1 pour dockerhost

@icecrime , qui donne la passerelle de l'hôte et non l'adresse IP de l'hôte sur mon ubuntu. Ne devrait-il pas s'agir uniquement de la commande ci-dessous ?

$ ip address show

+1, quelque chose d'utilisable sans avoir à exécuter de commandes serait idéal

Comment cela n'est-il toujours pas résolu ? L'exécution de commandes dans un conteneur pour rendre la mise en réseau du conteneur à l'hôte fonctionnelle est totalement inacceptable.

+1 pour tout ce qui est simple
BTW la solution de contournement avec ip fonctionne sur mon Ubuntu, mais ne fonctionne pas sur OS X, n'est-ce pas?

+1 Ceci est un problème de 2 ans et une fonctionnalité utile. Je veux un moyen simple de me connecter à l'API distante Docker depuis l'intérieur d'un conteneur.

@ianchildress si votre démon est configuré pour accepter les connexions de socket, montez simplement le socket dans votre conteneur, par exemple docker run -d -v /var/run/docker.sock:/var/run/docker.sock myimage

+1 pour dockerhost
Trouvé ce problème lors de la recherche de solutions pour utiliser le cas : xdebug.remote_host=dockerhost

+1 pour dockerhost

@thaJeztah et comment puis-je accéder au nom d'hôte ou à l'adresse IP à partir de là ?

@mbonaci Je répondais à @ianchildress , qui souhaitait se connecter à l'API Docker à l'intérieur d'un conteneur (pour lequel l'utilisation d'une connexion socket est l'approche générale)

Je suis confus. @icecrime ci-dessus a dit ci-dessus que cela est maintenant documenté, mais le lien qu'il a donné est mort. Je ne trouve pas rapidement la partie citée de la documentation. Je note que l'exemple apt-cache-ng utilise dockerhost, mais ne définit pas ce que c'est (#11556). La seule référence que j'ai pu trouver facilement était ce fil. J'ai recherché toutes les sources et la documentation de docker et cela ne semble pas être mentionné dans ce contexte .

@pwaller Depuis mars, nous avons divisé cet énorme long document en références distinctes. Le nouvel emplacement de ce matériel est :

http://docs.docker.com/reference/commandline/run/#adding -entries-to-a-container-hosts-file

+1 pour dockerhost

@moxiegirl Je pense que le paramètre --add-host est satisfaisant. Merci

Et comment se connecter à l'hôte à partir du conteneur docker ? Par exemple, pour faire git pull? Sans volumes à l'aide?

@a93ushakov tout est expliqué dans le lien fourni par @moxiegirl .
Lorsque vous faites docker run , ajoutez le paramètre suivant : --add-host=dockerhost:replace_with_docker_host_ip , qui crée une entrée dans le fichier /etc/hosts du conteneur.
Ce qui, bien sûr, signifie que vous pouvez vous référer à votre hôte docker depuis ce conteneur en utilisant son nom, dockerhost .

@mbonaci > Ce qui, bien sûr, signifie que vous pouvez vous référer à votre hôte docker depuis ce conteneur en utilisant son nom, dockerhost.

Via ssh ?

@thaJeztah > si votre démon est configuré pour accepter les connexions socket, ...
Comment faire cela ?

@a93ushakov SSH : si vous l'avez installé et exécuté sur l'hôte (et que son port n'est pas bloqué), oui.

@a93ushakov @thaJeztah fait référence à la connexion socket Unix. Je pense que c'est la valeur par défaut - voyez si vous avez un fichier /var/run/docker.sock sur votre hôte.

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost
Ce serait bien d'obtenir ce nom d'hôte sans aucune étape supplémentaire.

1 pour dockerhost

+1 pour dockerhost

Impossible de se connecter à l'hôte Docker depuis l'intérieur d'un conteneur. Des idées sur ce que je fais mal?

$ hostip=$(ip route show 0.0.0.0/0 | grep -Eo 'via \S+' | awk '{ print $2 }')
$ nc -l -p 1234 &
[1] 17361
$ docker run --add-host=docker:$(hostip) --rm -it hiromasaono/curl curl docker:1234
curl: (7) Failed to connect to docker port 1234: Connection refused

+1 pour dockerhost

Lorsque j'ajoute l'adresse IP du pont Docker, cela fonctionne.

Première écoute sur le port 1234 avec netcat

$ nc -l -p 1234

Obtenir l'IP du pont

$ ifconfig docker0 | grep 'inet addr'
          inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0

Connectez-vous ensuite

$ docker run --add-host=docker:172.17.42.1 --rm -it hiromasaono/curl curl 172.17.42.1:1234

Puis je vois la réponse

GET / HTTP/1.1
User-Agent: curl/7.35.0
Host: 172.17.42.1:1234
Accept: */*

+1 pour dockerhost
Merde, quand ?

+1 pour dockerhost qui fonctionne également sur Mac, c'est-à-dire qui gère la VM de manière transparente

Quelqu'un pourrait-il me dire comment vais-je appeler l'API Docker depuis l'intérieur du conteneur ? Je ne suis pas un gars Linux. J'ai déjà démarré le conteneur avec -v /var/run/docker.sock:/var/run/docker.sock .
Tout le monde parle de la façon de faire le montage, mais personne n'a mentionné comment appeler api à l'intérieur.

J'ai essayé d'appeler en utilisant curl, cela n'a pas fonctionné. J'ai utilisé l'adresse IP de l'hôte, par exemple

curl -XGET http://hostip :2375/images/json

C'est ainsi que j'ai démarré mon démon. c'est-à-dire docker -H unix:///var/run/docker.sock -H tcp://0.0.0.0 :2375

Toute aide est la bienvenue.

@jprogn le suivi des problèmes github n'est pas destiné aux questions d'assistance générales ; il est préférable de poser ces questions dans le canal IRC #docker, le groupe docker-users sur Google ou forums.docker.com

Cette question est liée au sujet d'origine, auquel il n'a pas été répondu complètement. S'il vous plaît voir le titre ci-dessus

Quelqu'un peut-il répondre s'il vous plaît comment appeler docker api à l'intérieur du conteneur ??????????????

@jprogn veuillez suivre mon commentaire ci-dessus ; il s'agit d'un outil de suivi des problèmes, utilisé pour suivre les bogues et les demandes de fonctionnalités ; pas un forum de support pour l'utilisation de docker ; utilisez les autres méthodes que j'ai mentionnées ci-dessus https://github.com/docker/docker/issues/1143#issuecomment -146924892

+1 pour dockerhost

Sur mon hôte docker CentOS7, je ne peux pas obtenir de route du conteneur à l'hôte :

[root@docker-host-fkb slehmann]# ifconfig docker0 | grep 'inet'

inet 172.17.42.1  netmask 255.255.0.0  broadcast 0.0.0.0
inet6 fe80::42:a7ff:fe4d:4cb2  prefixlen 64  scopeid 0x20<link>


[root@docker-host-fkb slehmann]# docker run --add-host=docker:172.17.42.1 --rm -it hiromasaono/curl curl 172.17.42.1:1234

curl: (7) Failed to connect to 172.17.42.1 port 1234: No route to host

Des idées?

+1, Peut-être qu'il devrait y avoir une variable d'environnement pour cela.

Moi-même, je voudrais que ce soit l'inverse; un lien de ma machine hôte vers les conteneurs docker par nom

+1 pour la variable d'environnement dockerhost

Il est vraiment difficile de combiner une entrée DNS sur mesure accédant à l'hôte sans coder en dur 172.17.42.1. par exemple

extra_hosts:
     - "docker:172.17.42.1"

+1 pour dockerhost n'importe où (/etc/host d'ENV)

+1 c'est encore nécessaire !

mon +1 aussi parce que l'ajout ip route list dev eth0 | grep -Eo 'via \S+' | awk '{ print \$2 }' à chaque projet (car en dev, tous les projets sont dans le même hôte et doivent pouvoir s'appeler) commence à ressembler à un mauvais piratage

Comment résoudre ce problème dans un cluster, par exemple Docker Swarm, où nous ne savons pas à quelle machine un conteneur sera affecté lorsque nous l'exécuterons ? L'adresse IP de la passerelle docker0 peut être différente d'un hôte à l'autre au sein du cluster swarm, nous ne pouvons donc pas simplement exécuter la commande ip route sur un hôte et supposer ensuite que l'adresse IP est la même pour tous les hôtes.

J'aimerais également pouvoir mapper un port de conteneur sur un port du pont docker0 sans avoir à connaître l'adresse IP du pont docker0. Quelque chose comme ça:

eval $(docker-machine env --swarm swarm-master-node)
docker run -d -p "$HOST_GATEWAY_IP:80:80" my-image

$HOST_GATEWAY_IP est remplacé par la même adresse IP que vous obtiendriez en exécutant la commande ip route sur l'hôte sur lequel le conteneur est finalement déployé dans le cluster.

Cela devrait être pris en charge pour toutes les autres commandes impliquant des adresses IP, par exemple l'option --dns sur docker run .

J'ai trouvé cette commande plus simple :

ip ro | grep docker | sed 's|.* \(\([0-9]\+\(.[0-9]\+\)\{3\}\)\)\s*|\1|'

+1 pour dockerhost dans /etc/hosts

+1 hôte docker

+1 pour avoir dockerhost dans /etc/hosts

+1000 pour dockerhost

+1 hôte docker

+1

+1 ou plus.

J'exécute un serveur Web dans un conteneur et j'ai besoin de le connecter à mon mysql exécuté sur l'hôte.
L'adresse IP de l'hôte change avec DHCP, donc quelque chose de dynamique est indispensable.

@wederbrand une approche alternative (et probablement plus performante) pourrait être de se connecter au socket mysql, par exemple ;

docker run -v /var/lib/mysql/mysql.sock:/mysql.sock mywebapp

Cela rendrait le socket MySQL disponible en tant que /mysql.sock à l'intérieur du conteneur

@thaJeztah Cela pourrait être une option. Cependant, l'image docker que j'utilise est également utilisée pour d'autres environnements où le serveur mysql est sur un serveur distant et l'image a une configuration pour host:port pour la base de données.

J'aimerais que mon conteneur se comporte aussi près que possible de celui en production, donc pas de bricolage avec les propriétés de connexion, sauf pour définir l'hôte et le port.

+1

+1

+1

+1

@peterbollen @radek1st @BradRuderman @aldarund @wederbrand @pataiadam @jllado @geniousphp @coreylenertz @dgtlmoon @xlight (tous +1 en décembre 2015 seulement)
_ce_ problème est clos ainsi que #8395
Je ne pense pas que l'ajout de +1 à un ancien problème aidera. Créez-en un nouveau (je l'ai fait avec # 8395) ou essayez un autre itinéraire pour résoudre ce problème.

THX!

+1

+1 hôte docker

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost, allez...

+1 pour dockerhost

l'utilisation de docker-compose et la mise à l'échelle des conteneurs n-aires dans un essaim ne fournissent pas naturellement un moyen d'effectuer des recherches d'adresse IP de nœud à la volée sur toutes les machines.

Ceci, comme indiqué ci-dessus et modifié pour la passerelle, n'est pas une option :

extra_hosts:
     - "docker:172.18.0.1"

👍 pour dockerhost aussi...

+1 pour dockerhost

+1

+1

+1

+1 hôte docker

+1 hôte docker

+1 hôte docker

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost.
Puisque ce problème est clos, j'ouvre un nouveau ticket.

+1

+1

Pour obtenir l'hôte dans une configuration docker-machine , vous pouvez utiliser cette commande :

docker-machine ssh "${DOCKER_MACHINE_NAME}" 'echo ${SSH_CONNECTION%% *}'

Il signale la machine à laquelle vous vous connectez via ssh , il devrait donc fonctionner raisonnablement bien à la fois pour les machines locales et pour les machines distantes, tant qu'il n'y a pas de NAT en cours de route. Ce serait bien si docker-machine inspect signalait également cette valeur quelque part, si cela est techniquement faisable.

+1

+1 pour dockerhost . Cela ressemble à une fonctionnalité précieuse avec pratiquement aucun effort à mettre en œuvre.

Pour l'instant, si vous avez besoin d'accéder à dockerhost dans des conteneurs créés à partir d'images que vous contrôlez, vous pouvez ajouter cet élément essentiel au script entrypoint.sh pour votre image : https://gist.github.com/dimitrovs/493678fd86c7cdf0c88312d9ddb4906b

Ou je suppose que vous pouvez l'ajouter à /etc/rc.local si votre image n'utilise pas de script shell comme point d'entrée. Ce que fait cet essentiel, c'est qu'il vérifie dockerhost dans /etc/hosts et l'ajoute s'il n'y est pas. Cela devrait se produire à chaque démarrage du conteneur.

Extrayez l'adresse IP de la passerelle de /proc/net/route :

export ipaddr=$(printf "%d." $(
  echo $(awk '$2 == "00000000" {print $3}' /proc/net/route) | sed 's/../0x& /g' | tr ' ' '\n' | tac
  ) | sed 's/\.$/\n/')

@dimitrovs Pouvez-vous montrer un exemple de configuration ? J'ai bricolé avec ça et je n'ai pas pu obtenir les bons résultats.

Quels résultats obteniez-vous @amcdnl ? Vous pouvez soit mettre l'essentiel que j'ai lié dans le fichier entrypoint.sh pour qu'il s'exécute à chaque démarrage du conteneur, soit dans /etc/rc.local à l'intérieur du conteneur. Vous devrez le faire lorsque vous créerez l'image, mais le script lui-même s'exécutera au démarrage d'un conteneur.

+1 pour l'hôte docker

@dimitrovs J'ai fini par écrire un script qui générerait une composition à l'exécution.

StartDocker.sh

#!/bin/bash
built_docker_file="docker-compose.dev.built.yml"

rm -rf docker-compose.dev.built.yml
localhost_ip="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"
sed -e "s/\${localhost}/$localhost_ip/" docker-compose.dev.template.yml > $built_docker_file

docker-compose -f $built_docker_file build
docker-compose -f $built_docker_file up

docker-compose.dev.template.yml

version: '2'

services:
  nginx:
    container_name: sw_nginx
    image: nginx:latest
    ports:
      - 80:80
    links:
     - search
    volumes:
      - ./Web/wwwroot:/var/www/public
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    extra_hosts:
      - "dockerhost:${localhost}"

@amcdnl Bonne solution de contournement. Notez que docker-compose prend en charge la substitution de variables (d'environnement).

par exemple (bash):

$ export localhost=$(...)
$ docker-compose (...)

@sebastiannm ma suggestion devrait être indépendante de l'hôte car elle s'exécute à l'intérieur de l'image docker, mais si vous l'exécutez sur Mac dans VirtualBox, l'adresse IP que vous obtiendrez est l'adresse IP de la machine virtuelle VirtualBox, pas votre adresse IP Mac. Je pense que c'est l'exigence dont nous discutons. Si vous souhaitez connaître l'adresse IP Mac à partir d'une instance Docker, une approche différente est nécessaire.

+1 pour dockerhost.

Mais pour l'instant, je fais un hack similaire à celui posté ci-dessus, qui vous permet d'obtenir dynamiquement l'adresse IP de l'hôte avec un simple script qui fonctionne à la fois sous Linux et OSX : http://stackoverflow.com/questions/24319662/from-inside -d'un-conteneur-docker-comment-se-connecter-à-l'hôte-local-du-mach#38753971

+1 pour dockerhost.

+1 pour dockerhost

+1+1 hôte docker

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

Je ne parviens pas à me connecter à un serveur netcat hôte de base à partir d'un conteneur Docker lorsque --net=bridge (valeur par défaut) via les différentes techniques décrites dans ce numéro.

@frankscholten Je ne parviens pas à reproduire votre test netcat réussi

J'ai créé un problème de stackoverflow décrivant le problème exact : http://stackoverflow.com/questions/38936738/communicate-to-docker-host-from-docker-container
et je voulais poster ici au cas où cela aiderait quelqu'un à l'avenir

Bien que tout cela parle de la communication du conteneur à l'hôte en utilisant docker0 ip en mode pont, je veux savoir si le conteneur peut également parler à l'adresse IP publique de l'hôte (disons son adresse IP eth0 d'origine). Appréciez votre réponse. Je n'ai pas réussi à cela.

@sburnwal Je ne vois pas pourquoi vous ne pourriez pas communiquer avec l'adresse IP eth0 de l'hôte. Le conteneur enverra une demande à sa passerelle par défaut (docker0) et l'hôte devrait répondre sans autre transfert car il sait qu'il a l'adresse IP. Vos pings vers l'adresse IP eth0 du conteneur expirent-ils ou vous n'obtenez aucune route vers l'hôte ou que se passe-t-il ? Le conteneur peut-il se connecter à Internet ?

Malheureusement, cela ne fonctionne pas pour moi. Bien que je puisse envoyer un ping à l'adresse IP du conteneur à partir de l'hôte, je ne peux pas envoyer de ping à l'adresse IP de l'hôte (LAN/eth0 de l'hôte) à partir du conteneur. J'utilise docker 1.9.1. Je suis coincé ici car j'ai besoin que mon conteneur communique avec le serveur Web en écoutant uniquement l'adresse IP eth0 de l'hôte.

J'ai personnalisé docker0 en utilisant l'option :
/bin/démon docker --bip=169.254.0.254/24 --fixed-cidr=169.254.0.0/24

J'ai donc ces interfaces sur mon hôte (ne répertoriant pas les interfaces veth * ici):

[root@pxgrid-106 irf]# ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtg 1500
        inet 169.254.0.254  netmask 255.255.255.0  broadcast 0.0.0.0
        inet6 fe80::42:84ff:fe87:d510  prefixlen 64  scopeid 0x20<link>
        ether 02:42:84:87:d5:10  txqueuelen 0  (Ethernet)
        RX packets 512  bytes 150727 (147.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 653  bytes 281686 (275.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtg 1500
        inet 172.23.166.176  netmask 255.255.255.128  broadcast 172.23.166.255
        inet6 fe80::20c:29ff:fecc:7d0f  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:cc:7d:0f  txqueuelen 1000  (Ethernet)
        RX packets 58462  bytes 12056152 (11.4 MiB)
        RX errors 0  dropped 69  overruns 0  frame 0
        TX packets 30877  bytes 18335042 (17.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Mon conteneur a l'adresse IP 169.254.0.2 et je peux envoyer un ping à cette adresse IP du conteneur depuis l'hôte. Bien sûr, je peux cingler depuis le conteneur sa passerelle 169.254.0.254 (docker0 ip) mais je ne peux pas pinger l'hôte eth0 ip 172.23.166.176.

J'ai essayé en arrêtant complètement le pare-feu et j'ai également ajouté ces règles explicites au pare-feu à la chaîne INPUT, mais sans succès pour le moment. Qui peut m'aider là-dessus ? Ou est-ce un bug ?

ACCEPT     all  --  172.23.166.176       169.254.0.0/24      
ACCEPT     all  --  169.254.0.0/24       172.23.166.176   

De plus, permettez-moi également de donner la sortie 'ip route' sur mon hôte :

[root@pxgrid-106 bin]# ip route
default via 172.23.166.129 dev eth0 
169.254.0.0/24 dev docker0  proto kernel  scope link  src 169.254.0.254 
172.23.166.128/25 dev eth0  proto kernel  scope link  src 172.23.166.176 

@tn-osimis merci pour la suggestion, j'ai mis à jour et fonctionne bien, voici mon code pour les autres :

docker-compose.yml

version: '2'

services:
  nginx:
    image: nginx:latest
    ports:
      - 80:80
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    extra_hosts:
      - "dockerhost:${localhost_ip}"

StartDocker.sh

#!/bin/bash
dev_docker_file="docker-compose.yml"

export localhost_ip="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"

docker-compose -f $dev_docker_file build
docker-compose -f $dev_docker_file up

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

La solution de @magicalbob est en effet magique 🎉

+1 pour dockerhost

+1, au fait, pourquoi est-ce fermé ? Le problème/demande de fonctionnalité n'a pas encore été résolu

Des mises à jour à ce sujet ? Quelle est la bonne façon ?

+1

Quelqu'un a-t-il une mise à jour sur la façon de se connecter à l'hôte (adresse IP publique de l'hôte comme eth0 ip et non docker0 interface ip) à partir du conteneur?

@sburnwal docker run --add-host=publicip:$(hostname --ip) ubuntu ping -c2 publicip

Voir la réponse de @retog

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

le laisser ici car peut-être que cela aidera au moins certains d'entre vous:

On m'a dit que l'interface réseau par défaut ne doit pas toujours être docker0 aussi, obtenir l'IP docker0 ne fonctionnera pas sur des systèmes autres que Linux, c'était un problème pour nous parce que certains d'entre eux nos développeurs utilisent des macs

donc au lieu d'utiliser les scripts magiques pour obtenir l'adresse IP de l'hôte à partir de la connexion réseau, il m'a été recommandé de forcer les paramètres réseau du conteneur au lieu d'essayer de le découvrir par programme

J'ai configuré les paramètres réseau docker dans mon fichier docker-compose comme ceci :

``` réseaux :
défaut:
pilote: pont
IPAM :
configuration :
- sous-réseau : 10.10.0.0/24
passerelle : 10.10.0.1

if you are only running one container, you could first create a network (`docker network create`) and connect to it with `docker run --network=<network-name>|<network-id> <image name>`

BUT if you don't want to do this (i.e. force the docker network) and really want to get the default gateway IP, you could get it more cleanly than using `docker0` network interface, for example by parsing the `docker network inspect <network name>`, which outputs the gateway IP (among other things):

...
"IPAM": {
"Pilote": "par défaut",
"Configuration": [
{
"Sous-réseau": "172.17.0.1/16",
"Passerelle": "172.17.0.1"
}
]
}
...

you could also use the `--format` option of `docker network inspect` to get only the fields that are of interest, like this:

$ docker network inspect bridge --format='{{range .IPAM.Config}}{{.Gateway}}{{end}}'
$ 172.17.0.1
```

REMARQUE: s'il y avait plus d'entrées .IPAM.Config , vous les obtiendriez toutes dans la sortie, donc une logique supplémentaire pour choisir la bonne serait nécessaire

+1 pour dockerhost

Notez que cela serait très utile lorsque vous souhaitez simplement utiliser xdebug dans un conteneur php-fpm pour vous connecter à votre IDE pour le débogage, car vous ne pouvez évidemment pas exécuter un IDE dans un conteneur.

+1 pour dockerhost

Mon résumé des hackarounds ci-dessus :

en docker-compose.yml :

nginx:
  restart: always
  build: ./nginx/
  ports:
    - "80:80"
  extra_hosts:
    # requires `export DOCKERHOST="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"` in ~/.bash_profile
    - "dockerhost:$DOCKERHOST"

en ~/.bash_profile :

# see https://github.com/docker/docker/issues/1143
export DOCKERHOST="$(ifconfig en0 inet | grep "inet " | awk -F'[: ]+' '{ print $2 }')"

en nginx-conf :

location / {
        proxy_pass http://dockerhost:3000;
        proxy_set_header host $host;
        proxy_set_header x-real-ip $remote_addr;
        proxy_set_header x-forwarded-for $proxy_add_x_forwarded_for;
}

J'ai tendance à utiliser l'image docker svendowideit/ambassador pour contourner ce problème.

Par exemple, si je veux me lier à un nœud elasticsearch exécuté sur l'hôte Docker :

docker run --restart always -d --name elasticsearch --expose 9200 -e ELASTICSEARCH_PORT_9200_TCP=tcp://<host>:9200 svendowideit/ambassador

Désormais, d'autres conteneurs docker peuvent simplement trouver elasticsearch en utilisant --link elasticsearch, tout en restant agnostiques quant à savoir si elasticsearch s'exécute dans un conteneur docker, sur l'hôte ou ailleurs.

+1 pour dockerhost

... pour l'instant si vous pourriez faire ceci:

$ docker build --build-arg HTTP_PROXY=172.16.42.1 .

... ou dans mon cas similaire avec docker-compose - je fais ceci :

client:
        build: ./client
        extra_hosts:
            - "foobar:${HTTP_PROXY}"

définissez votre hôte au moment de la construction :

export HTTP_PROXY=172.16.42.1 && docker-compose build

@rattrayalex sur mac, j'ai trouvé ceci imprime directement l'adresse IP : ipconfig getifaddr en0

+1 pour dockerhost

Ceux d'entre vous qui font juste +1 pour dockerhost peuvent-ils simplement ajouter un coup de pouce (réaction) à un commentaire existant de même nature ? +1 commentaires ne font qu'étendre/remplir inutilement ce fil de discussion. Il y en a déjà tellement, pas besoin d'en rajouter, mais nous pouvons toujours utiliser un pouce levé ! 👍

Je pense que les commentateurs écrivent un +1 étendu pour souligner qu'il s'agit d'un cas d'utilisation courant, avec des solutions de contournement connues, et devrait nécessiter un temps estimable en heures pour être codé par l'équipe docker
Pourtant, il est ouvert depuis 3 ans 👍

Donc, il me semble que c'est plus un "sommes-nous encore là" ? Au lieu de cela juste un emoji

La solution @magicalbob dans https://github.com/docker/docker/issues/1143#issuecomment -233152700 fonctionne parfaitement dans chaque configuration de conteneur et pont que j'ai essayé jusqu'à présent !

la solution de https://github.com/docker/docker/issues/1143#issuecomment -70052272 ne fonctionne pas lors de l'utilisation de docker compose extra_hosts

+1 pour dockerhost

Toujours pas de dockerhost ?

+1 pour dockerhost

+1 pour dockerhost

cela n'arrivera pas, il a été fermé il y a 3 ans et ils ne prévoient jamais de mettre cela en œuvre. la même raison pour laquelle docker.sock est un footgun pour la sécurité, dockerhost l'est aussi. avoir un nom de domaine résoluble à l'intérieur de votre application est un problème de sécurité majeur à mon humble avis. si vous le devez, utilisez simplement les solutions de contournement, de manière sélective uniquement là où l'accès aux services hôtes par IP ne constituera pas une surface d'attaque accrue.

Ne soyez pas en désaccord sur le fait que cela ne se produise pas, mais je ne vois pas en quoi dockerhost représente un risque pour la sécurité à moins que vous ne fermiez également les nombreuses solutions de contournement faciles ....⁣

Envoyé par BlueMail

Le 16 décembre 2016, 17h58, à 17h58, Paulo Cesar [email protected] a écrit :

ça n'arrivera pas, il a été fermé il y a 3 ans, et ils ne prévoient jamais de le faire
implémenter cela. la même raison que docker.sock est un footgun pour la sécurité,
dockerhost l'est aussi. avoir un nom de domaine résoluble à l'intérieur de votre
l'application est un problème de sécurité majeur à mon humble avis. si vous le devez, utilisez simplement le
solutions de contournement, de manière sélective uniquement là où l'accès aux services hôtes par IP ne le sera pas
être une surface d'attaque accrue.

--
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/docker/docker/issues/1143#issuecomment -267655915

+1 pour dockerhost

+1 pour dockerhost

L'IP de la machine hôte est 192.168.0.208 .

Le fichier docker-compose est le suivant :

version: '2'
 services:
   zl-tigervnc:
     image: zl/dl-tigervnc:1.5
     container_name: zl_dl_tigervnc
     restart: always
     tty: true
     ports:
       - "8001:8888"
       - "6001:6006"
       - "8901:5900"
       - "10001:22"
     devices:
       - /dev/nvidia0
     volumes:
       - ~/data:/root/data
       - /var/run/docker.sock:/var/run/docker.sock
     extra_hosts:
       - "dockerhost:192.168.0.208"

Un conteneur a été lancé par ce script. Le conteneur veut accéder au port 8080 sur la machine hôte (par exemple 192.168.0.208:8080 ). Mais ça ne marche pas.

Cependant, j'utilise la redirection de port pour mapper 8080 sur la machine hôte à 8080 sur le routeur. L'IP du routeur était 63.25.20.83 . Le conteneur peut accéder aux 8080 de la machine hôte par redirection de port (par exemple, 63.25.20.83:8080 ).

J'ai essayé de nombreuses solutions à partir de cette page, mais cela ne fonctionne toujours pas.

Remarque, cela serait très utile lorsque vous souhaitez simplement utiliser xdebug dans un conteneur php-fpm pour
connectez-vous à votre IDE pour le débogage car vous ne pouvez évidemment pas exécuter un IDE dans un conteneur.

Exactement @colinmollenhour ! Sauf qu'il y a un problème supplémentaire. Vous pouvez envoyer un ping à l'hôte, mais vous ne pouvez pas réellement vous connecter aux ports de l'hôte (par exemple, un débogueur distant fonctionnant sur 9000).

Beaucoup de choses anciennes et/ou pas tout à fait correctes sur le net. Beaucoup de gens semblent penser que configurer un alias IP et l'attacher à l'interface lo devrait fonctionner, mais ce n'est pas le cas.

(test avec netcat sur l'hôte et telnet dans le conteneur docker, donc je suis bien dépouillé).

@bitwombat vérifie le pare-feu de votre hôte pour une règle de port 9000

@gregmartyn C'était exactement ça. Merci! Cela aurait été la première chose que j'ai vérifiée dans une configuration plus simple ! Toutes les couches de tromperie m'ont fait vérifier des choses plus étranges.

Juillet 2013 à 2017. Presque 4 ans, pourquoi n'est-ce pas encore une fonctionnalité ? Ce n'est clairement pas un cas d'utilisation isolé.

Ce n'est pas une fonctionnalité car elle ne correspond pas à la stratégie de Docker d'être une solution de gestion de déploiement multi-hôte.

Je pense toujours qu'il existe de nombreux cas d'utilisation valides et que l'ajout de la fonctionnalité ne causerait aucun préjudice à la stratégie de Docker. Quoi qu'il en soit, voici une solution assez simple pour résoudre l'adresse de l'hôte docker à partir d'un conteneur qui, je pense, devrait fonctionner de manière assez universelle :

ip route | awk '/^default via /{print $3}'

+1 pour dockerhost

Très nécessaire. +1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

+1 pour toute solution qui n'est pas une solution de contournement hacky. Rien ne fonctionne ici.

D'accord. +1 pour une solution. Vous en avez besoin pour effectuer des travaux de développement et de test sur des projets utilisant Docker.

+1 pour dockerhost

+1 pour dockerhost

+1 pour dockerhost

wow .. 4 ans et ça va fort. +1 pour dockerhost ?

+1 dockerhost !!

+1 dockerhost !!!

Ceci est probablement en sourdine. Nous devrions peut-être faire un nouveau numéro faisant référence à celui-ci.

:+1: pour dockerhost... En ce moment je le configure par env :

export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)

Cela rend les choses encombrantes.

Même quelque chose d'aussi simple que d'utiliser docker-compose dans un conteneur avec un registre privé tunnelisé par ssh ne fonctionne pas car Docker est tellement déterminé à ne pas vouloir dockerhost.

REMARQUE : ce problème est clos, il est donc inutile d'y ajouter d'autres commentaires :-)

Si vous avez besoin de cette fonctionnalité, vous pouvez facilement ajouter un alias DNS dockerhost en utilisant --add-host et les options équivalentes.

Pourquoi n'est-ce pas disponible par défaut ? Parce que cela ne fonctionne que dans des cas triviaux. C'est à dire:

• qu'en est-il des conteneurs qui _n'ont_ pas_ accès au réseau ?
• qu'en est-il des conteneurs qui ont _plusieurs_ réseaux ?
• qu'en est-il des conteneurs exécutés sur un cluster Swarm ?

Si vous avez un bon cas d'utilisation (c'est-à-dire "Je voudrais faire XXX, et pour ce faire, j'aimerais avoir dockerhost ...") ainsi que des réponses solides aux questions ci-dessus (et autres cas particuliers qui pourraient survenir), n'hésitez pas à ouvrir un nouveau numéro faisant référence à celui-ci !

Merci.

Le problème est que votre adresse IP hôte peut être dynamique et dépend du réseau sur lequel vous vous trouvez. Si vous développez, la connexion à l'hôte pour le débogage est indispensable. La raison pour laquelle tout le monde veut le dockerhost n'est pas parce que les options qui ne sont pas là sont pratiques ou utiles du tout.
Docker a des tonnes d'options qui ne sont pas pertinentes pour tous, qu'est-ce qui le rend différent ? Pourquoi ne pas avoir l'option dans docker d'activer dockerhost si nécessaire, cela rendrait 99% heureux, je suppose.

@jpetazzo

qu'en est-il des conteneurs qui n'ont pas accès au réseau ?

Ensuite, dockerhost ne fonctionnera pas.

qu'en est-il des conteneurs qui ont plusieurs réseaux ?

Ensuite, dockerhost ne fonctionnera pas.

qu'en est-il des conteneurs exécutés sur un cluster Swarm ?

On s'en fout?

Si vous développez des logiciels impliquant des composants en dehors de l'écosystème Docker (comme certains logiciels exécutés à l'intérieur d'une machine virtuelle Windows sur l'hôte), il est difficile de le connecter à Docker. Pourquoi ça doit être une douleur ?

Tous les cas que vous avez énumérés ne sont pas ce dont parlent les 226 commentaires de ce fil, ils parlent du cas de base.

Edit : Désolé, j'ai supprimé une partie de mon commentaire. Je ne voulais pas fulminer. C'est juste un peu frustrant, c'est une fonctionnalité indispensable pour certains utilisateurs de docker et si vous développez un logiciel qui l'exige, il est encore plus frustrant de devoir le contourner sans aucune raison apparente.

@jpetazzo parfois les cas "triviaux" représentent 80% des cas d'utilisation. Dockerhost serait très utile pour les personnes utilisant Docker dans des environnements de développement ou de mise en scène , ou vraiment tous les environnements qui ne reposent pas sur la mise en réseau en essaim/multi-hôte. Voici quelques exemples où j'aimerais utiliser Dockerhost :

1) Docker-Compose sur Windows avec registre privé. Nous avons un registre Docker privé auto-hébergé. Les développeurs peuvent accéder au registre via un tunnel SSH avec redirection de port (c'est-à-dire sur localhost:5000). Mais lorsque Docker-Compose s'exécute dans son propre conteneur Docker, il n'y a aucun moyen de spécifier l'hôte de registre privé. Si nous avions dockerhost , nous pourrions utiliser dockerhost:5000 dans notre fichier docker-compose.yml lui donnant accès au port transféré sur l'hôte.

2) Toute application ayant besoin de communiquer avec des services exécutés sur l'hôte. Par exemple, un client SSH basé sur le Web s'exécutant dans un conteneur docker pourrait être utilisé pour établir une connexion SSH avec l'hôte s'il y avait dockerhost . Il existe d'innombrables exemples de services exécutés sur l'hôte d'un conteneur Docker qui peuvent être utilisés s'il existe dockerhost .

3) Redirection de port inverse. Nous pouvons faire fonctionner notre serveur SSH ou OpenVPN dans un conteneur Docker et cela pourrait donner aux clients l'accès aux services exécutés sur l'hôte s'il y avait dockerhost . Vous pouvez configurer la redirection de port du conteneur vers dockerhost.

J'aimerais entendre une justification technique pour laquelle les développeurs de Moby refusent d'entendre la communauté quand il s'agit de dockerhost. Jusqu'à présent, je n'entends que des raisons politiques/commerciales.

Je suis tombé sur ce fil en essayant de trouver un moyen d'attacher une interface réseau macvlan à un service swarm... Swarm semble être une solution à moitié finie, l'incapacité d'exposer les services directement au monde extérieur est une frustration continue pour moi. On a l'impression que Docker a perdu du terrain avec les cas d'utilisation du monde réel, avance rapide de 4 ans à partir du début de ce fil et il n'y a toujours pas d'implémentation native pour que les conteneurs se gèrent eux-mêmes.

@danfromtitan voir https://github.com/moby/moby/pull/32981

Je suis relativement nouveau sur Docker. Tout ce que j'ai lu dans la documentation officielle a du sens. _Docker est en fait un outil assez facile à prendre en main._

En fait, la seule chose que j'ai passé plusieurs heures à essayer de comprendre est _comment se connecter à l'hôte à partir d'un conteneur._ Tout le reste était facile à déterminer. Je ne sais toujours pas comment faire. Beaucoup de "hacks" dans ce forum et sur SO ne fonctionnent tout simplement pas. Nous devons accéder à l'hôte afin de consommer une application héritée qui n'est pas configurée pour être "Dockerisée" pendant plusieurs mois.

Cela n'arrivera jamais, j'en ai peur Josh. Les développeurs l'ont bien précisé.
Ce qui rend docker pire qu'inutile pour une grande classe d'applications,
malheureusement, docker (ou "moby") n'a rien à foutre de ces
développeurs ou ces applications.

Le 19 juin 2017 à 01h08, "Josh Wedekind" [email protected] a écrit :

Je suis relativement nouveau sur Docker. Tout ce que j'ai lu dans la documentation officielle
logique. Docker est en fait un outil assez facile à prendre en main.

En fait, la seule chose que j'ai passé plusieurs heures à essayer de comprendre
est de savoir comment se connecter à l'hôte à partir d'un conteneur. Tout le reste
était facile à déterminer. Je ne sais toujours pas comment faire. Beaucoup de
"hacks" dans ce forum et sur SO ne fonctionnent tout simplement pas. Nous devons accéder au
hôte afin de consommer une application héritée qui n'est pas configurée pour être "Dockerisée"
pendant de nombreux mois.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/moby/moby/issues/1143#issuecomment-309311997 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AA-shyjglsJXawxHHWGhQH0d1LlZeJqxks5sFbwXgaJpZM4Ayw00
.

Il est vraiment frustrant de pouvoir gérer toutes les situations avec un simple fichier docker-compose déclaratif, mais vous devez utiliser mille astuces pour vous connecter à une application héritée depuis votre conteneur dans votre environnement de développement.
@thaJeztah Cela ne fait pas du tout une bonne première impression de docker.

Pour info, nous avons fini par abandonner Docker en production justement pour cette raison. Je sais que les développeurs de Docker sont fermement opposés à cela (et je comprends que ce n'est pas une fonctionnalité aussi triviale que certains le prétendent) mais je voulais juste intervenir : vous perdez des clients du monde réel à cause d'un refus obstiné de même envisager ce problème. En tant qu '"expert" Docker réticent dans mon entreprise, je dois maintenant mettre en garde les personnes qui me posent des questions à ce sujet en disant "Docker est génial ... sauf si vous avez besoin de communiquer avec tout ce qui s'exécute sur l'hôte local".

Donc, encore une fois, je suis sûr que le problème est en sourdine, mais si jamais vous revenez sur ce fil, développeurs Docker, cela cause une réelle douleur et oblige les vrais clients Docker à cesser d'utiliser Docker. Je recommande de reconsidérer votre refus obstiné d'aborder le problème ; ce n'est pas parce que cela ne correspond pas à votre vision de la façon dont Docker est "censé" être utilisé que c'est une fonctionnalité inutile ou inutile.

Non seulement pourraient-ils perdre des clients existants. Nous aurions pu tout migrer vers docker s'il tenait sa promesse de développement. C'est une véritable anti-promotion pour docker à utiliser à grande échelle pour tous les processus.

La façon dont je le fais fonctionner pour l'instant est de créer un réseau. Voici à quoi ressemble mon fichier docker-compose :

version: '2'
services:
  <container_name>:
    image: <image_name>
    networks:
      - dockernet

networks:
  dockernet:
    driver: bridge
    ipam:
      config:
        - subnet: 192.168.0.0/24
          gateway: 192.168.0.1

Après cela, vous pouvez accéder à l'hôte avec 192.168.0.1.
Cela pourrait être utile à certains d'entre vous puisque cette fonctionnalité ne sera pas disponible de sitôt.

@deltabweb Les demandes entrant dans les applications sur la machine hôte apparaîtront-elles en tant que trafic "localhost", ou devrai-je modifier les applications pour répondre à 192.168.0.1 ?

Merci de votre aide.

@halfnibble
Je n'ai pas regardé la documentation de networks en détail mais je crois comprendre qu'un nouveau réseau sur votre machine hôte est créé où :

• L'IP du "dockerhost" est 192.168.0.1
• L'IP du premier conteneur est 192.168.0.2
• L'IP du deuxième conteneur est 192.168.0.3
• etc ...

A partir de là, tout devrait fonctionner comme si vous aviez des machines physiques connectées entre elles sur un réseau local :

• les machines peuvent se connecter les unes aux autres
• et vous devriez même pouvoir utiliser ping 192.168.0.2 depuis l'hôte - cela ne fonctionnera que si votre conteneur répond aux pings.

Donc, pour répondre à votre question, je pense que vos applications sur la machine hôte devront répondre à 192.168.0.X (selon le conteneur essayant de se connecter).

@deltabweb comment cloud j'accède au port hôte du serveur ? >>> Connexion refusée

@nooperpudd Juste pour être sûr : vous essayez d'accéder à une application s'exécutant sur l'hôte à partir d'un conteneur, n'est-ce pas ?
Je vérifierais d'abord si l'application autorise les connexions entrantes de l'extérieur (0.0.0.0 et pas seulement localhost). Et peut-être aussi s'assurer que vous n'avez pas de pare-feu bloquant la connexion ?

@nooperpudd si vous utilisez Docker for mac vous ne pouvez pas utiliser le mode host , la solution @deltabweb ne fonctionne pas non plus pour moi (mes serveurs écoutent tous 0.0.0.0 et les pare-feux de ma machine hôte ont été désactivés, mais je reçois Connection refused chaque fois). Après environ 2 jours d'essais et d'erreurs, le seul moyen que j'ai trouvé pour résoudre ce problème est le script ci-dessous :

#!/bin/bash
export DOCKERHOST=$(ifconfig | grep -E "([0-9]{1,3}\.){3}[0-9]{1,3}" | grep -v 127.0.0.1 | awk '{ print $2 }' | cut -f2 -d: | head -n1)

# You should use DOCKERHOST env variable in your `docker-compose.yml` 
# and put it everywhere you want to connect to `localhost` of the host machine
docker-compose $@

Le seul problème avec cette approche est que si votre adresse IP change après l'exécution de vos conteneurs, vous devez les exécuter à nouveau et ils ne peuvent pas trouver votre nouvelle adresse IP.

Une observation remarquable pour moi est que la commande, qui est exécutée lors du démarrage des conteneurs Docker, ne peut pas se connecter au conteneur via son adresse IP hôte. Cependant, lorsque cette commande n'effectue pas de telles tentatives de connexion et termine son exécution avec succès, le conteneur est alors en mesure de se joindre via son adresse IP hôte.

J'ai fait cette observation lorsque j'ai essayé d'exposer les points de terminaison des instances de cluster de base de données NoSql à des clients en dehors du cluster Swarm. Après tout, ces points de terminaison doivent être configurés avec des adresses IP privées ou publiques de la machine virtuelle pour que le client externe puisse les atteindre. Cassandra est cependant conçu de telle manière que lorsqu'il démarre, il essaie de se connecter immédiatement avec l'adresse IP de l'hôte (définie comme variable d'environnement CASSANDRA_BROADCAST_ADDRESS -- voir ci-dessous) et échoue donc. D'autre part, les nœuds des réplicas Mongodb sont d'abord tous démarrés dans un état propre, puis une commande d'initialisation distincte est exécutée de sorte que les nœuds principal et secondaire puissent former un réplica.

Ci-dessous, vous voyez un compte rendu détaillé de cette observation pour cassandra (je les crée avec docker swarm mais le même problème apparaît dans docker run -d (en mode NAT, donc sans l'option --net=host)

1) D'une part, un conteneur créé par

docker service create  --name cassandra-service
--publish mode=host,target=7000,published=7000,protocol=tcp 
-e CASSANDRA_SEEDS=host IP address  -e CASSANDRA_BROADCAST_ADDRESS=host IP address

échoue avec le message indiquant qu'il ne peut pas se connecter à l'adresse d'écoute : <host IP address>:7000

2) D'autre part, un conteneur attaché à un réseau superposé, créé par

docker service create  --network cassandra-net --name cassandra-service
-e CASSANDRA_SEEDS=cassandra-service  -e CASSANDRA_BROADCAST_ADDRESS=cassandra-service

démarre correctement et en même temps je peux me connecter à l'adresse IP de l'hôte sur n'importe quel port exposé dans le Dockerfile de l'image cassandra:2.0 :

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                                         NAMES
07603a75a379        cassandra:2.0       "/docker-entrypoin..."   About a minute ago   Up About a minute   7000-7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp   cassandra-service-1.1.m243u97zku15w08m6puytdngs

$ docker exec -it 1e61ec16f8d0 bash
root<strong i="5">@1e61ec16f8d0</strong>:/# cqlsh 172.17.13.151
Connected to Test Cluster at 172.17.13.151:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]

De même, la même chose peut être observée lors de la création d'un deuxième nœud cassandra

1) Si je crée un deuxième conteneur Cassandra sur un autre nœud en

docker service create  --network cassandra-net --name cassandra-service-2
-e CASSANDRA_SEEDS=172.17.13.151  -e CASSANDRA_BROADCAST_ADDRESS=cassandra-service-2

le conteneur échoue avec l'exception d'exécution qu'il ne peut pas bavarder avec la graine :

java.lang.RuntimeException: Unable to gossip with any seeds
        at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1322)
        at org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:457)

2) D'un autre côté, si je crée un conteneur cassandra via docker run -d , je peux atteindre le nœud de départ via son adresse IP hôte :

$ docker run -d cassandra:2.0
d87a79cc3de8cd7e4cf40284d1eca91ceb660581cc71082fe64a6b84a09fbd77
$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                         NAMES
d87a79cc3de8        cassandra:2.0       "/docker-entrypoin..."   3 seconds ago       Up 2 seconds        7000-7001/tcp, 7199/tcp, 9042/tcp, 9160/tcp   trusting_ardinghelli
$ docker exec -it d87a79cc3de8 bash
root<strong i="17">@d87a79cc3de8</strong>:/# cqlsh 172.17.13.151
Connected to Test Cluster at 172.17.13.151:9160.
[cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh>

Spécifiquement pour Cassandra, vous résolvez ce problème en désactivant le démarrage automatique des nœuds Cassandra. Pour ce faire, définissez auto_bootstrap sur false dans /etc/cassandra/cassandra.yaml à l'aide d'une commande de point d'entrée dans Compose V3 :

version: '3'
services:
  cassandra-1:
    image: cassandra:2.0
    entrypoint:
    - "sh"
    - "-c"
    - "echo auto_bootstrap: false >> /etc/cassandra/cassandra.yaml; /docker-entrypoint.sh cassandra -f"
    environment:
      CASSANDRA_BROADCAST_ADDRESS: 172.17.13.151
    volumes:
    - volume1:/var/lib/cassandra
    ports:
    - "7000:7000"
    - "7001"
    - "7199"
    - "9042:9042"
    - "9160:9160"

puis démarrez manuellement les nœuds Cassandra en exécutant docker exec -it <container id> nodetool rebuild .

Je pourrais utiliser cette fonctionnalité dans le développement, eh bien ...

@jpetazzo Nous développons des solutions PHP en équipe sur un mix de plateformes. Notre débogueur (xdebug) doit se reconnecter à l'IDE sur l'hôte. Sur Windows et Linux, cela fonctionne "prêt à l'emploi", mais sur mac, nos développeurs doivent modifier le fichier xdebug.ini pour mentionner spécifiquement leur adresse IP locale. Mais le Dockerfile est sous contrôle de source... mettez en file d'attente des conflits constants et jurez lorsque les développeurs s'affrontent pour éditer ce fichier. Oui, il existe des solutions de contournement scriptables, mais pourquoi docker pour Windows et Mac a-t-il docker.for.win.localhost et docker.for.mac.localhost ? C'est en partie utile, mais nous avons toujours besoin de scripts pour détecter sur quelle plate-forme nous nous trouvons pour configurer cela correctement. Cela semble tellement plus compliqué que cela devrait l'être. Veuillez reconsidérer cette fonctionnalité. Docker peut être une courbe d'apprentissage abrupte, mais des problèmes comme celui-ci laissent vos utilisateurs chercher avec incrédulité sur Google pendant des heures.

Vérifier la page https://docs.docker.com/docker-for-mac/networking/#use-cases-and-workarounds a aidé, en utilisant docker.for.mac.localhost a fonctionné pour nous :)

Pour le meilleur ou pour le pire, docker-compose est toujours de loin le moyen le plus simple que je connaisse pour créer un concentrateur Selenium et des nœuds de grille Firefox/Chrome sans tête pour tester un serveur Web exécuté sur une machine de développement locale ou en CI (lancement le serveur Web dans un conteneur Docker est tout simplement trop lent pour être pratique pour le développement). Ce n'est pas du tout ce à quoi Docker était destiné, mais Docker est le meilleur outil pour ce travail, et c'est la faute de Docker 😆 Sauf que le seul problème est de déterminer facilement l'adresse IP de l'hôte d'une manière qui fonctionne sur n'importe quel système d'exploitation.

@rskuipers pouvez-vous expliquer ce que vous avez fait exactement avec docker.for.mac.localhost ? J'essaie de faire des demandes depuis l'intérieur de mes conteneurs pour les résoudre sur la machine hôte. Mes conteneurs s'exécutent sur traefik, ce qui signifie que je peux y accéder via domain.docker.localhost, mais si j'essaie d'accéder à une URL qui commence par cela depuis l'intérieur de mon conteneur, cela ne résout pas.

Actuellement, ce que j'ai fait, c'est que j'ai ajouté ceci à mon docker-compose.yml , ce qui ajoute une ligne à /etc/hosts pour que le domaine se résolve bien :

extra_hosts: - "domain.docker.localhost:172.18.0.1"

L'adresse IP est l'adresse IP hôte de mon conteneur, que je peux obtenir en utilisant ip route | awk '/^default via /{print $3}' . Mais je n'aimerais pas coder cela en dur si possible ...

@jzavrl Tout ce que j'ai fait a été d'utiliser docker.for.mac.localhost pour que mes requêtes HTTP passent par un proxy exécuté sur l'hôte. Je n'utilise aucune autre couche à part docker-compose .

C'est exactement ce qui m'intéresse. Quel genre de changements avez-vous dû apporter en particulier ?

@jzavrl Aucun :P ça a juste fonctionné.

Je ne comprends pas, qu'avez-vous fait de docker.for.mac.localhost alors ?

@jzavrl J'ai utilisé cela au lieu de l'IP pour me connecter. Donc docker.for.mac. hôte local : 8888

Ahhhhhh, ça commence à avoir du sens maintenant. Je vais essayer ça alors. Bravo @rskuipers.

utilisez simplement l'adresse IP de "en0" sur votre ordinateur.

par exemple

ssh [email protected]

'192.168.1.100' peut-être du service DHCP de votre routeur.

@acuthbert , merci pour votre suggestion.
docker.for.win.localhost fonctionne pour moi dans Docker pour Windows. Il y a encore de l'espoir pour Docker et Windows. 😣

il y a peu de raisons techniques pour lesquelles cela ne peut pas être fait et satisfaire les 90% des personnes sur ce fil, les cas de coin et les situations où cela ne fonctionne pas vraiment, les personnes qui se développent dans cette situation pourraient être satisfaites d'un ensemble simple de "cas d'utilisation" qui expliquent quels scénarios sont susceptibles de ne pas fonctionner.

Il s'agit principalement de déchets politiques et non d'un véritable raisonnement technique ici. J'espère que l'un des autres moteurs de conteneurs fonctionnera et que je pourrai échanger kubernetes pour l'utiliser à la place. Alors je n'aurai plus à m'occuper de ces déchets.

@NdubisiOnuora , quel type de candidature ? application Web?

J'ai 2 applications console (tcp-server dans l'hôte et tcp-client dans le conteneur).
Parce qu'ils utilisent tcp, j'ai besoin exactement d'IP ( docker.for.win.localhost ne convient pas, car c'est un domaine).

Par exemple, quel ip:port je dois définir dans tcp-client, si je définis ip:port 127.0.0.1:9595 dans tcp-server ?

Résolvez simplement le domaine en une adresse IP ?

@orf ,
Je veux utiliser ce code en C #:
IPAddress hostAddr = Dns.Resolve("docker.for.win.localhost").AddressList[0];
Mais avant cela, j'essaie d'envoyer un ping à docker.for.win.localhost , mais je ne vois pas ça, erreur : Ping request could not find host docker.for.win.localhost. Please check the name and try again.
Mon Dockerfile :
FROM microsoft/windowsservercore
ADD . /
ENTRYPOINT powershell ping docker.for.win.localhost

Au cas où quelqu'un l'aurait manqué, je pense que la solution à partir du 18.03 est host.docker.internal bien que pour une raison quelconque, cela ne fonctionne que sur Docker pour Windows !? Pourquoi pas les autres ?

EDIT : Je n'ai pas vu que les commentaires ont été réduits par Github... 🤦‍♂️

Travaille pour moi:
docker run --rm -it --add-host "docker.for.localhost:$(ip -4 addr show docker0 | grep -Po 'inet \K[\d.]+')" alpine:latest ping docker.for.localhost

@lukasmrtvy Cela fonctionne pour un shell, mais qu'en est-il pour docker-compose.yml ?

J'ai créé un conteneur pour résoudre ce problème de manière générique en travaillant sur toutes les plateformes https://github.com/qoomon/docker-host