Relier les conteneurs en réseau · Docker sur Windows ou Ubuntu

Une application réelle tient rarement dans un seul conteneur : un site et sa base de données, un service et son cache… Ces conteneurs doivent se parler. Mais se parler entre eux ne veut pas dire être joignables par tout le monde.

Pourquoi créer son propre réseau

Docker range tout conteneur lancé sans précision dans un réseau par défaut. Il a un défaut majeur : les conteneurs ne s’y trouvent que par leur adresse IP, qui change d’un redémarrage à l’autre. Sur un réseau que vous créez, Docker résout les noms : c’est lui qu’il faut utiliser dès que deux conteneurs doivent communiquer.

Dans le réseau, on se trouve par son nom. Dehors, rien n’entre tant qu’aucun port n’est publié.

Exercice : deux conteneurs qui se parlent

Créez le réseau, puis lancez Nginx dedans. Remarquez l’absence de -p : on ne publie aucun port.

docker network create owlnet-net
docker run -d --name web-backend --network owlnet-net nginx:alpine

Lancez maintenant un client jetable sur le même réseau, et demandez-lui la page de web-backend, par son nom :

docker run --rm --network owlnet-net alpine wget -qO- http://web-backend

Le code HTML de la page d’accueil de Nginx s’affiche : le client a trouvé le serveur par son nom, et Nginx lui a répondu.

La contre-épreuve est tout aussi instructive. Même commande, sans --network :

docker run --rm alpine wget -qO- http://web-backend

Réponse : bad address 'web-backend'. Ce client est resté sur le réseau par défaut : il ne voit pas owlnet-net, et personne ne lui a appris ce nom.

Observer

docker network inspect owlnet-net
docker ps

La rubrique Containers de la première commande liste web-backend et son adresse IP interne. Dans docker ps, la colonne PORTS affiche 80/tcp, sans flèche : le port existe dans le conteneur, mais n’est relié à rien à l’extérieur. Essayez d’ailleurs de l’ouvrir dans le navigateur : il n’y a aucune adresse à taper.

Publier ou non : une décision par service

Écriture	Qui peut joindre le service	Pour quoi
Pas de `-p`	Les conteneurs du même réseau, et eux seuls	Une base de données, un cache, un service interne
`-p 127.0.0.1:8083:80`	En plus, votre ordinateur	Un outil personnel, une interface d’administration
`-p 8083:80`	En plus, tous les appareils du réseau local	Un service que d’autres doivent vraiment utiliser

Partez toujours de la première ligne, et ne descendez que si vous avez une raison. Chaque ligne ajoutée ouvre une porte de plus.

Quand un port est publié pour tout le réseau, Windows peut vous demander d’autoriser Docker dans son pare-feu. Ne l’acceptez pas par réflexe : demandez-vous d’abord si un autre appareil a réellement besoin de ce service.

Rappel de l’épisode 2 : un port publié par Docker passe devant les règles d’UFW. La troisième ligne du tableau rend le service joignable depuis le réseau, même si UFW semble tout bloquer.

Nettoyer

Dans l’ordre : d’abord le conteneur, ensuite le réseau, qui refuse de partir tant qu’un conteneur y est branché.

docker rm -f web-backend
docker network rm owlnet-net

Ne supprimez jamais un réseau que vous n’avez pas identifié : d’autres projets, comme ceux de Compose à l’épisode suivant, créent les leurs.

Testez-vous

3 questions pour vérifier que l’essentiel est acquis. Rien n’est noté ni enregistré.

Sur un réseau créé avec docker network create, comment un conteneur en joint-il un autre ?

Votre base de données ne sert qu’à votre application, sur le même réseau Docker. Faut-il publier son port ?

Que change -p 8080:80 par rapport à -p 127.0.0.1:8080:80 ?

Vérifier que tout fonctionne

Cochez au fur et à mesure : quand tout est coché, vous pouvez passer à la suite.

Le conteneur client obtient la page de web-backend en l’appelant par son nom

Le même appel, hors du réseau, échoue avec « bad address »

docker ps montre web-backend sans aucun port publié

Le réseau owlnet-net est supprimé à la fin de l’exercice

Problèmes courants

« bad address 'web-backend' »

Le conteneur qui appelle n’est pas sur le même réseau que web-backend : il manque --network owlnet-net à sa commande. Sur le réseau par défaut de Docker, les noms ne sont de toute façon pas résolus.

« network owlnet-net not found »

Le réseau n’existe pas encore, ou son nom est mal orthographié. docker network ls liste ceux qui existent ; créez-le avec docker network create owlnet-net.

Docker refuse de supprimer le réseau (« active endpoints »)

Des conteneurs y sont encore branchés. Supprimez d’abord web-backend, puis le réseau. docker network inspect owlnet-net montre qui est encore connecté.

Ubuntu : UFW bloque tout, et pourtant mon port publié répond depuis le réseau

Docker écrit ses propres règles de pare-feu, qui passent avant celles d’UFW. Un port publié sans 127.0.0.1 est joignable depuis le réseau, quoi que dise UFW. Publiez sur 127.0.0.1, ou ne publiez pas.