Par défaut, Docker crée plusieurs réseaux : `bridge` (par défaut), `host`, `none`. Les conteneurs sur le même réseau bridge peuvent communiquer entre eux par leur adresse IP, mais pas par leur nom (sauf sur les réseaux personnalisés). La communication externe se fait via le NAT. Les réseaux personnalisés (user-defined bridge) offrent la résolution DNS automatique (nom du service → conteneur). ISOSET forme à la conception de réseaux Docker pour des applications microservices.

• bridge (par défaut) – réseau privé, NAT vers l’extérieur, pas de résolution DNS automatique entre conteneurs.
• host – le conteneur utilise directement la pile réseau de l’hôte (pas d’isolation).
• none – aucun réseau (loopback uniquement).
• overlay – pour les clusters multi‑hôtes (Docker Swarm, Kubernetes).
• macvlan / ipvlan – assigne une adresse MAC/IP directement sur le réseau physique.

Les réseaux bridge personnalisés offrent la résolution DNS : les conteneurs peuvent se joindre par leur nom (ou alias) sans utiliser l’IP. Ils sont recommandés pour la plupart des applications multi‑conteneurs.

# Créer un réseau bridge personnalisé
docker network create mon-reseau
# Lancer deux conteneurs sur ce réseau
docker run -d --name api --network mon-reseau mon-image-api
docker run -d --name nginx --network mon-reseau -p 80:80 nginx
# L’API est accessible depuis nginx via http://api:port

Les conteneurs attachés à un réseau personnalisé peuvent aussi être exposés sur plusieurs ports à l’extérieur via `-p`. ISOSET utilise ces réseaux dans ses ateliers de microservices.

Pour une architecture distribuée sur plusieurs serveurs, le driver `overlay` crée un réseau virtuel qui s’étend sur tous les nœuds du cluster. Docker Swarm et Kubernetes utilisent ce mécanisme pour permettre aux conteneurs de communiquer indépendamment de l’hôte physique.

# Créer un réseau overlay dans Swarm
docker network create -d overlay mon-overlay
docker service create --network mon-overlay --name api mon-image

• host – utile pour les applications nécessitant des performances réseau extrêmes (pas de NAT, pas de virtualisation réseau). Moins sécurisé.
• macvlan – assigne une adresse MAC distincte au conteneur, le faisant apparaître comme un périphérique physique sur le réseau. Idéal pour les applications legacy ou la surveillance de réseau.

Les conteneurs sont éphémères : toute donnée écrite dans la couche du conteneur disparaît à sa suppression. Les volumes permettent de persister des données au‑delà du cycle de vie du conteneur, de partager des fichiers entre conteneurs, ou de monter des répertoires de l’hôte.

• Volumes nommés – gérés par Docker, stockés dans `/var/lib/docker/volumes/`. Recommandés en production.
• Bind mounts – montent un répertoire ou fichier de l’hôte dans le conteneur. Pratique pour le développement (code source).
• tmpfs mounts – données en mémoire (non persistantes), idéal pour les secrets temporaires.

# Créer et utiliser un volume nommé
docker volume create pgdata
docker run -d --name postgres -v pgdata:/var/lib/postgresql/data postgres:15
# Lister les volumes
docker volume ls
# Inspecter un volume
docker volume inspect pgdata

Les volumes nommés peuvent être utilisés par plusieurs conteneurs simultanément. Docker gère leur création, leur sauvegarde et leur suppression. ISOSET enseigne les bonnes pratiques de gestion des volumes en production.

Les bind mounts lient un répertoire (ou fichier) de l’hôte à un chemin dans le conteneur. Toute modification est reflétée en temps réel. C’est idéal pour le développement : on modifie le code localement, les changements apparaissent immédiatement dans le conteneur (avec un outil de hot‑reload).

# Bind mount pour le développement
docker run -d -p 3000:3000 -v "$(pwd)":/app -v /app/node_modules node:18 npm run dev

⚠️ Attention : les bind mounts dépendent du système de fichiers de l’hôte ; ils sont moins portables que les volumes nommés. ISOSET forme à distinguer bind mounts (dev) et volumes nommés (prod).

Les volumes contiennent des données critiques (bases de données, fichiers uploadés). On peut les sauvegarder en utilisant un conteneur temporaire qui lit le volume et compresse son contenu vers l’hôte.

# Sauvegarde d’un volume nommé pgdata
docker run --rm -v pgdata:/source -v $(pwd):/backup alpine tar czf /backup/pgdata-backup.tar.gz -C /source .
# Restauration
docker run --rm -v pgdata:/target -v $(pwd):/backup alpine tar xzf /backup/pgdata-backup.tar.gz -C /target

Les volumes peuvent aussi être sauvegardés via des drivers tiers (Restic, Velero) ou directement copiés depuis `/var/lib/docker/volumes/`. ISOSET propose des ateliers de sauvegarde automatisée.

Pour des environnements multi‑hôtes ou du stockage clé en main, des pilotes permettent de monter des volumes depuis le cloud (AWS EBS, Azure Disk) ou des solutions partagées (NFS, Ceph, GlusterFS).

• Rex‑Ray – pilote pour AWS EBS, EFS, S3, etc.
• NFS volume plugin – monter un partage NFS.
• Cloudstare – pilote Docker pour les clouds (déprécié, préférer CSI).

# Créer un volume avec pilot Rex‑Ray sur EBS
docker volume create --driver rexray/ebs --name mon-vol-ebs

• Isoler les environnements – créer un réseau par stack d’application (web, db, cache).
• Nommer explicitement les réseaux – éviter le réseau bridge par défaut.
• Préférer les volumes nommés aux bind mounts en production.
• Ne pas stocker de secrets dans les volumes non chiffrés.
• Utiliser `docker volume prune` régulièrement pour supprimer les volumes orphelins.
• Documenter la configuration des réseaux et des volumes (docker-compose).

version: '3.8'
services:
  web:
    build: .
    networks:
      - frontend
    volumes:
      - ./src:/app
      - /app/node_modules
  db:
    image: postgres:15
    networks:
      - backend
    volumes:
      - pgdata:/var/lib/postgresql/data
  proxy:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      - frontend
networks:
  frontend:
  backend:
volumes:
  pgdata:

Ce fichier définit deux réseaux isolés (frontend, backend) et un volume nommé pour PostgreSQL. ISOSET fournit de nombreux exemples comme celui‑ci dans ses supports de cours.

Les témoignages d’anciens élèves d’ISOSET confirment l’impact concret de la formation : *« Je ne comprenais pas comment les conteneurs PostgreSQL persistaient leurs données. La session sur les volumes nommés et les bind mounts m’a tout éclairci. Maintenant je sauvegarde automatiquement mes volumes dans S3. »*