Quand j’ai commencé à travailler avec Docker en formation BTS SIO, la partie réseau m’a semblé abstraite. On lance des conteneurs, ils communiquent entre eux, et tout fonctionne. Jusqu’au jour où un conteneur ne parvient plus à joindre la base de données, où un port entre en conflit, ou encore où l’on doit faire communiquer des services répartis sur plusieurs machines. C’est à ce moment-là que comprendre le docker networking devient indispensable.

Dans ce guide, je vous propose de décortiquer le fonctionnement réseau de Docker, driver par driver, avec des exemples concrets et des commandes que vous pourrez reproduire immédiatement. Que vous prépariez votre formation Docker ou que vous configuriez une infrastructure de production, ce guide couvre l’ensemble des concepts à maîtriser.

Comprendre le fonctionnement du réseau Docker

Docker repose sur les fonctionnalités réseau du noyau Linux pour isoler les conteneurs et leur permettre de communiquer. Chaque conteneur dispose de sa propre pile réseau : interface virtuelle, table de routage et espace de noms réseau (network namespace). Cette isolation garantit qu’un conteneur ne peut pas interférer directement avec le réseau d’un autre conteneur ou de l’hôte, sauf configuration explicite.

Concrètement, quand vous lancez un conteneur Docker, le moteur crée une paire d’interfaces réseau virtuelles (veth pair). L’une est placée dans le namespace du conteneur, l’autre est rattachée à un pont réseau virtuel (bridge) sur la machine hôte. Ce mécanisme est identique à celui utilisé par les hyperviseurs de virtualisation, mais avec une empreinte beaucoup plus légère.

Le modèle réseau de Docker s’appuie sur le concept de Container Network Model (CNM), qui définit trois composants principaux :

• Sandbox : l’espace réseau isolé du conteneur, contenant ses interfaces et sa configuration
• Endpoint : le point de connexion entre la sandbox et le réseau, comparable à une carte réseau virtuelle
• Network : le réseau virtuel qui regroupe un ensemble d’endpoints et permet leur communication

Ce modèle est implémenté par la bibliothèque libnetwork, qui fournit l’abstraction nécessaire pour que différents drivers réseau puissent coexister. Si vous venez du monde réseau traditionnel, pensez aux VLANs : chaque réseau Docker agit comme un segment réseau isolé, et vous choisissez quels conteneurs y participent.

Les cinq drivers réseau natifs de Docker

Docker propose cinq drivers réseau intégrés. Chacun répond à un besoin spécifique, et le choix du bon driver conditionne directement les performances, la sécurité et la scalabilité de votre architecture. Voici un aperçu comparatif avant de détailler chacun d’eux.

Comme vous le constatez, il n’existe pas de driver universel. En formation, je recommande toujours à mes étudiants de commencer par bridge pour les développements locaux, puis de passer à overlay dès que l’architecture devient distribuée. Pour approfondir la comparaison entre les approches réseau dans Compose, consultez mon article sur les configurations réseau Docker Compose.

Réseau bridge : le mode par défaut

Le driver bridge est le mode réseau par défaut de Docker. Quand vous lancez un conteneur sans spécifier de réseau, il est automatiquement rattaché au bridge par défaut nommé docker0. Ce pont virtuel agit comme un switch réseau logiciel : tous les conteneurs qui y sont connectés peuvent communiquer entre eux via leurs adresses IP.

Cependant, il existe une différence majeure entre le bridge par défaut et un bridge personnalisé. Le bridge par défaut ne fournit pas de résolution DNS automatique. Vous devez utiliser les adresses IP directement ou recourir aux liens legacy (--link), une fonctionnalité dépréciée. En revanche, un bridge personnalisé offre un serveur DNS embarqué qui permet de résoudre les noms des conteneurs.

Voici comment créer et utiliser un réseau bridge personnalisé :

# Créer un réseau bridge personnalisé
docker network create --driver bridge mon-reseau

# Lancer deux conteneurs sur ce réseau
docker run -d --name api --network mon-reseau nginx
docker run -d --name base-donnees --network mon-reseau postgres:16

# Depuis le conteneur api, on peut joindre la base par son nom
docker exec api ping base-donnees

Dans cet exemple, le conteneur api peut résoudre le nom base-donnees directement grâce au DNS intégré. C’est cette fonctionnalité qui rend les bridges personnalisés indispensables pour tout projet sérieux. D’autres avantages importants du bridge personnalisé incluent :

• Isolation renforcée : seuls les conteneurs explicitement connectés au réseau peuvent communiquer
• Connexion et déconnexion à chaud : vous pouvez rattacher ou détacher un conteneur sans le redémarrer
• Configuration fine : sous-réseau, passerelle et options IP personnalisables

# Créer un bridge avec un sous-réseau spécifique
docker network create \
  --driver bridge \
  --subnet 172.20.0.0/16 \
  --gateway 172.20.0.1 \
  --ip-range 172.20.240.0/20 \
  reseau-personnalise

Si vous travaillez sur un projet Docker Compose, sachez que Compose crée automatiquement un bridge personnalisé pour chaque projet. C’est l’une des raisons pour lesquelles vos services communiquent si facilement dans un fichier docker-compose.yml.

Driver host, overlay et macvlan

Le driver host

Avec le driver host, le conteneur partage directement la pile réseau de la machine hôte. Il n’y a aucune isolation réseau : le conteneur utilise l’adresse IP de l’hôte et ses ports. Cette approche élimine la couche de NAT (Network Address Translation) et offre les meilleures performances réseau possibles.

# Lancer un conteneur en mode host
docker run -d --network host nginx

Attention : en mode host, si le port 80 est déjà utilisé sur l’hôte, le conteneur ne pourra pas démarrer. Ce mode est réservé aux situations où la performance réseau est critique, comme les outils de monitoring. Pour installer Grafana avec Docker par exemple, le mode host peut être pertinent pour éviter la latence supplémentaire du NAT.

Le driver overlay

Le driver overlay est conçu pour les architectures multi-hôtes. Il crée un réseau virtuel qui s’étend sur plusieurs nœuds Docker Swarm, permettant à des conteneurs déployés sur des machines physiques différentes de communiquer comme s’ils étaient sur le même réseau local. Le driver utilise le protocole VXLAN pour encapsuler le trafic réseau dans des paquets UDP.

# Initialiser Docker Swarm
docker swarm init

# Créer un réseau overlay
docker network create --driver overlay --attachable reseau-overlay

# Déployer un service sur ce réseau
docker service create --name web --network reseau-overlay --replicas 3 nginx

L’option --attachable permet à des conteneurs autonomes (non gérés par Swarm) de rejoindre le réseau overlay. C’est utile pour le débogage ou pour des conteneurs de migration. La résolution DNS fonctionne automatiquement sur les réseaux overlay, avec un load balancing intégré pour les services répliqués.

Le driver macvlan

Le driver macvlan attribue une adresse MAC unique à chaque conteneur, le faisant apparaître comme un équipement physique distinct sur le réseau. Les conteneurs reçoivent une adresse IP du même sous-réseau que l’hôte et sont directement accessibles depuis le réseau physique, sans NAT ni mapping de ports.

# Créer un réseau macvlan
docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  reseau-macvlan

Ce driver est particulièrement adapté aux applications legacy qui nécessitent une adresse IP fixe sur le réseau local, ou aux situations où les conteneurs doivent être traités comme des serveurs physiques par le reste de l’infrastructure. En revanche, il requiert que la carte réseau de l’hôte soit configurée en mode promiscuous, ce qui n’est pas toujours possible sur les hébergeurs cloud.

Gestion DNS et découverte de services

La résolution DNS est l’un des aspects les plus pratiques du docker networking. Sur les réseaux personnalisés (bridge ou overlay), Docker embarque un serveur DNS interne accessible à l’adresse 127.0.0.11. Ce serveur permet à chaque conteneur de résoudre les noms des autres conteneurs connectés au même réseau.

Concrètement, quand vous nommez un conteneur avec --name mon-service, ce nom devient un enregistrement DNS résolvable par tous les conteneurs du même réseau. Dans Docker Compose, le nom du service défini dans le fichier YAML sert directement de nom DNS. Pour en savoir plus sur ce mécanisme, consultez mon guide sur Docker Compose net et les différences réseau.

# docker-compose.yml
services:
  api:
    image: node:20
    networks:
      - backend
    # L'API peut joindre la base à l'adresse "db:5432"

  db:
    image: postgres:16
    networks:
      - backend

networks:
  backend:
    driver: bridge

Dans cet exemple, le service api peut se connecter à PostgreSQL simplement en utilisant db comme nom d’hôte. Le DNS Docker résout automatiquement ce nom vers l’adresse IP du conteneur de base de données. Cette fonctionnalité élimine le besoin de coder en dur des adresses IP, ce qui rend vos configurations portables et reproductibles.

Pour les architectures Swarm avec des services répliqués, le DNS Docker offre également un load balancing automatique. Quand un service possède plusieurs réplicas, la résolution DNS retourne l’adresse IP virtuelle (VIP) du service, et Docker distribue les requêtes entre les réplicas via un mécanisme d’IPVS (IP Virtual Server).

Vous pouvez personnaliser le comportement DNS de vos conteneurs avec ces options :

docker run -d \
  --dns 8.8.8.8 \
  --dns-search exemple.local \
  --hostname mon-conteneur \
  nginx

Docker Compose et configuration réseau

Docker Compose simplifie considérablement la gestion réseau en créant automatiquement un réseau dédié pour chaque projet. Par défaut, tous les services d’un fichier docker-compose.yml sont connectés au même réseau bridge et peuvent communiquer entre eux via leur nom de service. Le nom du réseau est construit à partir du nom du répertoire du projet suivi de _default.

Pour des architectures plus complexes, vous pouvez définir plusieurs réseaux et contrôler précisément quels services peuvent communiquer :

# docker-compose.yml avec réseaux multiples
services:
  proxy:
    image: nginx
    networks:
      - frontend
      - backend
    ports:
      - "80:80"

  api:
    image: node:20
    networks:
      - backend

  db:
    image: postgres:16
    networks:
      - backend
    volumes:
      - pgdata:/var/lib/postgresql/data

  monitoring:
    image: grafana/grafana
    networks:
      - frontend

networks:
  frontend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.28.0.0/16
  backend:
    driver: bridge
    internal: true

volumes:
  pgdata:

Dans cette configuration, le réseau backend est marqué comme internal, ce qui signifie qu’aucun conteneur connecté à ce réseau ne peut accéder à Internet. Seul le proxy, connecté aux deux réseaux, peut relayer les requêtes vers l’API et la base de données. Le service monitoring peut accéder au proxy via le réseau frontend, mais ne peut pas joindre directement la base de données. Cette segmentation est une bonne pratique de sécurité fondamentale.

Vous pouvez aussi rattacher vos services à un réseau externe, déjà existant avant le lancement de Compose :

networks:
  reseau-existant:
    external: true
    name: mon-reseau-partage

Cette approche est utile pour faire communiquer plusieurs projets Compose entre eux. Pour approfondir ces configurations, je vous recommande mon article dédié aux 5 configurations réseau Docker Compose à maîtriser.

Iptables et sécurité réseau Docker

Docker manipule directement les règles iptables de la machine hôte pour gérer le routage, le NAT et l’isolation des conteneurs. Quand vous exposez un port avec -p 8080:80, Docker crée automatiquement des règles iptables qui redirigent le trafic entrant sur le port 8080 de l’hôte vers le port 80 du conteneur. C’est un point crucial à comprendre, car ces règles contournent les règles de pare-feu que vous auriez configurées manuellement.

Voici les chaînes iptables principales utilisées par Docker :

• DOCKER : contient les règles de redirection de ports (DNAT) pour les conteneurs
• DOCKER-ISOLATION-STAGE-1 et STAGE-2 : assurent l’isolation entre les différents réseaux Docker
• DOCKER-USER : chaîne destinée aux règles personnalisées de l’administrateur

# Visualiser les règles iptables créées par Docker
sudo iptables -L -n -v
sudo iptables -t nat -L -n -v

# Ajouter une règle personnalisée dans la chaîne DOCKER-USER
sudo iptables -I DOCKER-USER -s 192.168.1.0/24 -j ACCEPT
sudo iptables -A DOCKER-USER -j DROP

La chaîne DOCKER-USER est évaluée avant les règles automatiques de Docker, ce qui vous permet de filtrer le trafic sans que Docker ne les écrase lors d’un redémarrage. C’est le seul endroit sûr pour ajouter vos propres règles de filtrage. Pour une sécurité renforcée de votre infrastructure, pensez également à sensibiliser vos équipes à la cybersécurité.

Un piège classique : si vous utilisez un pare-feu comme ufw sur Ubuntu, les ports Docker exposés restent accessibles même si ufw les bloque. Docker insère ses règles dans la table nat et la chaîne FORWARD, qui sont traitées avant les règles INPUT de ufw. Pour éviter ce problème, vous pouvez configurer Docker pour ne pas manipuler iptables en ajoutant "iptables": false dans le fichier /etc/docker/daemon.json. Attention : dans ce cas, vous devez gérer manuellement tout le routage réseau.

La documentation officielle Docker sur le filtrage de paquets détaille l’ensemble des interactions entre Docker et iptables. Je vous recommande vivement de la consulter avant de déployer des conteneurs exposés sur Internet.

Commandes essentielles pour gérer vos réseaux

Maîtriser les commandes réseau de Docker est indispensable pour diagnostiquer les problèmes de connectivité et gérer vos réseaux efficacement. Voici les commandes que j’utilise quotidiennement.

Pour diagnostiquer un problème de connectivité entre conteneurs, voici la procédure que je suis systématiquement :

# 1. Vérifier sur quel réseau se trouve chaque conteneur
docker inspect mon-conteneur --format '{{json .NetworkSettings.Networks}}' | python3 -m json.tool

# 2. Vérifier l'adresse IP attribuée
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' mon-conteneur

# 3. Tester la connectivité depuis un conteneur
docker exec mon-conteneur ping -c 3 autre-conteneur

# 4. Vérifier la résolution DNS
docker exec mon-conteneur nslookup autre-conteneur 127.0.0.11

# 5. Inspecter les règles iptables si nécessaire
sudo iptables -L DOCKER -n -v

Un outil que je recommande particulièrement est docker network inspect avec l’option --format. Elle permet d’extraire des informations précises en utilisant les templates Go. Si vous envisagez de migrer votre infrastructure dans le cloud, cette maîtrise des commandes réseau Docker vous sera précieuse pour le débogage à distance.

Bonnes pratiques en production

Après plusieurs années à déployer des conteneurs en production et à former des étudiants en BTS SIO, j’ai identifié un ensemble de bonnes pratiques qui évitent les problèmes les plus courants. Le guide réseau officiel de Docker constitue la référence à garder sous la main.

1. Toujours utiliser des réseaux personnalisés. Ne comptez jamais sur le bridge par défaut. Créez systématiquement des réseaux dédiés pour bénéficier de la résolution DNS, de l’isolation et de la possibilité de connecter ou déconnecter des conteneurs à chaud.

2. Segmenter par responsabilité. Séparez vos réseaux frontend et backend. Les conteneurs de base de données n’ont aucune raison d’être accessibles depuis le réseau qui expose vos services au monde extérieur. Utilisez l’option internal: true pour les réseaux qui ne doivent pas accéder à Internet.

3. Ne pas exposer de ports inutilement. Chaque port exposé avec -p crée une règle iptables qui ouvre ce port à tout le réseau. Privilégiez la communication interne entre conteneurs via le réseau Docker, et n’exposez que les points d’entrée strictement nécessaires, comme le reverse proxy.

4. Limiter la bande passante si nécessaire. En production, un conteneur qui génère un pic de trafic peut saturer la bande passante de l’hôte. Utilisez les options --network-alias pour créer des alias DNS et faciliter le basculement entre instances.

5. Surveiller le nombre de réseaux. Chaque réseau bridge consomme des ressources noyau (interfaces virtuelles, règles iptables, entrées de table de routage). Sur un hôte chargé, nettoyez régulièrement les réseaux inutilisés avec docker network prune.

6. Documenter votre topologie réseau. Un schéma clair de vos réseaux Docker, des conteneurs qui y sont connectés et des ports exposés facilite considérablement le dépannage. Intégrez cette documentation dans votre processus de versionnement Docker.

Pour les déploiements multi-hôtes, évaluez soigneusement si Docker Swarm avec les réseaux overlay suffit à vos besoins, ou si une solution d’orchestration comme Kubernetes avec son propre modèle réseau (CNI) serait plus adaptée. Si vous hésitez entre différents moteurs de conteneurisation, mon comparatif Podman vs Docker vous aidera à faire le bon choix.

Lucie Moreau

Formatrice IT indépendante depuis 2016, ancienne étudiante BTS SIO SLAM. 6 ans d'expérience en entreprise.