Comment accéder à l'adresse IP interne du conteneur Docker depuis l'hôte?

Il semble que vous utilisiez le modèle de réseau bridge par défaut. Les adresses IP internes sont destinées à permettre à chaque conteneur de se parler sous le réseau bridge . Vous ne pouvez pas y accéder depuis l'hôte.

Il existe plusieurs options pour vous.

1. Vous pouvez configurer http://172.17.0.3:9000 comme point de terminaison de votre sondeur dans Jenkins.
2. Vous pouvez configurer http://172.17.0.2:8000 comme point de terminaison jenkins dans le sondeur.
3. Si vous ne souhaitez pas coder en dur au-dessus d'Ips, vos deux conteneurs peuvent communiquer avec chacun en utilisant Docker Default GatewayIp ( 172.17.0.1 ) et leur port interne . vous pouvez donc essentiellement configurer http://172.17.0.1 également.

Remarque - Modification de l'IP de la passerelle par défaut si vous définissez réseau de pont défini par l'utilisateur .

https: // docs. docker.com/v17.09/engine/userguide/networking/#the-default-bridge-network

https://docs.docker.com/network/network-tutorial- autonome /

Si vous souhaitez faire tourner les deux conteneurs à l'aide de docker-compose, vous pouvez lier les deux conteneurs en utilisant le nom du service. Suivez simplement Mise en réseau dans Compose .

Est-ce un comportement normal? Ne devrais-je pas pouvoir accéder à chaque conteneur depuis mon hôte par son adresse IP interne?

Ce que vous décrivez est un comportement normal: vous ne pouvez pas accéder directement aux adresses IP internes de Docker depuis un hôte MacOS. Voir "Par conteneur L'adressage IP n'est pas possible "dans la documentation Docker pour Mac .

Comment puis-je tester qu'un conteneur (par exemple Jenkins) peut accéder à l'autre conteneur (par exemple SonarQube) par adresse IP?

Ce n'est pas quelque chose que je "teste" normalement en soi . Démarrez les deux processus et demandez-leur d'établir leurs connexions normales (HTTP); si cela fonctionne, vous verrez les messages de journal appropriés, et si cela ne fonctionne pas, vous verrez des plaintes. (Obtenir un shell racine dans un conteneur pour envoyer des paquets ICMP d'un conteneur à un autre semble être une option populaire mais ne prouve pas grand-chose.)

Aussi: ne faites pas cette connexion en adresse IP explicite . Comme vous l'avez déjà remarqué, les adresses IP internes de Docker ne sont pas utilisables dans certains contextes et elles changeront chaque fois que vous redémarrerez les conteneurs. Au lieu de cela, Docker fournit un service DNS interne qui peut résoudre les noms d'hôte lors de la communication entre les conteneurs, mais vous devez explicitement configurer un réseau de pont autre que celui par défaut . Cette configuration ressemblerait à:

docker network create jenkinsnet
docker run --name sonarqube -d --net jenkinsnet \
  -p 9000:9000 \
  sonarqube
docker run --name jenkins -d --net jenkinsnet \
  -p 8080:8080 -p 50000:50000 \
  -e SONARQUBE_URL=http://sonarqube:9000 \
  jenkins/jenkins:latest

J'ai donc explicitement créé un réseau; commencé les deux conteneurs qui y sont connectés; et dit au conteneur client (via une variable d'environnement) où se trouve le conteneur serveur. Vous n'avez pas besoin de publier des ports avec docker run -p pour les atteindre de cette façon; que vous le fassiez ou non, utilisez le port sur lequel le processus serveur écoute (le deuxième numéro de port dans l'option docker run -p ).

Depuis l'hôte, votre seul chemin (portable et fiable) pour atteindre le conteneur passe par ses ports publiés.

La réponse acceptée ( https://stackoverflow.com/a/53992787/7730554 ) fournit déjà des options valides de ce que je préfère personnellement en utilisant docker compose.

Mais comme vous exécutez Docker sur Mac, vous pouvez également utiliser en combinaison avec le port d'hôte de transfert défini. Docker veillera donc à ce que host.docker.internal soit résolu en IP correspondante même si votre IP hôte change.