Docker — conteneurs, images et ce qu'on peut en faire

1. C’est quoi, un conteneur ?

Un conteneur est un processus isolé, pas une machine virtuelle. Il partage le noyau du système hôte, mais vit dans son propre monde : son système de fichiers, son réseau, ses limites de ressources. Là où une VM embarque un OS complet (des Go, des minutes de démarrage), un conteneur embarque uniquement l’application et ses dépendances (des Mo, des millisecondes).

	Machine virtuelle (Vagrant)	Conteneur (Docker)
Isole	Un OS complet avec son noyau	Un processus sur le noyau de l’hôte
Poids	Go	Mo
Démarrage	Minutes	Millisecondes
Bon pour	Simuler des machines (un parc, un réseau)	Empaqueter des applications

Les deux se complètent : dans les TP, Vagrant fabrique les machines, Docker fait tourner les services dans ces machines.

L’isolation repose sur deux mécanismes du noyau Linux — les namespaces (chaque conteneur voit ses propres processus, son propre réseau, ses propres utilisateurs) et les cgroups (limites CPU/RAM). Retenez la conséquence sécurité : un conteneur n’est pas une frontière aussi solide qu’une VM — le noyau est partagé, le durcissement reste nécessaire (utilisateur non-root, capabilities réduites, image minimale).

2. Image, conteneur, registre — le vocabulaire qui suffit

Terme	C’est…	Analogie
Image	Le paquet figé : système de fichiers + métadonnées, construit en couches	La classe
Conteneur	Une instance en cours d’exécution d’une image	L’objet
Dockerfile	La recette texte qui construit l’image	Le code source de l’image
Registre	Le serveur qui stocke et distribue les images (Docker Hub, GitLab Registry)	Le dépôt de paquets

# Une application 12-factor se conteneurise en quelques lignes :
FROM node:22-alpine            # partir d'une image de base minimale
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev          # facteur II : dépendances déclarées, installées au build
COPY . .
USER node                      # durcissement : jamais root si le process n'en a pas besoin
EXPOSE 3000                    # facteur VII : l'application expose son port
CMD ["node", "server.js"]

Chaque instruction crée une couche mise en cache : ne changez que votre code, et seule la couche COPY . . se reconstruit. C’est ce qui rend les builds rapides — et c’est pour ça que l’ordre des instructions (le stable d’abord, le volatil ensuite) n’est pas cosmétique.

3. Compose — décrire plusieurs services ensemble

Une application réelle, c’est rarement un conteneur : c’est une API plus sa base plus son cache. docker-compose.yml décrit l’ensemble — services, réseaux, volumes — dans un fichier versionné, et docker compose up -d monte le tout.

services:
  api:
    build: .
    ports: ["8000:8000"]
    environment:
      DATABASE_URL: postgresql://app:app@db:5432/app   # facteur III et IV
    depends_on: [db]
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data               # l'état vit dans un volume, pas dans le conteneur
volumes:
  db-data:

Trois idées à retenir :

• Le fichier EST la documentation de l’architecture — même vertu que le Vagrantfile.
• Les services se joignent par leur nom (db:5432) : Compose crée un réseau et son DNS.
• Les conteneurs sont jetables (facteur IX), les volumes ne le sont pas : tout ce qui doit survivre à un docker compose down vit dans un volume nommé.

4. Le tour des possibilités

Usage	Ce que Docker apporte	Exemple dans la formation
Poste de dev	Le service tourne pareil chez toute la promo, sans rien installer sur l’hôte	La stack Postgres + Redis d’un TP
Environnements jetables	Monter/détruire un service en secondes pour un essai	Tester une version de Grafana sans rien casser
CI	Chaque job tourne dans une image propre et reproductible	Les runners GitLab — cf. CI/CD
Déploiement	La même image du build à la prod (facteur V)	Dokploy, GitOps
Exploitation	Logs, métriques et cycle de vie uniformes quel que soit le langage	Dockhand pour piloter tout ça

Ce que Docker ne règle pas

Docker empaquette et isole ; il ne sécurise pas à votre place. Une image obsolète embarque ses CVE, un conteneur root reste root sur le noyau partagé, un secret copié dans l’image y reste pour toujours (les couches n’oublient rien). Réflexes : images minimales et à jour, USER non-root, secrets par variables d’environnement ou fichiers montés — jamais dans le Dockerfile.

Commandes de survie

docker ps                        # ce qui tourne
docker logs -f <conteneur>       # suivre les logs
docker exec -it <conteneur> sh   # entrer dans le conteneur
docker compose up -d             # monter la stack du dossier courant
docker compose down              # la démonter (les volumes survivent)
docker system df                 # qui mange mon disque ?

Pour aller plus loin

• Stéphane Robert — guides conteneurs : Docker, durcissement, bonnes pratiques, en français et sourcé
• Xavki — playlists Docker : de la première image au Swarm
• Suite logique : CI/CD — faire construire et tester vos images à chaque push