Aller au contenu

Docker Networking

Contexte

Les containers Docker sont isolés par défaut. Pour qu'ils communiquent entre eux ou avec l'extérieur, Docker fournit plusieurs drivers réseau.

Types de réseaux

Bridge (défaut)

docker network create my-network
docker run --network my-network --name api my-api
docker run --network my-network --name db postgres
  • réseau isolé sur l'hôte
  • les containers sur le même bridge communiquent par nom
  • le réseau bridge par défaut ne supporte pas la résolution DNS — toujours créer un réseau custom

Host

docker run --network host my-api
  • le container partage directement le réseau de l'hôte
  • pas d'isolation réseau
  • utile pour les performances (pas de NAT)
  • ne fonctionne pas sur Docker Desktop (Mac/Windows)

None

docker run --network none my-api
  • aucune connectivité réseau
  • utile pour des containers de calcul isolés

Overlay

  • réseau multi-hôtes pour Docker Swarm ou Kubernetes
  • les containers sur différentes machines communiquent comme s'ils étaient sur le même réseau

Résolution DNS

Sur un réseau bridge custom, Docker fournit un DNS interne :

api → 172.18.0.2
db  → 172.18.0.3

Le container api peut accéder à la base avec jdbc:postgresql://db:5432/mydb.

Warning

Le réseau bridge par défaut (créé automatiquement) ne supporte pas la résolution DNS par nom de container. Toujours utiliser un réseau custom.

Port mapping

docker run -p 8080:8080 my-api
docker run -p 5432:5432 postgres
  • -p hostPort:containerPort expose un port du container sur l'hôte
  • sans -p, le container n'est accessible que depuis son réseau Docker

Docker Compose networking

services:
  api:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: mydb

Docker Compose crée automatiquement un réseau bridge pour tous les services du fichier. Les services communiquent par leur nom (api, db).

Communication entre containers

flowchart LR
    Client -->|:8080| API
    API -->|db:5432| DB
    API -->|redis:6379| Redis

    subgraph Docker Network
        API
        DB
        Redis
    end

Règles :

  • entre containers du même réseau : utiliser le nom du service et le port interne
  • depuis l'extérieur : utiliser le port mappé sur l'hôte
  • ne jamais hardcoder des IPs — elles changent à chaque redémarrage

Isolation et sécurité

Bonnes pratiques :

  • séparer les réseaux par responsabilité (frontend, backend, database)
  • ne pas exposer les ports des bases de données en production
  • utiliser un reverse proxy pour exposer un seul point d'entrée
networks:
  frontend:
  backend:

services:
  nginx:
    networks: [frontend, backend]
  api:
    networks: [backend]
  db:
    networks: [backend]

Le container nginx est le seul à avoir accès aux deux réseaux.

À retenir

  • toujours créer un réseau custom (pas le bridge par défaut)
  • les containers communiquent par nom DNS sur un réseau partagé
  • ne pas exposer les ports inutilement en production
  • Docker Compose gère le réseau automatiquement
  • séparer les réseaux pour l'isolation de sécurité

Voir aussi