Découverte de Docker

Le problème : « ça marche sur ma machine »

Le pire ennemi du "ça marche chez moi", c'est la divergence d'environnement. Ton code passe en local, casse en CI, repasse en staging, recasse en prod. Tu perds des heures à diagnostiquer une version de Node qui change, une dépendance système absente, une variable d'environnement oubliée.

Cette divergence vient toujours des mêmes coupables : version d'un runtime, librairies installées au niveau de l'OS, configuration laissée à l'implicite, base de données absente ou en mauvaise version.

La solution : encapsuler l'environnement

L'idée est simple : empaqueter le code et son environnement (runtime, librairies, configuration) dans un artefact reproductible. Cet artefact se lance n'importe où à l'identique, sur ta machine, sur ton CI, en production.

C'est exactement ce que fait Docker. Tu décris l'environnement une fois dans un fichier texte, tu construis une image, et cette image tourne partout pareil.

VM vs conteneur

Les VMs et les conteneurs résolvent le même problème (isoler une application), mais à des coûts très différents.

• Une VM virtualise tout le matériel et embarque un OS complet (kernel + userspace). Démarrage en minutes, empreinte en Go.
• Un conteneur partage le kernel de l'OS hôte et n'embarque que l'application avec ses dépendances. Démarrage en secondes, empreinte en Mo.

Cas d'usage typiques

• Environnement de dev cohérent entre tous les membres d'une équipe
• Pipeline CI/CD reproductible : les tests tournent dans le même environnement que la prod
• Déploiement en production (microservices, edge, fonctions serverless)
• Isolation de processus : sandboxer un script non sûr, faire tourner une vieille version d'une lib

L'image

Une image est un template immuable. Elle contient l'OS minimal, le runtime (Node, Python, JVM...), ton code, les dépendances. Tu construis une image une fois, puis tu peux la lancer autant de fois que tu veux.

Métaphore utile : l'image est le moule, le conteneur est la pâtisserie. Le moule (image) ne change pas, tu peux en sortir plusieurs gâteaux (conteneurs) identiques.

Le conteneur

Un conteneur est une instance d'image en cours d'exécution. Il a son propre filesystem (en couches superposées), son réseau, ses processus. Il vit, fait son travail, meurt. Sans affecter l'image source.

Implication importante : les conteneurs sont éphémères. Si tu écris des données dans le filesystem du conteneur et que tu le supprimes, les données disparaissent. Pour persister, il faut des volumes (on verra ça au chapitre 7).

Le registry

Un registry est un dépôt centralisé d'images. Le plus connu est Docker Hub (docker.io). GitHub Container Registry (ghcr.io) est aussi très utilisé. Tu peux héberger ton propre registry privé (Harbor, Gitea, AWS ECR...).

Format complet d'un nom d'image : registry/namespace/repo:tag. Par exemple docker.io/library/postgres:16-alpine. Quand tu écris juste postgres:16-alpine, Docker complète avec Docker Hub par défaut.

Layers et cache de build

Docker construit les images en couches : chaque instruction du Dockerfile crée une layer. Ces layers sont mises en cache. Si tu re-builds sans rien changer, le build est instantané.

Docker Desktop (Mac & Windows)

Docker Desktop est l'interface tout-en-un : GUI + Docker Engine + Compose + Kubernetes optionnel. Téléchargeable sur docker.com/products/docker-desktop.

Docker Engine (Linux)

Sur Linux, on installe directement le moteur, sans GUI. Le mieux est de suivre le repo officiel pour avoir la dernière version stable, pas celle (souvent vieille) des dépôts de la distrib.

Sur Ubuntu, en une seule ligne via le script d'install officiel :

curl -fsSL https://get.docker.com | sh

Ajoute ensuite ton utilisateur·ice au groupe docker pour ne plus avoir à taper sudo à chaque commande :

sudo usermod -aG docker $USER
newgrp docker

Vérifier l'installation

docker version
docker run hello-world

Si hello-world affiche son message, tout est bon : Docker a téléchargé l'image, créé un conteneur, exécuté le programme, affiché le message, puis arrêté le conteneur.

docker run, la commande à tout faire

docker run [options] image [commande]

Les options que tu vas utiliser tous les jours :

• -d : détaché, lance en arrière-plan
• -p HÔTE:CONTENEUR : map un port (ex: -p 8080:80)
• --name NOM : nomme le conteneur (sinon Docker invente)
• -v VOLUME : monte un volume (on en parle au chapitre 7)
• -e KEY=value : passe une variable d'environnement
• --rm : supprime le conteneur quand il s'arrête
• -it : interactif + terminal (utile pour lancer un shell)

Exemple concret : lance un PostgreSQL prêt à l'emploi en une commande.

docker run -d \
  --name pg \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=secret \
  postgres:16-alpine

Tu as maintenant un PostgreSQL accessible sur localhost:5432. Pas d'install, pas de configuration système.

Lister, arrêter, supprimer

docker ps              # conteneurs en cours
docker ps -a           # tous les conteneurs, même arrêtés
docker stop pg         # arrête proprement
docker start pg        # redémarre
docker restart pg      # stop + start
docker rm pg           # supprime (le conteneur doit être arrêté)
docker rm -f pg        # force la suppression d'un conteneur qui tourne

Manipuler les images

docker images          # liste les images locales
docker pull node:22    # télécharge une image sans la lancer
docker rmi node:22     # supprime une image
docker image prune     # supprime toutes les images non utilisées

Inspecter et déboguer

docker logs pg              # affiche les logs
docker logs -f pg           # suit les logs en temps réel (Ctrl+C pour sortir)
docker exec -it pg bash     # ouvre un shell dans le conteneur
docker inspect pg           # détails complets en JSON
docker stats                # CPU/RAM en temps réel

Les instructions principales

• FROM : image de base (souvent une distribution Linux minimale avec un runtime)
• WORKDIR : répertoire de travail dans le conteneur
• COPY src dst : copie depuis l'hôte vers l'image
• RUN : exécute une commande au moment du build (install, compilation)
• ENV : variable d'environnement disponible au build et au runtime
• EXPOSE : documente un port (purement informatif, ne le publie pas)
• CMD : commande par défaut au lancement (peut être surchargée)
• ENTRYPOINT : commande qui s'exécute toujours, CMD devient ses arguments
• USER : change l'utilisateur d'exécution (par défaut root, à éviter en prod)
• HEALTHCHECK : commande de vérification de santé du conteneur

Exemple complet : application Node.js

FROM node:22-alpine

WORKDIR /app

# Layer cachée tant que package.json ne change pas
COPY package*.json ./
RUN npm ci --omit=dev

# Le code applicatif change souvent, on le copie après
COPY . .

EXPOSE 3000
USER node

CMD ["node", "server.js"]

.dockerignore : ne pas envoyer tout le contexte

Comme .gitignore, le .dockerignore exclut des fichiers du contexte de build envoyé au daemon Docker. Crucial pour la performance et la taille des images.

node_modules
.git
.env
*.log
.DS_Store
dist
coverage
Dockerfile
.dockerignore

Multi-stage builds : images de prod légères

Le multi-stage permet de build dans une image lourde (avec tous les outils) puis de ne copier que le résultat dans une image finale minimale. Tu passes facilement de 1,2 Go à 200 Mo.

# Stage 1 : build
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2 : runtime minimal
FROM node:22-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package*.json ./
RUN npm ci --omit=dev
USER node
CMD ["node", "dist/server.js"]

Résultat : l'image finale ne contient que le code compilé et les dépendances de prod. Pas de devDependencies, pas de code source, pas de toolchain.

docker-compose.yml

Le fichier décrit tes services, leurs images, leurs ports, leurs volumes, leurs interconnexions. Tu lances tout d'un seul docker compose up.

services:
  web:
    build: .
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://user:pass@db:5432/app
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
      POSTGRES_DB: app
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d app"]
      interval: 5s
      timeout: 3s
      retries: 5

volumes:
  db-data:

Les commandes essentielles

docker compose up -d         # lance tout en arrière-plan
docker compose up --build    # rebuild les images avant de lancer
docker compose down          # arrête et supprime les conteneurs
docker compose down -v       # supprime aussi les volumes (attention !)
docker compose logs -f web   # suit les logs d'un service
docker compose exec web sh   # shell dans un service en cours
docker compose ps            # liste les services
docker compose restart web   # redémarre un service

Le réseau automatique

Compose crée automatiquement un réseau privé entre tes services. Le nom du service devient le hostname : depuis web, tu peux joindre db avec postgres://user:pass@db:5432. Pas besoin d'IP, pas besoin de localhost.

Deux types de stockage

• Bind mount : tu montes un dossier de ton hôte directement dans le conteneur. Utile en dev pour voir les modifications de code en temps réel.
• Named volume : Docker gère le stockage dans sa propre zone (/var/lib/docker/volumes). Plus propre pour la production.

docker run -v $(pwd):/app node:22 npm test

docker volume create app-data
docker run -v app-data:/data my-app

Quand utiliser quoi

• Bind mount : développement (hot reload), scripts ponctuels, montage de fichiers de config depuis l'hôte
• Named volume : bases de données, uploads d'utilisateur·ices, cache persistant, anything qui doit survivre au cycle de vie d'un conteneur

Sauvegarder un volume

docker run --rm \
  -v app-data:/source:ro \
  -v $(pwd):/backup \
  busybox tar czf /backup/data.tar.gz -C /source .

On lance un conteneur jetable (--rm) avec le volume monté en lecture seule et le dossier courant en backup, puis on tar.gz le contenu. Astuce classique pour faire des dumps réguliers.

Images légères

• Utilise une base alpine (5 Mo) ou distroless (image sans shell, ultra-minimale) plutôt que la base par défaut
• Multi-stage build pour ne garder que le strict nécessaire au runtime
• Combine les RUN avec && pour éviter les layers inutiles
• Nettoie les caches dans la même RUN (apt clean, npm cache clean)

Sécurité

• Ne lance jamais en root en production : ajoute USER node (ou autre user non-root) dans ton Dockerfile
• Ne mets jamais de secret dans le Dockerfile ni dans l'image (utilise les variables d'env au runtime ou un secret manager type Doppler, AWS Secrets Manager)
• Pinne les versions : node:22.5.1-alpine, pas node:latest (build reproductible, pas de surprise)
• Scanne tes images : docker scout cves ou trivy image my-app

Healthchecks

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s \
  CMD curl -f http://localhost:3000/health || exit 1

Sans healthcheck, ton orchestrateur (Kubernetes, Compose, ECS, Nomad) ne sait pas si ton app est vraiment prête à servir du trafic. Il routera des requêtes vers un conteneur cassé.

Logs : stdout, toujours

N'écris pas les logs dans des fichiers à l'intérieur du conteneur. Ils seront perdus à la mort du conteneur, et invisibles depuis l'extérieur. Écris sur stdout et stderr. Docker (et tout orchestrateur) collecte ça automatiquement et le route vers ton système de logs centralisé.

Versionne tes images

• En CI, tagge avec le SHA du commit et un tag sémantique (ex: 1.4.2)
• Garde :latest pour les builds dev uniquement, jamais en prod
• Pousse sur ton registry et garde un historique versionné pour pouvoir rollback rapidement