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: