Tu as déjà vécu ce moment où ton application marche sur ton PC, mais pas sur le serveur ?
Ou l’inverse : « Chez moi ça marche… » devient la phrase maudite du projet ?

Docker est arrivé pour régler ce genre de chaos, avec une idée simple :

On emballe l’application + son environnement (dépendances, config, runtime…) dans un “pack” standard, et on le fait tourner partout de la même manière.

Pas magique. Juste… pratique.

1) Docker, c’est quoi (en langage humain) ?

Image vs conteneur (la métaphore qui aide)

• Une image = une recette figée (un package standardisé contenant tout ce qu’il faut pour exécuter un logiciel).
• Un conteneur = la recette en cours d’exécution (un processus isolé qui tourne à partir de l’image).

Docker s’appuie sur des standards de l’industrie (OCI) qui décrivent comment une image est structurée et comment un runtime exécute un conteneur.

Docker ≠ machine virtuelle

• Une VM embarque un OS complet → plus lourd, plus long à démarrer.
• Un conteneur isole un processus + ses dépendances → plus léger, plus rapide, plus facile à multiplier.

2) Pourquoi utiliser Docker (les vrais bénéfices)

✅ 1. “Ça marche partout”

Tu figes l’environnement dans une image : même versions, mêmes libs, même comportement.
Résultat : moins de surprises entre dev / test / prod.

✅ 2. Démarrage en quelques secondes

Tu peux lancer une base PostgreSQL, Redis, Elasticsearch… en 1 commande, pour tester vite, jeter, recommencer.

✅ 3. Propreté et réversibilité

Installer un outil “en dur” sur ta machine = traces partout.
Avec Docker : tu supprimes le conteneur → tu reviens à un état propre.

✅ 4. Standardisation d’équipe

Même stack, mêmes commandes, mêmes conventions.
C’est souvent plus important que la techno elle-même.

3) Le modèle mental à retenir (en 30 secondes)

1. Tu écris un Dockerfile (la recette).
2. Tu construis une image (docker build).
3. Tu lances un conteneur (docker run).
4. Tu exposes ce qu’il faut :
   • ports (pour accéder au service),
   • volumes (pour garder les données),
   • variables d’environnement (pour configurer).

4) Les commandes Docker essentielles (vraiment utiles)

Lancer un conteneur

docker run --name web -p 8080:80 nginx

• -p 8080:80 = ton PC:8080 → conteneur:80

Voir ce qui tourne

docker ps

Stopper / supprimer

docker stop web
docker rm web

Télécharger une image (si besoin)

docker pull nginx

5) Construire ta propre image (le “hello world” sérieux)

Exemple Dockerfile (application simple)

Un Dockerfile est un fichier texte décrivant comment construire l’image.

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Puis :

docker build -t mon-app:1.0 .
docker run --rm -p 8000:8000 mon-app:1.0

6) Docker Compose : quand tu as plusieurs services

Dès que tu as “app + base de données + cache”, tu veux un bouton ON.

Exemple minimal :

services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    volumes:
      - dbdata:/var/lib/postgresql/data  app:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - dbvolumes:
  dbdata:

Puis :

docker compose up -d
docker compose down

7) Les 4 pièges classiques (et comment les éviter)

Piège 1 — “Mes données ont disparu”

Normal si tu ne stockes rien hors du conteneur.
✅ Utilise des volumes (ou un bind mount) pour les données persistantes.

Piège 2 — “J’ai une image de 2 Go”

Souvent :

• base image trop lourde
• dépendances inutiles
• cache mal géré

✅ Utilise des images “slim”, nettoie le cache, et garde un Dockerfile propre.

Piège 3 — “Ça marche en dev, mais pas en prod”

Cause fréquente : la conf n’est pas externalisée.
✅ Passe la config via variables d’environnement (et pas en dur dans l’image).

Piège 4 — “Docker = sécurité automatique”

Non. Les conteneurs ont des risques spécifiques (images, runtime, registry, droits…).
Le guide NIST SP 800-190 détaille menaces et recommandations (durcissement, scanning, moindre privilège, etc.).

8) Un petit plan “démarrage en 1 heure”

1. Installer Docker (Docker Desktop ou Docker Engine selon ton OS)
2. Faire :
   • docker run nginx
   • docker ps
   • docker stop/rm
3. Faire un Dockerfile minimal
4. Ajouter Compose avec une base
5. Apprendre 3 réflexes :
   • volumes pour les données
   • ports pour l’accès
   • .env pour la config

Tu passes de “Docker c’est flou” à “je peux packager et lancer une stack”.

Sources (avec hyperliens)

• Docker Docs — What is an image?
• Docker Docs — Writing a Dockerfile
• Docker Docs — Dockerfile overview / concepts
• Docker Docs — Dockerfile reference
• Open Container Initiative — Présentation et specs (image/runtime/distribution)
• OCI — Image spec (GitHub)
• OCI — Runtime spec (GitHub)
• NIST — SP 800-190 Application Container Security Guide
• CNCF — containerd project (runtime largement utilisé)