Date de création : 2025/11/23 00:06

Docker est une plateforme de virtualisation légère basée sur les conteneurs. Son objectif principal est de permettre d'embarquer une application, ses dépendances, sa configuration et son environnement dans un paquet isolé, reproductible et portable : le conteneur.

Docker résout les problèmes majeurs rencontrés dans les environnements de développement et de production :

• « Chez moi ça marche, chez toi non »
• Conflits de versions entre bibliothèques
• Déploiements manuels longs et risqués
• Différences entre serveurs (OS, configurations, dépendances)

Docker garantit que le même code fonctionne exactement de la même manière partout.

• 2013 : Docker, Inc. publie la première version open-source.
• Docker popularise l’usage des namespaces et cgroups du noyau Linux.
• 2014–2020 : adoption massive et industrialisation DevOps.
• Aujourd’hui : Docker est le standard mondial de la conteneurisation.

Un modèle immuable contenant l’environnement complet nécessaire à une application.

Une instance vivante d’une image, équivalente à un processus isolé.

Le moteur responsable des images, conteneurs, réseaux et volumes.

Dépôt d’images (Docker Hub, GitHub Container Registry…).

• Portabilité totale
• Performances élevées
• Isolation forte
• Standardisation
• Déploiement rapide
• Scalabilité microservices
• Réduction des coûts

Schéma :

      MACHINE VIRTUELLE                          CONTENEUR

+—————————+ +——————————–+

+—————————+ +——————————–+

+—————————+ +——————————–+

+—————————+ +——————————–+

+—————————+ +——————————–+

+—————————+ +——————————–+

brew install –cask docker

sudo apt update sudo apt install docker.io -y sudo systemctl enable –now docker

Installation via Docker Desktop Windows (WSL2 requis).

docker version docker run hello-world

docker run -d -p 8080:80 –name monnginx nginx

Tester sur : http://localhost:8080

docker stop docker start docker rm docker logs docker exec

Schéma : docker run → création → exécution → arrêt → suppression

Tester installation avec hello-world.

Lancer Nginx et afficher la page depuis navigateur.

Explorer un conteneur via : docker exec -it <id> sh

• Docker = conteneurisation légère
• Un conteneur = une instance isolée
• Une image = un template immuable
• Avantages : portabilité, rapidité, simplicité
• Nginx permet un premier test concret

Comprendre en profondeur le fonctionnement interne de Docker :

• Docker CLI
• Docker Daemon (dockerd)
• Images & layers
• Conteneurs & file systems copy-on-write
• Cgroups & Namespaces
• Storage drivers (overlay2…)
• Registries
• Interaction complète entre les composants

Ce module développe chaque concept avec des schémas, explications détaillées et exercices pratiques.

Schéma conceptuel :

[ Docker CLI ] → (API HTTP) → [ Docker Daemon ]

                        ↓
                 [ Images / Layers ]
                        ↓
                  [ Containers ]
                        ↓
                 [ Registries ]

Docker est construit autour d’une architecture client/serveur.

L’outil en ligne de commande utilisé par l’utilisateur :

• docker run
• docker build
• docker ps
• docker logs
• docker network …

Il ne fait que transmettre des commandes au daemon via une API REST.

Le cœur de Docker. Il gère :

• création et exécution de conteneurs
• téléchargement et construction d’images
• gestion des réseaux
• volumes
• sécurité
• stockage

Tout passe par le daemon.

Une image est un ensemble de couches immuables (layers). Chaque instruction Dockerfile produit une nouvelle couche.

Structure :

• Layer 5 — CMD / ENTRYPOINT
• Layer 4 — Code source
• Layer 3 — Dépendances
• Layer 2 — Paquets système supplémentaires
• Layer 1 — Base OS (alpine, debian, python:slim…)

• immuable
• versionnable
• portable
• optimisée via un cache

Commande pour voir les layers :

docker history nginx

Docker utilise un mécanisme CoW (copy-on-write).

Schéma :

IMAGE (read-only)

 ▲ layers immuables
 |

CONTAINER (read-write)

Lorsqu’un fichier est modifié dans le conteneur :

1. Docker copie le fichier dans la couche RW du conteneur.
2. La modification s'applique uniquement au conteneur.

Cela rend les conteneurs légers et rapides.

Un conteneur est :

• une instance d’une image
• un processus isolé
• un système de fichiers minimal
• un ensemble d’espaces d’exécution indépendants

Cycle de vie :

docker create docker start docker stop docker restart docker kill docker rm

Commande pour inspecter un conteneur :

docker inspect mon_container

Les namespaces fournissent l’isolation au niveau du noyau. Chaque conteneur a son propre ensemble de namespaces.

• PID — processus
• NET — réseau
• MNT — systèmes de fichiers
• IPC — communications inter-processus
• UTS — hostname
• USER — utilisateurs
• CGROUP — ressources

Schéma :

[ Host OS ] ├─ Namespace A → Container 1 ├─ Namespace B → Container 2 └─ Namespace C → Container 3

Les cgroups limitent les ressources :

• CPU
• RAM
• I/O disque
• Réseau

Exemples :

docker run –memory=“512m” nginx docker run –cpus=“1.5” nginx

On peut donc isoler les ressources de chaque conteneur.

Les drivers gèrent le système de fichiers interne des conteneurs.

• overlay2 (recommandé)
• aufs (ancien)
• btrfs
• zfs

docker info | grep Storage

Sous Linux (Ubuntu), Docker utilise overlay2.

Les registres stockent les images Docker.

• Docker Hub (public)
• GitHub Container Registry
• GitLab Registry
• Azure Container Registry
• Registres privés auto-hébergés

docker pull nginx docker push johnben/monimage:1.0 docker login

docker run nginx
  ↓
Docker CLI → API HTTP UNIX socket → Docker Daemon
  ↓
Daemon vérifie si l’image existe
  ↓
Image présente ? sinon → téléchargement
  ↓
Création du conteneur (RW layer)
  ↓
Lancement du processus principal (ENTRYPOINT/CMD)

Sous Linux :

journalctl -u docker

Sous macOS : Docker Desktop → menu → Troubleshoot → logs

1. Télécharger nginx :

docker pull nginx

2. Inspecter ses layers :

docker history nginx

3. Inspecter l’image :

docker inspect nginx

1. Lancer nginx :

docker run -d --name test-nginx nginx

2. Inspecter le conteneur :

docker inspect test-nginx

3. Analyser :

• GraphDriver (overlay2)
• NetworkSettings
• HostConfig (cgroups)

Depuis le conteneur :

docker exec -it test-nginx sh

Tester :

ps aux
hostname

• Docker CLI = interface utilisateur
• Docker Daemon = moteur principal
• Images = layers immuables
• Conteneurs = instances isolées
• Namespaces = isolation
• Cgroups = contrôle des ressources
• Overlay2 = système de fichiers CoW moderne
• Registries = stockage des images
• docker inspect = commande la plus puissante pour tout comprendre

Comprendre en profondeur :

• la structure interne d’une image Docker
• les layers et le mécanisme de cache
• les bonnes pratiques modernes d’écriture d’un Dockerfile
• l’optimisation (taille, sécurité, vitesse)
• les multi-stage builds
• les commandes avancées d’inspection d’image
• les erreurs courantes
• un atelier pratique complet

Ce module est fondamental pour produire des images professionnelles, propres et performantes.

Une image est un ensemble immuable de couches (layers) représentant :

• un OS minimal
• des paquets système
• des outils nécessaires
• le code de votre application
• les configurations finales (CMD/ENTRYPOINT)

Schéma structurel :

• Layer 6 — CMD / ENTRYPOINT
• Layer 5 — Application
• Layer 4 — Dépendances applicatives
• Layer 3 — Dépendances système
• Layer 2 — Config système
• Layer 1 — OS minimal (alpine, debian-slim…)

Les images sont read-only, les conteneurs ajoutent une couche RW.

Chaque instruction Dockerfile crée une couche :

• FROM = nouvelle base
• RUN = nouvelle couche
• COPY = nouvelle couche
• ADD = nouvelle couche
• ENV = met à jour les métadonnées
• CMD/ENTRYPOINT = pas une couche de fichiers, mais une couche de configuration

Commande :

• docker history <image>

Analyse typique :

• IMAGE CREATED BY SIZE
• <id> CMD [“npm” “start”] 0B
• <id> COPY . . 34kB
• <id> RUN npm ci 55MB
• <id> COPY package*.json . 1kB
• <id> FROM node:20-alpine 7MB

Docker optimise fortement le build avec un cache basé sur les layers.

Si une instruction ne change pas, Docker réutilise le layer précédent → gain massif de temps.

Exemple :

COPY package*.json ./
RUN npm install
COPY . .

→ modifier seulement les fichiers sources n’invalide pas npm install.

• mettre COPY package.json AVANT COPY .
• grouper les RUN quand ils sont liés
• éviter ADD (inefficace)
• ne jamais copier tout le répertoire avant installation des dépendances

Structure générale recommandée 2025 :

FROM ...
WORKDIR ...
COPY ... ...
RUN ...
COPY ... ...
EXPOSE ...
USER ...
ENTRYPOINT ...
CMD ...

Définit l’image de base. Exemples :

FROM node:20-alpine FROM python:3.12-slim FROM ubuntu:22.04

Meilleures pratiques :

• toujours utiliser une base slim ou alpine
• éviter ubuntu/debian pour les petits services
• versionner TOUTES les images (pas de latest)

Définit le répertoire de travail.

WORKDIR /app

Avantages :

• évite les chemins relatifs
• plus propre et lisible

Copie des fichiers dans l’image.

COPY . . COPY src/ /app/src/ COPY package*.json ./

Points importants :

• l’ordre des COPY influence le cache
• COPY est plus sûr que ADD

Exécute des commandes lors du build.

RUN apt update && apt install -y curl

Bonnes pratiques :

• utiliser && pour réduire le nombre de layers
• nettoyer les caches apt
• ne pas mettre plusieurs RUN inutiles

Définit une variable d’environnement dans l’image.

ENV NODE_ENV=production

Commande utilisée par défaut si aucune autre n’est fournie.

CMD [“npm”, “start”]

Commande forcée, non écrasable.

ENTRYPOINT [“python”] CMD [“app.py”]

Exécution : → python app.py

Objectif :

• réduire drastiquement la taille de l’image finale
• éliminer les dépendances nécessaires uniquement au build

Exemple Node.js :

FROM node:20-alpine AS build WORKDIR /app COPY package*.json ./ RUN npm ci –only=production COPY . .

FROM node:20-alpine AS runtime WORKDIR /app COPY –from=build /app . CMD [“node”, “server.js”]

Avantages :

• sécurité accrue
• rapidité
• image finale très légère

Bonnes pratiques 2025 :

• ne jamais exécuter en root :

RUN adduser -D appuser

  USER appuser
  
* limiter les outils installés
* scanner les images :
  
  docker scan monimage
  
* utiliser des bases officielles minimalistes (alpine, slim, distroless)

• utiliser alpine (musl)
• utiliser slim (glibc)
• multi-stage
• nettoyer les caches :

RUN rm -rf /var/lib/apt/lists/*

• structurer le Dockerfile autour du cache
• éviter COPY . trop tôt

docker inspect monimage

docker history monimage

docker run --rm -it monimage sh

• oublier .dockerignore → image énorme
• mettre COPY . . avant COPY package.json
• utiliser latest → builds non reproductibles
• RUN multiple non optimisés
• permissions root dangereuses
• images trop grosses → déploiements lents

Exemple de .dockerignore recommandé :

node_modules
.git
.gitignore
Dockerfile
docker-compose.yml
dist
.env

Étapes :

mkdir docker-app cd docker-app

print(“Hello Johnny, Docker fonctionne en version ultra !”)

FROM python:3.12-slim WORKDIR /app COPY . . CMD [“python”, “app.py”]

docker build -t monpython:1.0 .

docker run monpython:1.0

Hello Johnny, Docker fonctionne en version ultra !

• Les images sont immuables et organisées en layers
• Le cache Docker améliore massivement la vitesse de build
• Le Dockerfile est le cœur de la création d’images
• Multi-stage builds = standard moderne 2025
• Optimisation = sécurité + rapidité + légèreté
• docker history / docker inspect = outils essentiels
• .dockerignore impératif

Le module 3 est crucial pour produire des images propres, rapides, petites et adaptées à la production.

Ce module couvre en profondeur :

• le cycle de vie complet d’un conteneur
• les commandes essentielles et avancées
• la gestion des processus internes
• l’inspection, le debugging et le monitoring
• la gestion des logs
• la connexion interactive (shell)
• le mapping des ports et des systèmes de fichiers
• les redémarrages et les politiques de restart
• les erreurs courantes
• les exercices pratiques professionnels

Un conteneur est une instance vivante d’une image Docker. Il représente :

• un processus isolé
• possédant son propre système de fichiers (layer RW)
• son propre espace réseau (namespace)
• ses propres ressources (cgroups)
• ses propres variables d’environnement

Schéma :

IMAGE (read-only layers)

      │
      ▼

CONTAINER (read-write layer)

      │
      ▼

Processus principal (ENTRYPOINT/CMD)

Un conteneur vit tant que SON PROCESSUS PRINCIPAL est en vie.

• docker create → crée un conteneur (pas lancé)
• docker start → démarre un conteneur arrêté
• docker run → create + start
• docker stop → arrêt propre (SIGTERM → SIGKILL)
• docker kill → arrêt brutal (SIGKILL immédiat)
• docker restart → stop + start
• docker pause → suspend les processus
• docker unpause → reprise
• docker rm → supprime un conteneur
• docker rm -f → supprime même s’il tourne

Commandes de base :

• docker run nginx
• docker stop nginx
• docker rm nginx

Les états visibles via :

docker ps -a

États courants :

• Up : en cours d’exécution
• Exited (0) : terminé normalement
• Exited (1) : erreur
• Created : créé mais pas démarré
• Paused : suspendu
• Restarting : en boucle de redémarrage

docker run -d nginx

docker run –name web nginx

Mapping :

-p HOST:CONTAINER

Exemple :

docker run -d -p 8080:80 nginx

→ http://localhost:8080

docker run -e APP_ENV=prod monapp

docker run -it ubuntu bash

docker run -v /host/data:/container/data nginx

Docker peut redémarrer automatiquement un conteneur.

  --restart=no           (par défaut)
  --restart=on-failure   (si process error)
  --restart=always       (toujours)
  --restart=unless-stopped

Exemple :

docker run --restart=always myservice

Très utilisé en production hors orchestrateur.

docker inspect moncontainer

Parties importantes :

• HostConfig → cgroups, volumes, ports
• NetworkSettings → IP du conteneur
• GraphDriver → overlay2
• Config.Env → variables

docker inspect -f 'networksettings.ipaddress' moncontainer

docker logs moncontainer docker logs -f moncontainer

Options utiles :

• -f → suivre en temps réel
• –tail 100 → n'affiche que 100 lignes

docker exec -it moncontainer bash

ou si bash n’existe pas :

docker exec -it moncontainer sh

docker exec moncontainer ls -la

Chaque conteneur n’a qu’un seul processus principal.

Vérifier :

docker top moncontainer

Dans un OS classique :

ps aux

docker stop envoie :

1. SIGTERM (arrêt propre)
2. après 10 secondes → SIGKILL (forcé)

Changer le délai :

docker stop --time=3 moncontainer

Schéma :

HOST : 8080 → CONTAINER : 80

Commande :

docker run -p 8080:80 nginx

Lister les ports :

docker port moncontainer

Le conteneur a son propre système :

docker exec -it moncontainer sh ls -la

Pour copier un fichier :

docker cp fichier.txt moncontainer:/tmp/ docker cp moncontainer:/etc/nginx/nginx.conf .

docker rm id docker rm -f id docker container prune docker system prune

• container keeps restarting

→ mauvais CMD / erreur au démarrage

  
  docker logs
  

• ports already in use

→ le port hôte est occupé

• cannot exec: container not running

→ conteneur arrêté, vérifier avec docker ps -a

• permission denied

→ volumes ou fichiers hôte non accessibles

docker run -d -p 8080:80 –name demo-nginx nginx

docker exec -it demo-nginx sh

docker logs -f demo-nginx

docker cp demo-nginx:/etc/nginx/nginx.conf .

docker restart demo-nginx

docker rm -f demo-nginx

• Un conteneur est une instance isolée et vivante d’une image
• Commande clé : docker run (create + start)
• docker exec permet d’entrer dans un conteneur
• docker logs pour diagnostiquer
• Les ports, volumes et variables sont essentiels
• docker inspect révèle tout le fonctionnement interne
• Les restart policies sont fondamentales pour la production
• Les erreurs courantes sont faciles à corriger avec les bonnes commandes

Ce module donne toutes les bases nécessaires pour maîtriser les conteneurs de manière professionnelle.

Ce module ultra complet couvre :

• la persistance des données dans Docker
• les différents types de volumes
• les bind mounts vs volumes Docker
• le fonctionnement interne du stockage
• la gestion des permissions
• les bonnes pratiques 2025
• les commandes avancées : inspect, prune, backup
• un atelier complet avec exercices + CORRIGÉS

Ce module est essentiel pour les bases de données, les CMS (WordPress), les APIs persistant des données, etc.

Par défaut, un conteneur Docker :

• possède son propre système de fichiers isolé
• qu’il PERD entièrement si le conteneur est supprimé

Donc sans volume :

• une base MySQL perd tout
• un WordPress perd ses uploads
• une API perd ses fichiers

Il faut donc des volumes persistants.

Création :

docker volume create data-mysql

Utilisation :

docker run -d -v data-mysql:/var/lib/mysql mysql:8

Lister :

docker volume ls

Inspecter :

docker volume inspect data-mysql

Avantages :

• totalement géré par Docker
• portable
• indépendant de l'hôte
• parfait pour MySQL, PostgreSQL, MongoDB, Redis

Syntaxe :

-v /chemin/hote:/chemin/conteneur

Exemple :

docker run -d -v /home/johnny/site:/var/www/html php:8.2-apache

Avantages :

• idéal en développement
• permet d’éditer les fichiers en temps réel

Inconvénients :

• dépend du système hôte
• moins portable

Sous Linux :

/var/lib/docker/volumes/

Sous macOS et Windows (Docker Desktop) : Stockés dans un disque virtuel interne.

Depuis un conteneur temporaire :

docker run –rm -it -v data-mysql:/data alpine sh

Puis dans le conteneur :

ls -la /data

Dans un volume, les permissions dépendent du conteneur, pas de l’hôte (sauf bind mount).

Corriger une permission avec alpine :

docker run –rm -v data:/data alpine chown -R 1000:1000 /data

Création d’une archive :

docker run –rm -v data-mysql:/source -v /backup:/backup alpine tar czvf /backup/mysql.tar.gz /source

Restauration :

docker run –rm -v data-mysql:/dest -v /backup:/backup alpine tar xzvf /backup/mysql.tar.gz -C /dest –strip 1

Supprimer un volume spécifique :

docker volume rm data-mysql

Supprimer les volumes inutilisés :

docker volume prune

• toujours nommer ses volumes
• utiliser bind mounts uniquement en dev
• ne jamais stocker des données dans le conteneur
• éviter les chemins relatifs
• pour bases SQL → toujours volume dédié
• versionner le dossier backup, pas le volume

Objectif :

• lancer MySQL
• vérifier la persistance
• supprimer le conteneur
• vérifier que les données existent encore

Commandes à exécuter :

docker volume create mysql-data docker run -d –name mydb -e MYSQL_ROOT_PASSWORD=1234 -v mysql-data:/var/lib/mysql mysql:8

Ajouter une table :

docker exec -it mydb mysql -u root -p1234 -e “CREATE DATABASE test;” docker exec -it mydb mysql -u root -p1234 -e “USE test; CREATE TABLE demo(id INT);”

Supprimer le conteneur :

docker rm -f mydb

Vérification :

docker run –rm -it -v mysql-data:/data alpine ls -la /data

→ les fichiers .ibd et .frm sont présents → la base est bien persistée

Création bind mount :

mkdir ~/monapp echo “hello” > ~/monapp/test.txt

docker run –rm -it -v ~/monapp:/data alpine sh

Dans alpine :

cat /data/test.txt

MODIFIER depuis le conteneur :

echo “modifié” > /data/test.txt

Quitter, puis vérifier côté hôte :

cat ~/monapp/test.txt

→ Le fichier local a été modifié → preuve que bind mount = partage natif

Créer un volume :

docker volume create testdata

Ajouter des fichiers :

docker run –rm -v testdata:/data alpine sh -c “echo 'Johnny' > /data/name.txt”

Sauver :

mkdir ~/backup docker run –rm -v testdata:/source -v ~/backup:/backup alpine tar czvf /backup/archive.tar.gz /source

Fichier créé :

ls -la ~/backup/archive.tar.gz

→ archive présente → backup réussi

• Docker perd les données sans volume
• Volumes nommés = standard pour la production
• Bind mounts = parfaits pour le développement
• Les volumes sont indépendants du cycle de vie des conteneurs
• docker inspect permet de comprendre la structure
• Savoir faire un backup / restore est indispensable
• Ce module est clé pour tout service nécessitant des données (SQL, NoSQL, uploads, logs)

Ce module ultra complet couvre :

• le fonctionnement réseau interne de Docker
• les types de réseaux Docker (bridge, host, none)
• les réseaux personnalisés
• la résolution DNS interne entre conteneurs
• l’isolation réseau et les namespaces
• les ports, NAT et iptables
• les drivers réseau avancés (overlay, macvlan)
• Docker Compose et les réseaux
• les outils de diagnostic réseau
• les exercices pratiques AVEC réponses

Ce module est essentiel pour comprendre comment les conteneurs communiquent.

Lorsqu’un conteneur Docker est lancé, Docker lui attribue :

• une interface réseau virtuelle
• une adresse IP interne
• un namespace réseau isolé
• un accès éventuel au réseau hôte selon configuration

Schéma général :

[Host Network]

    │

[Docker Engine]

    │

[Bridge Network] — Conteneurs isolés + IP internes

Chaque conteneur vit dans un namespace réseau isolé.

Le réseau *bridge* est créé automatiquement :

docker network ls

On y voit :

bridge host none

IP par défaut :

172.17.0.0/16

Lorsqu’un conteneur démarre :

docker run -d nginx

Il reçoit une IP locale :

172.17.0.2

Le mapping :

-p 8080:80

Signifie :

HÔTE port 8080 → CONTENEUR port 80

Docker configure automatiquement :

• NAT (iptables MASQUERADE)
• Forward de ports
• Routage interne

docker network inspect bridge

docker inspect moncontainer

Sections importantes :

• IPAddress
• Networks
• MacAddress
• Gateway

Créer :

docker network create monreseau

Lancer deux conteneurs :

docker run -d –name web –network monreseau nginx docker run -d –name api –network monreseau alpine sleep 9999

Tester la communication :

docker exec -it api ping web

Résultat attendu :

PING web (172.x.x.x): 56 data bytes

Docker crée automatiquement un DNS interne.

Créer un alias :

docker run -d –network monreseau –network-alias backend nginx

Tester :

docker exec -it api ping backend

docker run –network host nginx

Le conteneur :

• partage l’interface réseau du host
• n’a pas de NAT
• expose directement ses ports

Avantage → perf maximale Inconvénient → aucune isolation

docker run –network none alpine

Résultat :

• aucun accès réseau
• seulement `lo`

Idéal pour :

• batch sécurisés
• environnements isolés

Macvlan permet d’attribuer une vraie adresse MAC.

Exemple de création :

docker network create -d macvlan –subnet=192.168.1.0/24 –gateway=192.168.1.1 -o parent=eth0 pubnet

Les conteneurs apparaissent comme des machines réelles sur le LAN.

Utilisé pour Swarm ou Kubernetes.

Permet à des conteneurs :

• situés sur plusieurs serveurs physiques
• d’être sur un même réseau virtuel

Exemple :

version: “3.9” services:

web:
  image: nginx
  networks:
    - backend

api:
  image: alpine
  command: sleep 9999
  networks:
    - backend

networks:

backend:
  driver: bridge

Test DNS :

docker compose exec api ping web

docker exec -it conteneur nslookup web

docker run –rm -it –net=host nicolaka/netshoot

Netshoot contient :

• tcpdump
• dig
• nslookup
• ip route
• netstat

Commandes :

docker run -d –name test-nginx nginx docker inspect -f 'networksettings.ipaddress' test-nginx

RÉPONSE ATTENDUE : → Une IP interne `172.17.x.x`

Création réseau :

docker network create reseau-test

Lancement conteneurs :

docker run -d –name c1 –network reseau-test alpine sleep 9999 docker run -d –name c2 –network reseau-test alpine sleep 9999

Ping :

docker exec -it c1 ping -c 2 c2

RÉPONSE ATTENDUE : → Ping OK grâce au DNS Docker

docker run –network none alpine ip a

RÉPONSE ATTENDUE : → Seule interface disponible : `lo`

• Docker utilise un réseau bridge NAT par défaut
• Chaque conteneur reçoit une IP interne
• Docker inclut un DNS interne très puissant
• Le mapping de ports passe par iptables NAT
• host = réseau partagé
• none = aucun réseau
• macvlan = conteneur visible sur LAN
• overlay = multi-nœuds
• docker network inspect = outil clé

Ce module permet de maîtriser tous les aspects réseau indispensables en production.

Ce module ultra complet couvre :

• le fonctionnement de Docker Compose
• la syntaxe complète du fichier docker-compose.yml
• les services, réseaux, volumes et dépendances
• la gestion du scaling (réplication de services)
• l'override, les profils, les variables d'environnement
• les commandes avancées
• un atelier complet avec exercices + réponses corrigées
• exemples professionnels utilisés en production

Docker Compose est l’outil indispensable pour gérer des environnements multi-conteneurs.

Docker Compose permet de :

• définir plusieurs services dans un fichier unique
• lancer toute une stack en une seule commande
• gérer réseaux, volumes, dépendances automatiquement
• simplifier les environnements de dev, test et staging

Commande principale :

docker compose up -d

Structure générale :

version: “3.9” services:

service1:
  ...
service2:
  ...

networks:

...

volumes:

...

Les sections principales :

• services
• networks
• volumes
• configs (avancé)
• secrets (avancé)

Exemple :

services:

web:
  image: nginx
  ports:
    - "8080:80"

Options courantes :

• image
• build
• ports
• environment
• volumes
• depends_on
• restart
• command
• networks

services:

api:
  build: .
  ports:
    - "3000:3000"

Compose exécutera automatiquement :

docker build .

environment:

1. APP_ENV=prod
2. DB_HOST=mysql

Fichier `.env` :

APP_ENV=prod PORT=8080

Compose :

ports:

1. “${PORT}:80”

Exemple :

services:

db:
  image: mysql
  volumes:
    - dbdata:/var/lib/mysql

volumes:

dbdata:

Permet la persistance automatique.

Définir un réseau :

networks:

backend:
  driver: bridge

Assigner un service :

services:

api:
  image: myapi
  networks:
    - backend

Par défaut, Compose crée un réseau :

<dossier>_default

services:

web:
  depends_on:
    - db

IMPORTANT : depends_on ne garantit PAS que db soit prêt, seulement qu'il démarre avant.

Pour vérifier la santé :

healthcheck:

test: ["CMD", "curl", "-f", "http://localhost"]
interval: 5s
timeout: 3s
retries: 5

services:

app:
  image: node
  command: ["npm", "start"]

Override ENTRYPOINT :

entrypoint: [“python3”] command: [“app.py”]

restart: always restart: on-failure restart: unless-stopped

docker compose up -d –scale web=3

Limites :

• fonctionne uniquement si le service n’a pas de ports mappés fixes

Exemple correct :

ports:

1. “80”

(= port dynamique)

docker compose up -d docker compose down docker compose ps docker compose logs -f docker compose exec <service> <commande> docker compose restart docker compose up -d –build

version: “3.9” services:

web:
  image: nginx
  ports:
    - "8080:80"
  volumes:
    - ./nginx.conf:/etc/nginx/nginx.conf
  depends_on:
    - php

php:
  image: php:8.2-fpm
  volumes:
    - ./app:/var/www/html

db:
  image: mysql:8
  environment:
    MYSQL_ROOT_PASSWORD: root
  volumes:
    - dbdata:/var/lib/mysql

volumes:

dbdata:

version: “3.9” services:

api:
  build: ./api
  ports:
    - "3000:3000"
  depends_on:
    - redis

redis:
  image: redis:7
  command: ["redis-server", "--appendonly", "yes"]
  volumes:
    - redisdata:/data

volumes:

redisdata:

docker-compose.yml :

version: “3.9” services:

web:
  image: nginx
  ports:
    - "8080:80"

Commande :

docker compose up -d

RÉPONSE : http://localhost:8080 affiche Nginx.

docker-compose.yml :

services:

c1:
  image: alpine
  command: sleep 9999

c2:
  image: alpine
  command: sleep 9999

Test :

docker compose exec c1 ping -c 2 c2

RÉPONSE : Le ping fonctionne grâce au DNS interne Docker.

docker-compose.yml :

version: “3.9” services:

db:
  image: mysql:8
  environment:
    MYSQL_ROOT_PASSWORD: 1234
  volumes:
    - mysqldata:/var/lib/mysql

volumes:

mysqldata:

Test :

docker compose exec db mysql -uroot -p1234 -e “CREATE DATABASE testdb;” docker compose down docker compose up -d docker compose exec db mysql -uroot -p1234 -e “SHOW DATABASES;”

RÉPONSE : La base testdb apparaît → la persistance fonctionne.

• Docker Compose orchestre plusieurs services dans un seul fichier
• sections principales : services, volumes, networks
• depend_on aide à orchestrer le démarrage
• persistence gérée via volumes
• réseaux automatiques + DNS interne
• scaling possible avec –scale
• docker compose up / down / logs / exec sont les commandes essentielles

Ce module est indispensable pour déployer des stacks multi-services (WordPress, Laravel, Django, Node.js, Next.js…).

Ce module ultra complet couvre :

• les risques liés aux conteneurs Docker
• les meilleures pratiques de sécurité 2025
• la configuration des utilisateurs non-root
• la signature et le scanning d’images
• les capabilities Linux
• seccomp, AppArmor & SELinux
• la gestion des secrets
• la sécurité réseau
• la sécurité des images et des registres
• exercises complets AVEC réponses

Ce module est essentiel pour un usage professionnel de Docker.

Docker apporte une isolation, mais pas une sécurité absolue.

Risques courants :

• conteneur exécuté en root → très dangereux
• mauvaise isolation réseau
• images non fiables
• secrets stockés dans les fichiers
• volumes mal configurés
• ports exposés inutilement

Objectif : Protéger l’hôte, les conteneurs et les données.

Le conteneur tourne par défaut en root, ce qui permettrait :

• d'écrire partout dans les volumes
• d’accéder à des fichiers sensibles
• d’échapper potentiellement au conteneur

Solution recommandée : Créer un utilisateur interne.

Exemple dans Dockerfile :

RUN adduser -D appuser USER appuser

Pour vérifier :

docker exec -it monapp id

Docker retire la majorité des capabilities, mais certaines restent.

Lister les capabilities disponibles :

docker run –rm alpine capsh –print

Désactiver TOUTES les capabilities :

docker run –cap-drop=ALL myapp

N’en autoriser qu’une :

docker run –cap-drop=ALL –cap-add=NET_ADMIN myapp

Seccomp = sandbox de syscalls Linux.

Voir le profil par défaut :

/usr/share/docker/seccomp.json

Exécuter un conteneur sans seccomp :

docker run –security-opt seccomp=unconfined myapp

→ DÉCONSEILLÉ en production.

Voir profils :

aa-status

Activer un profil :

docker run –security-opt apparmor=monprofil myapp

Mode permissif :

setenforce 0

Mode enforcing :

setenforce 1

Label SELinux pour Docker :

docker run -v data:/data:Z myapp

Docker propose un scan natif :

docker scan monimage

Sortie :

• CVE détectées
• Niveau de sévérité
• Packages vulnérables
• Correctifs recommandés

Autre outil : Trivy

docker run aquasec/trivy image monimage

Activer la confiance :

export DOCKER_CONTENT_TRUST=1

Signer une image :

docker trust sign monrepo/monimage:1.0

Valider une signature :

docker trust inspect monrepo/monimage

Bonnes pratiques 2025 :

• utiliser images officielles (docker.io/library/)
• préférer alpine, slim ou distroless
• éviter latest
• limiter les packages installés
• utiliser multi-stage builds
• supprimer les outils sensibles :

RUN apk del curl git build-base

docker run –pids-limit 100 myapp

docker run –memory=512m myapp

docker run –cpus=“1.0” myapp

docker run –read-only myapp

docker run –security-opt no-new-privileges myapp

—- Réduire la surface d'exposition —-

• éviter d'exposer tous les ports
• privilégier des réseaux internes
• utiliser un reverse proxy (Traefik, Nginx Proxy Manager)

—- Exemple : Nginx accessible seulement via backend —-

networks:

backend:
public:

services:

nginx:
  networks:
    - public
    - backend
api:
  networks:
    - backend

—- Firewall interne —-

docker run –cap-add NET_ADMIN alpine iptables -L

Ne jamais mettre les secrets dans :

• Dockerfile
• docker-compose.yml
• .env versionné

secrets:

db_pass:
  file: ./db_pass.txt

services:

db:
  secrets:
    - db_pass

Dans le conteneur :

/run/secrets/db_pass

Authentification :

docker login registry.example.com

Limiter le push :

docker push registry.example.com/secure/image:1.0

Registry privé sécurisé :

• HTTPS obligatoire
• tokens d’accès
• scanning automatique CI/CD

Objectif : Créer un conteneur avec un utilisateur non-root.

Solution :

docker run -it –user 1000:1000 alpine id

RÉPONSE : Le conteneur affiche :

uid=1000 gid=1000

Commandes :

docker run –cap-drop=ALL alpine sh -c “ping 8.8.8.8”

RÉSULTAT ATTENDU :

ping: socket: Operation not permitted

→ NORMAL : capability supprimée.

docker scan nginx

RÉSULTAT ATTENDU : Liste de CVE + niveaux critique/haut/moyen.

docker run –read-only -it alpine touch /test

RÉPONSE ATTENDUE :

touch: /test: Read-only file system

• Ne jamais exécuter en root
• Limiter les capabilities Linux
• Utiliser seccomp, AppArmor, SELinux
• Scanner les images (Docker Scan, Trivy)
• Utiliser des bases minimales (alpine, slim, distroless)
• Sécuriser l’accès réseau et les secrets
• Protéger les registres privés
• Limiter ressources CPU / RAM / PIDs
• Activer rootless si possible
• Réduire la surface d’attaque au strict minimum

Ce module est indispensable pour un déploiement professionnel sécurisé.

Ce module ultra complet couvre :

• les outils essentiels pour gérer, surveiller et optimiser Docker
• les interfaces graphiques (Portainer, DockStation…)
• le monitoring réseau & système (Netshoot, cAdvisor…)
• les reverse-proxy modernes (Traefik, Nginx Proxy Manager)
• les outils de mise à jour (Watchtower)
• les environnements de développement optimisés
• les outils de build & analyse
• EXERCICES COMPLETS + réponses

C’est le module le plus pratique pour travailler comme un professionnel.

Portainer permet :

• de visualiser les conteneurs
• de voir logs, stats, CPU/RAM
• de gérer réseaux, volumes, stacks
• de déployer Docker Compose depuis UI
• de gérer un cluster Swarm

Installation :

docker volume create portainer_data docker run -d -p 9443:9443 –name portainer –restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

Accès :

https://localhost:9443

Permet :

• HTTPS avec Let’s Encrypt en un clic
• gestion multi-sites
• redirections
• proxy vers conteneurs

Compose complet :

version: “3.9” services:

npm:
  image: jc21/nginx-proxy-manager:latest
  ports:
    - "80:80"
    - "81:81"
    - "443:443"
  volumes:
    - npm-data:/data
    - npm-letsencrypt:/etc/letsencrypt

volumes:

npm-data:
npm-letsencrypt:

Traefik permet :

• proxy dynamique
• SSL automatique
• dashboards
• labels Docker
• load balancing

Exemple service avec labels :

services:

api:
  image: myapi
  labels:
    - "traefik.enable=true"
    - "traefik.http.routers.api.rule=Host(`api.example.com`)"

docker run -d –name watchtower -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower

Fonctions :

• vérifie les images mises à jour
• redéploie automatiquement
• idéal pour les serveurs auto-hébergés

docker run –rm -it nicolaka/netshoot

Inclut :

• curl
• dig
• tcpdump
• nslookup
• mtr
• netstat
• iperf

Ex : résolution DNS interne →

dig web

docker run -d -p 8080:8080 –name cadvisor –volume=/:/rootfs:ro –volume=/var/run:/var/run:ro –volume=/sys:/sys:ro –volume=/var/lib/docker/:/var/lib/docker:ro gcr.io/cadvisor/cadvisor

Interface :

http://localhost:8080

Fonctions :

• gestion projets multi-conteneurs
• interface visuelle intuitive
• logs en temps réel
• gestion Docker Compose

docker run –rm -it wagoodman/dive:latest <image>

Dive analyse :

• les layers
• la taille de chaque layer
• les fichiers dupliqués
• optimisation possible

Installation :

curl https://raw.githubusercontent.com/jesseduffield/lazydocker/master/scripts/install_update_linux.sh | bash

Interface :

lazydocker

Fonctions :

• vue conteneurs
• vue logs CPU/RAM
• vue réseau
• gestion volumes
• restart/stop en temps réel

docker buildx create –use docker buildx build –platform linux/arm64,linux/amd64 -t image:latest .

Pratique pour :

• Raspberry Pi
• clusters ARM
• images cross-platform

stern “api-*”

Similaire à :

docker compose logs -f

Mais avec filtrage avancé.

Commandes :

docker volume create portainer_data docker run -d -p 9443:9443 –name portainer -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

RÉPONSE : Accès → https://localhost:9443

Commandes :

docker run -d –name web nginx docker run -d –name api –network bridge alpine sleep 9999 docker exec -it api apk add bind-tools docker exec -it api dig web

RÉSULTAT ATTENDU : web.docker resolve vers → 172.17.x.x

Commande :

docker run –rm -it wagoodman/dive:latest nginx

RÉSULTAT ATTENDU :

• layers listés
• taille optimisée
• suggestions de réduction

Commande :

docker run -d –name watchtower -v /var/run/docker.sock:/var/run/docker.sock containrrr/watchtower –interval 30

RÉPONSE ATTENDUE : Watchtower surveille les images toutes les 30 secondes.

• Portainer = meilleure interface graphique
• Nginx Proxy Manager = HTTPS facile
• Traefik = reverse proxy moderne en production
• Watchtower = mise à jour automatique
• Netshoot = diagnostic réseau ultime
• cAdvisor = monitoring CPU/RAM/I/O
• Dive = analyse taille images
• LazyDocker = gestion terminal avancée
• Buildx = builds multi-architectures

Ce module fournit l’ensemble des outils nécessaires à une gestion pro et simplifiée de Docker.

Ce module ultra complet couvre :

• les bonnes pratiques professionnelles pour déployer Docker en production
• l’optimisation des images, conteneurs et réseaux
• la supervision, la gestion des logs et des ressources
• les stratégies de mise à jour et de rollback
• la haute disponibilité (Swarm / K8s introduction)
• la CI/CD avec Docker
• la sécurité renforcée
• les patterns de déploiement modernes
• exercices complets + réponses corrigées

Ce module est la conclusion professionnelle de toute la formation.

Une stack Docker prête pour la production doit respecter :

• images légères (alpine/slim/distroless)
• utilisateurs non-root
• ressources limitées (CPU/RAM/PIDs)
• logs externes (ELK / Loki / Splunk)
• reverse proxy sécurisé (Traefik / NPM)
• monitoring complet (cAdvisor, Prometheus, Grafana)
• backups automatiques (volumes)
• stratégie de mises à jour maîtrisée

Le mot d’ordre : minimalisme + sécurité + observabilité.

Images recommandées :

• alpine
• debian-slim
• python:slim
• node:alpine
• distroless

Éviter :

• latest
• ubuntu “full”
• images non officielles

Bonne pratique :

FROM node:20-alpine RUN adduser -D appuser USER appuser

docker run –cpus=“1.0” myapp

docker run –memory=“512m” myapp

docker run –pids-limit=100 myapp

docker run –read-only myapp

Ne jamais stocker les logs DANS le conteneur.

Solutions recommandées :

• Loki (Grafana)
• ELK Stack
• Promtail
• Splunk

Logging driver :

docker run –log-driver json-file myapp

Outils essentiels :

• cAdvisor — CPU, RAM, IO
• Prometheus — métriques
• Grafana — dashboards
• Netshoot — diagnostic réseau

Exemple cAdvisor :

docker run -d -p 8080:8080 gcr.io/cadvisor/cadvisor

Traefik :

• SSL automatique
• autodiscovery Docker
• redirections
• load balancing

Exemple labels :

labels:

1. “traefik.enable=true”
2. “traefik.http.routers.web.rule=Host(`site.com`)”
3. “traefik.http.routers.web.tls.certresolver=myresolver”

Déployer progressif → réduire risques.

2 versions en parallèle → switch instantané.

Un petit pourcentage du trafic teste la nouvelle version.

Toujours sauvegarder :

• volumes SQL
• configurations
• certificats SSL
• images privées

Backup modèle :

docker run –rm -v data:/source -v /backup:/backup alpine tar czvf /backup/data.tar.gz /source

Pipeline GitHub Actions :

name: Deploy on: push jobs:

build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v3
    - run: docker build -t myapp .
    - run: docker login -u $USER -p $PASS
    - run: docker push myapp

Pipeline complet :

• build
• tests
• scanning sécurité
• push registry
• déploiement automatique

docker swarm init docker service create –replicas 3 nginx

Fonctions :

• load balancing natif
• scaling automatique
• secrets sécurisés
• rollback intégré

Kubernetes permet :

• orchestration avancée
• autoscaling
• stratégies de déploiement sophistiquées
• stockage dynamique
• observabilité complète

Idéal pour :

• les infrastructures complexes
• les microservices
• la haute disponibilité

Checklist :

• utilisateur non-root
• seccomp actif
• pas de capabilities inutiles
• no-new-privileges activé
• réseaux internes privés
• pas de secrets dans Dockerfile

Exemple :

docker run –security-opt no-new-privileges –cap-drop=ALL myapp

Séparer les réseaux :

• public (reverse proxy)
• backend (API)
• database (privé)

Exemple Compose :

networks:

public:
internal:

services:

web:
  networks:
    - public
    - internal
db:
  networks:
    - internal

Commande :

docker run –cpus=“0.5” –memory=“256m” nginx

RÉPONSE : Le conteneur ne peut utiliser que :

• 50% d’un CPU
• 256 Mo RAM

docker scan nginx

RÉPONSE : La liste des CVE s’affiche → corrigées avant mise en prod.

docker run –read-only -it alpine touch /test

RÉSULTAT ATTENDU :

touch: /test: Read-only file system

• Production = sécurité, optimisation, monitoring, CI/CD
• Ne jamais exécuter en root
• Utiliser images optimisées
• Limiter ressources des conteneurs
• Utiliser reverse proxies professionnels
• Logging & monitoring externes obligatoires
• CI/CD avec scanning sécurité intégré
• Swarm & Kubernetes pour haute disponibilité

Ce module final clôture toute la formation en vous donnant les standards industriels actuels.

Page dans la catégorie: