infra / docker
Réseaux Docker (bridge/host, notions overlay)
Explication
Ce que vous allez apprendre
- Comprendre le rôle des réseaux Docker et pourquoi le réseau bridge par défaut ne suffit pas toujours
- Créer un réseau bridge personnalisé et bénéficier de la résolution DNS automatique par nom de conteneur
- Distinguer les modes bridge, host, none et overlay et savoir quand utiliser chacun
- Connecter et déconnecter un conteneur d'un réseau, même après son lancement
- Exposer un port de façon plus sûre en limitant son accès à
127.0.0.1
Dans quel contexte ?
Une développeuse construit une application composée d'une API et d'une base PostgreSQL, chacune dans son propre conteneur, lancés séparément avec docker run. Sur le réseau bridge par défaut, son API ne parvient pas à joindre db:5432 — seule l'adresse IP interne (qui change à chaque redémarrage) fonctionnerait. En créant un réseau bridge personnalisé et en y rattachant les deux conteneurs, elle peut enfin utiliser le nom db comme adresse fixe, résolu automatiquement par le DNS interne de Docker.
Pourquoi les conteneurs ont besoin d'un réseau
Dès qu'une application est composée de plusieurs conteneurs (une API et une base de données, par exemple), ils doivent pouvoir communiquer entre eux, et parfois avec l'extérieur. Docker crée pour cela des réseaux virtuels, un peu comme si chaque groupe de conteneurs partageait son propre petit réseau local isolé du reste de la machine.
| Mode | Isolation réseau | DNS par nom | Cas d'usage |
|---|---|---|---|
| bridge (défaut) | Oui | Non | Rarement utilisé tel quel |
| bridge personnalisé | Oui | Oui | Recommandé pour la plupart des cas |
| host | Aucune | N/A | Performance maximale, cas précis |
| none | Totale | N/A | Traitement sans besoin réseau |
Piège fréquent
Exposer un port avec -p 8080:80 sans réfléchir revient parfois à l'ouvrir à toute la machine, voire au réseau local. Préciser 127.0.0.1:8080:80 restreint l'accès à la machine elle-même — un réflexe de sécurité simple pour un service qui ne doit pas être accessible depuis l'extérieur.
Le mode par défaut, et sa limite
Par défaut, tout conteneur lancé sans précision rejoint le réseau bridge. Chaque conteneur y reçoit une adresse IP privée, ce qui permet une communication technique, mais ce réseau par défaut ne fournit pas de résolution de noms : impossible de joindre un autre conteneur simplement par son nom, il faudrait connaître son IP — qui change à chaque redémarrage. C'est pour cela qu'on crée presque toujours un réseau bridge personnalisé : Docker y ajoute automatiquement un DNS interne, permettant à un conteneur nommé "db" d'être joint simplement en écrivant "db" comme adresse.
host et none : les cas extrêmes
Le mode host supprime toute isolation réseau : le conteneur utilise directement la pile réseau de la machine, sans mapping de port nécessaire, mais aussi sans la protection qu'apporte l'isolation. Le mode none, à l'opposé, retire toute interface réseau : utile pour un traitement qui n'a strictement aucun besoin réseau (traitement de fichiers en batch, par exemple), afin de réduire la surface d'attaque au minimum.
overlay, en un mot
Ces trois modes ne concernent qu'une seule machine. Le mode overlay répond à un besoin différent : faire communiquer des conteneurs situés sur des machines physiques distinctes, comme s'ils étaient sur le même réseau local, en encapsulant le trafic dans un tunnel entre les hôtes. C'est la brique réseau utilisée par les orchestrateurs multi-machines comme Docker Swarm, abordé plus loin dans le cours.
Ce qu'il faut retenir avant Docker Compose
Cette notion de réseau nommé, avec résolution DNS automatique par nom de service, sera reprise telle quelle dans Docker Compose (leçon suivante), qui crée automatiquement un réseau partagé entre tous les services déclarés dans le même fichier.
Commandes & code
Réseaux Docker
docker network ls
# NAME DRIVER SCOPE
# bridge bridge local <- réseau par défaut de tous les conteneurs
# host host local <- pas d'isolation réseau, partage la pile de l'hôte
# none null local <- aucune interface réseau
# --- bridge (défaut) : chaque conteneur reçoit une IP privée sur un réseau virtuel isolé ---
docker run -d --name api nginx # utilise le réseau "bridge" par défaut
docker inspect --format '{{.NetworkSettings.IPAddress}}' api
# Réseau bridge CUSTOM : recommandé, permet la résolution DNS automatique par nom de conteneur
docker network create mon-reseau
docker run -d --name api --network mon-reseau mon-api:1.0
docker run -d --name db --network mon-reseau postgres:16
# Depuis "api", on peut alors joindre la base simplement par son nom : "db:5432"
docker exec api ping -c2 db
# --- host : le conteneur partage directement la pile réseau de la machine hôte ---
docker run -d --network host nginx
# Pas de mapping de port nécessaire, mais pas d'isolation réseau (rarement recommandé)
# --- none : isolation totale, aucune interface réseau (hors loopback) ---
docker run -d --network none mon-batch-job
# Connecter/déconnecter un conteneur déjà lancé
docker network connect mon-reseau api
docker network disconnect mon-reseau api
# Inspecter un réseau : qui y est connecté, quel sous-réseau
docker network inspect mon-reseau
# --- overlay (notions) : réseau multi-hôtes pour Docker Swarm ---
# Permet à des conteneurs sur des MACHINES DIFFÉRENTES de communiquer comme s'ils étaient
# sur le même réseau local, via un tunnel VXLAN encapsulé entre les hôtes du cluster.
docker network create --driver overlay --attachable mon-reseau-overlay
# --attachable permet à un conteneur "docker run" classique (hors service Swarm) de le rejoindre
# Exposer un port vers l'extérieur (indispensable pour bridge/overlay, inutile pour host)
docker run -d -p 8080:80 --network mon-reseau nginx
docker run -d -p 127.0.0.1:8080:80 nginx # limite l'exposition à localhost uniquement (plus sûr)Résumé
- Le réseau bridge par défaut n'a pas de DNS interne ; un réseau bridge custom (
docker network create) l'apporte par nom de conteneur. --network hostsupprime l'isolation réseau (perf maximale, à réserver à des cas précis) ;nonel'isole totalement.overlayrelie des conteneurs entre plusieurs hôtes physiques, typiquement dans un cluster Swarm.
Exercices pratiques
Mission : réparer la communication entre une API et sa base de données
Objectif : Diagnostiquer un problème de résolution de noms entre conteneurs et sécuriser l'exposition d'un port.
Contexte
Une API et une base PostgreSQL, lancées séparément avec docker run sur le réseau bridge par défaut, ne parviennent pas à communiquer via db:5432. De plus, le port de l'API est exposé sans restriction sur toute la machine.