DEV Community: Roméo DOSsOu

Comment dockeriser une API FastAPI de A à Z — Dockerfile expliqué ligne par ligne

Roméo DOSsOu — Wed, 08 Jul 2026 16:31:07 +0000

Introduction

Tu sais faire tourner une API FastAPI en local. Tu lances uvicorn main:app --reload, tu ouvres localhost:8000/docs, et tout fonctionne.

Maintenant, comment tu fais tourner cette même API sur n'importe quelle machine, sans installer Python, sans configurer un environnement virtuel, sans que "ça marche chez moi mais pas chez toi" ?

La réponse, c'est Docker.

Dans cet article, on prend une API CRUD simple — gestion de produits — et on la dockerise de A à Z. Pas de raccourci. Pas d'image mystérieuse qu'on colle sans comprendre. Chaque ligne du Dockerfile sera expliquée, avec la raison exacte pour laquelle elle existe.

À la fin, tu seras capable de dockeriser n'importe quelle API Python simple par toi-même.

Ce qu'on va construire

Une API de gestion de produits avec 4 endpoints :

POST /produits — créer un produit
GET /produits — lister tous les produits
GET /produits/{id} — récupérer un produit par son id
DELETE /produits/{id} — supprimer un produit

Stack : FastAPI + Uvicorn + SQLAlchemy + SQLite + Docker

Repo GitHub : [lien]

Étape 1 — L'API FastAPI

Structure du projet

fastapi-produits/
├── Dockerfile
├── .dockerignore
├── requirements.txt
├── main.py
├── database.py
├── models.py
└── schemas.py

`database.py`

from sqlalchemy import create_engine
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker

DATABASE_URL = "sqlite:///./produits.db"

engine = create_engine(DATABASE_URL, connect_args={"check_same_thread": False})
SessionLocal = sessionmaker(autocommit=False, autoflush=False, bind=engine)
Base = declarative_base()

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

Le yield dans get_db() est important : FastAPI ouvre la session avant la requête, la passe à la route, et la ferme proprement après — même en cas d'erreur.

`models.py`

from sqlalchemy import Column, Integer, String, Float
from database import Base

class Produit(Base):
    __tablename__ = "produits"

    id    = Column(Integer, primary_key=True, index=True)
    nom   = Column(String, nullable=False)
    prix  = Column(Float, nullable=False)
    stock = Column(Integer, default=0)

`schemas.py`

from pydantic import BaseModel

class ProduitCreate(BaseModel):
    nom:   str
    prix:  float
    stock: int = 0

class ProduitRead(ProduitCreate):
    id: int

    class Config:
        from_attributes = True

Deux schémas distincts : ce que le client envoie (ProduitCreate, sans id) et ce que l'API renvoie (ProduitRead, avec id). Le client n'envoie jamais l'id — c'est la base qui le génère.

`main.py`

from fastapi import FastAPI, Depends, HTTPException
from sqlalchemy.orm import Session
import models, schemas
from database import engine, get_db

models.Base.metadata.create_all(bind=engine)

app = FastAPI(title="API Produits", version="1.0.0")

@app.post("/produits", response_model=schemas.ProduitRead, status_code=201)
def creer_produit(produit: schemas.ProduitCreate, db: Session = Depends(get_db)):
    nouveau = models.Produit(**produit.model_dump())
    db.add(nouveau)
    db.commit()
    db.refresh(nouveau)
    return nouveau

@app.get("/produits", response_model=list[schemas.ProduitRead])
def lister_produits(db: Session = Depends(get_db)):
    return db.query(models.Produit).all()

@app.get("/produits/{produit_id}", response_model=schemas.ProduitRead)
def lire_produit(produit_id: int, db: Session = Depends(get_db)):
    produit = db.query(models.Produit).filter(models.Produit.id == produit_id).first()
    if not produit:
        raise HTTPException(status_code=404, detail="Produit non trouvé")
    return produit

@app.delete("/produits/{produit_id}", status_code=204)
def supprimer_produit(produit_id: int, db: Session = Depends(get_db)):
    produit = db.query(models.Produit).filter(models.Produit.id == produit_id).first()
    if not produit:
        raise HTTPException(status_code=404, detail="Produit non trouvé")
    db.delete(produit)
    db.commit()

`requirements.txt`

fastapi==0.111.0
uvicorn==0.29.0
sqlalchemy==2.0.30
pydantic==2.7.1

Pourquoi épingler les versions avec == ? Pour garantir que le build est reproductible. Sans version fixe, pip installe la dernière version disponible — et une mise à jour inattendue peut casser l'app silencieusement.

Teste en local avant de continuer :

python -m venv venv && source venv/bin/activate
pip install -r requirements.txt
uvicorn main:app --reload

http://localhost:8000/docs doit afficher Swagger UI. Si c'est bon, on passe à Docker.

Étape 2 — Le piège du cache Docker

Avant d'écrire le Dockerfile, il faut comprendre un concept qui change tout : le cache des couches.

Docker construit une image couche par couche. Chaque instruction (FROM, COPY, RUN...) crée une couche. Si une couche n'a pas changé depuis le dernier build, Docker la réutilise depuis le cache — sans la reconstruire.

La règle critique : dès qu'une couche change, toutes les couches suivantes sont reconstruites.

❌ L'erreur classique du débutant

COPY . .                              # copie tout le code
RUN pip install -r requirements.txt   # installation après le code

Résultat : tu modifies une ligne dans main.py → Docker voit que COPY . . a changé → il réinstalle toutes les dépendances. À chaque modification.

✅ L'ordre correct

COPY requirements.txt .               # copie UNIQUEMENT requirements.txt
RUN pip install -r requirements.txt   # cette couche est mise en cache
COPY . .                              # le code vient APRÈS

Résultat : tu modifies main.py → requirements.txt n'a pas changé → Docker réutilise la couche pip install → rebuild en 2 secondes.

Sur une connexion lente, ce détail peut faire passer de 3 minutes à 3 secondes par rebuild.

Étape 3 — Le Dockerfile, ligne par ligne

# 1. IMAGE DE BASE
FROM python:3.11-slim

Point de départ : une image Linux avec Python 3.11 déjà installé. La version slim fait ~150MB au lieu de ~1GB pour la version complète. Elle contient tout ce qu'il faut pour faire tourner Python, sans les outils de développement inutiles.

# 2. RÉPERTOIRE DE TRAVAIL
WORKDIR /app

Crée le dossier /app dans le conteneur et le définit comme répertoire courant. Sans ça, les fichiers atterrissent à la racine / — mélangés avec les fichiers système Linux.

# 3. DÉPENDANCES (stratégie de cache)
COPY requirements.txt .
RUN pip install -r requirements.txt --no-cache-dir

Copie uniquement requirements.txt puis installe les dépendances. --no-cache-dir supprime le cache interne de pip — il ne servira jamais dans un conteneur et occupe inutilement de l'espace.

# 4. CODE SOURCE
COPY . .

Copie le reste du projet dans /app. Vient après pip install — c'est la stratégie de cache vue à l'étape 2.

# 5. PORT (documentation uniquement)
EXPOSE 8000

⚠️ EXPOSE ne fait rien au niveau réseau. Il documente simplement le port que l'app utilisera. L'ouverture réelle se fait avec -p dans docker run.

# 6. COMMANDE DE DÉMARRAGE
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Deux points importants ici :

Pourquoi Uvicorn ? FastAPI est un framework, pas un serveur. Il définit les routes et la logique, mais il ne sait pas écouter sur un port réseau. Uvicorn est le serveur ASGI qui fait ce travail. Sans Uvicorn, FastAPI ne reçoit aucune requête.

Pourquoi --host 0.0.0.0 ? 127.0.0.1 = "écoute uniquement les connexions internes à cette machine". Dans un conteneur, "cette machine" c'est le conteneur lui-même. Le navigateur de l'hôte ne peut pas y accéder. 0.0.0.0 = "écoute tout le trafic réseau" — y compris ce qui vient de l'extérieur du conteneur.

Étape 4 — Builder et observer le cache

docker build -t fastapi-produits .

Sortie du terminal (premier build) :

[1/5] FROM python:3.11-slim          12.4s  ← téléchargement
[2/5] WORKDIR /app                    0.0s
[3/5] COPY requirements.txt .         0.0s
[4/5] RUN pip install ...            28.3s  ← installation
[5/5] COPY . .                        0.1s

Maintenant, modifie une ligne dans main.py et rebuilde :

[1/5] FROM python:3.11-slim           0.0s  ← CACHED
[2/5] WORKDIR /app                    0.0s  ← CACHED
[3/5] COPY requirements.txt .         0.0s  ← CACHED
[4/5] RUN pip install ...             0.0s  ← CACHED ✅ (pas de réinstallation)
[5/5] COPY . .                        0.1s  ← seulement ça est reconstruit

La stratégie de cache fonctionne. 2 secondes au lieu de 30.

Étape 5 — Lancer le conteneur

docker run -d -p 8000:8000 --name api-produits fastapi-produits

-d : mode détaché — libère le terminal

-p 8000:8000 : relie le port 8000 de ta machine au port 8000 du conteneur

--name : nom lisible pour référencer le conteneur

Pour voir que tout tourne :

docker ps
docker logs api-produits

Logs attendus :

INFO:     Uvicorn running on http://0.0.0.0:8000
INFO:     Application startup complete.

Teste l'erreur classique : lance le conteneur sans -p, puis essaie d'accéder à localhost:8000. Connexion refusée. L'app tourne parfaitement à l'intérieur, mais sans le mapping de port, le trafic externe n'entre pas.

Étape 6 — Tester via Swagger UI

Ouvre http://localhost:8000/docs.

L'interface Swagger générée automatiquement par FastAPI est disponible — identique à ce qu'on avait en local. La dockerisation n'a rien cassé.

Teste le cycle CRUD complet :

POST /produits — crée un produit avec nom, prix, stock
GET /produits — vérifie qu'il apparaît dans la liste
GET /produits/1 — récupère-le par son id
DELETE /produits/1 — supprime-le
GET /produits/1 → 404 confirmé

Maintenant, arrête le conteneur, supprime-le, et relances-en un nouveau :

docker stop api-produits && docker rm api-produits
docker run -d -p 8000:8000 --name api-produits-2 fastapi-produits

GET /produits → liste vide. Les données ont disparu.

C'est la limite principale de ce projet : la base SQLite est dans le conteneur. Quand le conteneur est supprimé, les données le sont aussi. La solution — les volumes Docker — sera l'objet d'un article dédié.

Résumé — Le Dockerfile complet commenté

# Image de base Python minimale
FROM python:3.11-slim

# Répertoire de travail dans le conteneur
WORKDIR /app

# Dépendances en premier — stratégie de cache
COPY requirements.txt .
RUN pip install -r requirements.txt --no-cache-dir

# Code source après les dépendances
COPY . .

# Documentation du port (n'ouvre rien)
EXPOSE 8000

# Uvicorn sur 0.0.0.0 — obligatoire pour l'accessibilité hors conteneur
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Limites documentées

Ce Dockerfile est volontairement simple. Ce qu'il ne fait pas :

Limite	Solution à venir
Données non persistantes	Volumes Docker
Image non optimisée	Multi-stage build
Processus en root	`USER` non-root
Pas de health check	`HEALTHCHECK` Docker
SQLite	PostgreSQL + Docker Compose

Ces points seront couverts dans les prochains articles de la série.

Conclusion

Tu viens de dockeriser une API FastAPI de A à Z. Pas de magie. Chaque ligne a une raison d'être.

Ce que tu comprends maintenant que tu ne comprenais pas avant :

La différence entre image et conteneur
Pourquoi FastAPI a besoin d'Uvicorn
Comment le cache Docker fonctionne et comment l'exploiter
Pourquoi --host 0.0.0.0 est obligatoire
La différence entre EXPOSE et -p

Le repo complet est disponible sur GitHub : https://github.com/Bordley/fastapi-produits.git

Cet article fait partie d'une série sur Docker et DevOps orientée développeurs francophones.

Suivant : Dockerfile Senior — multi-stage, non-root user, production-ready.

Tags Dev.to : docker fastapi python devops beginners tutorial api backend webdev programming

Tags Hashnode : docker fastapi python devops beginners tutorial rest-api backend web-development containerization

Dockeriser une API Flask de zéro sur Ubuntu : le guide complet pour ingénieurs africains

Roméo DOSsOu — Thu, 02 Jul 2026 17:14:00 +0000

Dockeriser une API Flask de zéro sur Ubuntu : le guide complet

Il y a un problème que tout développeur africain a vécu au moins une fois.

Tu construis une app. Elle tourne parfaitement sur ta machine. Tu l'envoies en production — ou à ton collègue, ou au client. Elle plante.

"Mais ça marchait chez moi…"

Docker est la solution définitive à ce problème. Dans ce guide, je te montre comment dockeriser une API Flask réelle, de bout en bout, sur Ubuntu — avec les bonnes pratiques de production dès le départ.

Ce qu'on va construire

À la fin de ce guide, tu auras :

Un projet Flask cloné depuis GitHub et analysé
Un Dockerfile optimisé avec gestion intelligente du cache
Une app servie par Gunicorn (le vrai serveur de prod, pas flask run)
Une configuration sécurisée par variables d'environnement
Une image versionnée et publiée sur Docker Hub

Prérequis

Ubuntu 22.04 ou 24.04
Docker installé (guide officiel)
Git installé
Connaissances de base en Python et ligne de commande

Étape 1 — Installer Docker sur Ubuntu

Sur Ubuntu, Docker s'installe nativement — pas besoin de virtualisation comme sur Windows.

# Supprime les anciennes versions si présentes
for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do
    sudo apt-get remove $pkg
done

# Installe Docker via le script officiel
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# Autorise ton utilisateur à utiliser Docker sans sudo
sudo usermod -aG docker $USER
newgrp docker

# Vérifie l'installation
docker run hello-world

Si tu vois Hello from Docker! — tu es prêt.

Étape 2 — Cloner et analyser le projet Flask

On part d'un projet existant, comme tu le ferais dans une vraie mission.

git clone https://github.com/gothinkster/flask-realworld-example-app.git
cd flask-realworld-example-app

Avant de toucher quoi que ce soit, lis ces trois fichiers :

cat requirements.txt   # Les dépendances Python
cat autoapp.py         # Le point d'entrée de l'app
cat README.md          # La documentation existante

Ce réflexe — lire avant d'agir — est la marque d'un développeur qui pense avant de coder. C'est ce que cherche un tech lead.

La structure du projet :

flask-realworld-example-app/
├── autoapp.py          ← Point d'entrée Flask
├── requirements.txt    ← Dépendances Python
└── conduit/            ← Code de l'API

Étape 3 — Écrire le Dockerfile

C'est l'étape centrale. Chaque instruction a une raison précise.

# Image de base : Python 3.10 allégée (150 Mo au lieu de 900 Mo)
FROM python:3.10-slim

# Dossier de travail dans le container
WORKDIR /app

# ÉTAPE CLÉE : copier requirements.txt EN PREMIER
COPY requirements.txt .

# Installer les dépendances sans cache pip
RUN pip install --no-cache-dir -r requirements.txt

# Installer Gunicorn — le serveur de production
RUN pip install gunicorn

# Copier le code APRÈS les dépendances
COPY . .

# Documenter le port utilisé
EXPOSE 5000

# Démarrer avec Gunicorn
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "autoapp:app"]

Pourquoi cet ordre précis ?

Docker construit l'image couche par couche. Chaque instruction crée une couche mise en cache.

Si tu copies tout le code d'abord (COPY . .), puis tu fais pip install — le moindre changement dans ton code invalide le cache et force une réinstallation complète de toutes les dépendances.

En copiant requirements.txt seul en premier, le pip install n'est relancé que si les dépendances changent. Si tu modifies juste ton code — le rebuild passe directement au COPY . ..

30 secondes économisées à chaque rebuild. Sur 50 rebuilds par semaine, ça compte.

Pourquoi Gunicorn ?

Le serveur intégré de Flask (flask run) est :

Mono-thread (une requête à la fois)
Non sécurisé pour la production
Prévu uniquement pour le développement

Gunicorn gère plusieurs workers en parallèle et est conçu pour la production.

Pourquoi `0.0.0.0` ?

127.0.0.1 = accessible uniquement de l'intérieur du container → invisible depuis ton navigateur.
0.0.0.0 = accessible depuis l'extérieur → le port mapping fonctionne.

Étape 4 — Créer le .dockerignore

Sans ce fichier, Docker envoie tout ton dossier au moteur de build — y compris les fichiers inutiles ou dangereux.

# .dockerignore
venv/
.venv/
__pycache__/
*.pyc
.env
.git/
*.md

⚠️ .env dans ce fichier est critique. Sans ça, tes clés secrètes pourraient se retrouver dans l'image Docker publiée sur Docker Hub. Publiquement accessibles.

Étape 5 — Builder l'image

docker build -t mon-api-flask:v1 .

Observe les logs. Chaque step correspond à une instruction du Dockerfile.

Maintenant fais un second build sans rien changer :

docker build -t mon-api-flask:v1 .

Tu verras CACHED sur les steps pip install. Le cache fonctionne.

Vérifie l'image créée :

docker images
# REPOSITORY       TAG    SIZE
# mon-api-flask    v1     ~180MB

Étape 6 — Lancer le container et tester

# Lance le container
docker run -d -p 5000:5000 --name api-flask mon-api-flask:v1

# Vérifie qu'il tourne
docker ps

# Lis les logs Gunicorn
docker logs -f api-flask

Ouvre http://localhost:5000 dans ton navigateur. L'API répond.

Décryptage des flags docker run :

Flag	Signification
`-d`	Mode détaché — tourne en arrière-plan
`-p 5000:5000`	Port mapping hôte:container
`--name api-flask`	Nom lisible au lieu d'un hash

Étape 7 — Sécuriser avec les variables d'environnement

# Crée le fichier de configuration
nano .env

FLASK_ENV=production
SECRET_KEY=change-cette-valeur-en-production
PORT=5000

Relance le container avec ces variables injectées :

docker stop api-flask && docker rm api-flask
docker run -d -p 5000:5000 --name api-flask --env-file .env mon-api-flask:v1

# Vérifie que les variables sont bien reçues
docker exec api-flask env

Le principe : l'image Docker ne contient jamais les valeurs sensibles. Elle les reçoit au moment du lancement. La même image peut tourner en dev, staging et production avec des configurations différentes.

Étape 8 — Publier sur Docker Hub

# Connexion
docker login

# Tag avec ton pseudo Docker Hub
docker tag mon-api-flask:v1 tonpseudo/mon-api-flask:v1

# Push
docker push tonpseudo/mon-api-flask:v1

Ton image est maintenant accessible depuis n'importe quel serveur dans le monde :

# Sur n'importe quelle machine avec Docker
docker pull tonpseudo/mon-api-flask:v1
docker run -d -p 5000:5000 tonpseudo/mon-api-flask:v1

C'est ça, la promesse de Docker : construis une fois, fais tourner partout.

Ce que ce projet t'a appris

Concept	Ce que tu maîtrises maintenant
Layers Docker	L'ordre des instructions = stratégie de cache
Port mapping	`-p hôte:container` — sans ça, l'app est invisible
`.dockerignore`	Protège les secrets, allège le build
Variables d'env	Séparation config/code — principe 12-factor
Gunicorn	Serveur WSGI de production pour Python
Docker Hub	Registry public — le "GitHub" des images

Pour aller plus loin

Docker Compose + PostgreSQL — Ajouter une base de données persistante connectée à Flask
GitHub Actions CI/CD — Automatiser build + push à chaque git push
Déploiement VPS — Nginx reverse proxy + HTTPS via Let's Encrypt

Conclusion

Tu n'as plus besoin de dire "ça marchait chez moi".

Ton app Flask est dans une boîte hermétique. Elle tourne sur ton Ubuntu, sur le serveur du client, sur la machine de ton collègue — de manière identique, sans rien réinstaller.

C'est exactement ce qu'un client freelance ou un recruteur veut voir : pas juste du code qui tourne en local, mais un artefact déployable et professionnel.

Le projet est sur GitHub et l'image sur Docker Hub — liens en fin d'article.

Roméo DOSSOU — Cloud & DevSecOps Engineer | Ouidah, Bénin
Je publie des guides pratiques Docker, Kubernetes et Cloud pour les ingénieurs francophones africains.

Docker Compose en production : les 5 erreurs que personne ne te dit

Roméo DOSsOu — Thu, 02 Jul 2026 11:51:10 +0000

Docker Compose en production : les 5 erreurs que personne ne te dit

La plupart des tutoriels Docker Compose t'apprennent à faire tourner une app sur ton ordinateur. Mais quand tu passes en production — un vrai serveur, de vrais utilisateurs, de vraies données — tu découvres des pièges que ces tutoriels n'ont jamais mentionnés.

Cet article ne construit rien from scratch. Il autopsie 5 erreurs réelles, montre ce qui casse, explique pourquoi, et donne la correction exacte. C'est le contenu que les ingénieurs seniors gardent pour eux — et que les juniors paient en nuits blanches pour apprendre.

Niveau requis : tu sais ce qu'est Docker Compose et tu as déjà écrit un docker-compose.yml. Si tu es débutant complet, commence par le TUTORIAL.md avant cet article.

Le fichier qui a l'air correct — mais qui contient 5 bombes

Voici un docker-compose.yml typique. Il a l'air propre. Il fonctionne en local. Chaque ligne a l'air raisonnable.

version: '3.8'
services:
  db:
    image: postgres:15
    environment:
      POSTGRES_PASSWORD: supersecret123    # 💣 Bombe #3
    volumes:
      - ./postgres-data:/var/lib/postgresql/data  # 💣 Bombe #2

  api:
    build: ./backend
    environment:
      FLASK_DEBUG: "true"                  # 💣 Bombe #3
    depends_on:
      - db                                 # 💣 Bombe #1

  nginx:
    image: nginx:alpine                    # 💣 Bombe #4
    ports:
      - "80:80"
                                           # 💣 Bombe #5 : absence de restart/logs

Allons désarmer chaque bombe.

💣 Erreur #1 — Le health check qui ment

Le symptôme

api_1 | OperationalError: could not connect to server
api_1 | Connection refused (host "db", port 5432)
api_1 exited with code 1

Cette erreur apparaît dans les 30 premières secondes du démarrage. En local : invisible (la DB démarre en 2 secondes). Sur un VPS chargé : dévastateur.

La cause racine

depends_on: - db dit à Docker : "attends que le conteneur db soit démarré". Pas qu'il soit prêt à accepter des connexions.

PostgreSQL démarre en plusieurs phases. Le process démarre (← Docker s'arrête là), puis il initialise les fichiers, charge la config, crée les bases — et seulement à la fin il ouvre le port 5432. Sur un VPS avec peu de RAM, ces étapes peuvent prendre 20-40 secondes.

La correction

db:
  image: postgres:15
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U admin -d myapp"]
    interval: 10s
    timeout: 5s
    retries: 5
    start_period: 30s    # ← le paramètre le plus ignoré

api:
  depends_on:
    db:
      condition: service_healthy    # ← attend vraiment que DB soit prête

start_period : pendant les 30 premières secondes, les échecs ne comptent pas. C'est la grâce au démarrage. Sans lui, Docker marque la DB unhealthy avant même qu'elle ait eu le temps de s'initialiser.

💣 Erreur #2 — Les volumes qui font disparaître les données

Le symptôme

docker compose down
docker compose up
# Base de données vide. 3 mois de données clients perdus.

La cause racine

volumes:
  - ./postgres-data:/var/lib/postgresql/data

Un bind mount monte un dossier de ta machine dans le conteneur. C'est parfait pour du code en développement. Pour une base de données en production : problèmes de permissions, risque de corruption, données liées à un seul serveur.

La commande la plus dangereuse de Docker, avec une seule lettre de différence :

docker compose down      # ✅ Conteneurs supprimés, données conservées
docker compose down -v   # ❌ Conteneurs ET volumes supprimés → données perdues

La correction

services:
  db:
    volumes:
      - pgdata:/var/lib/postgresql/data    # volume nommé

volumes:
  pgdata:
    driver: local    # Docker gère l'emplacement

Et séparer dev et prod avec deux fichiers :

# docker-compose.override.yml (dev uniquement, fusionné automatiquement)
services:
  api:
    volumes:
      - ./backend:/app    # live reload uniquement en dev

💣 Erreur #3 — Les secrets exposés

Le symptôme (découvert 48h plus tard)

git log --all -- .env
git show HASH:.env
# POSTGRES_PASSWORD=supersecret123
# Visible dans l'historique Git. Pour toujours.

Des bots scannent GitHub 24h/24. Délai moyen entre le push et la compromission : moins de 4 heures.

Les 3 vecteurs d'exposition

Vecteur 1 : le .env commité dans Git.

Vecteur 2 : un secret passé en ARG dans le Dockerfile.

docker history mon-image
# ENV DATABASE_URL=postgresql://admin:supersecret@db/myapp
# Gravé dans les layers de l'image. Lisible par quiconque y a accès.

Vecteur 3 : Flask en mode debug en production — affiche toutes les variables d'environnement dans le navigateur en cas d'erreur.

La correction

# .gitignore — la ligne la plus importante de ton repo
.env

# docker-compose.yml — référencer, jamais écrire en dur
environment:
  POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}    # lu depuis .env

# Vérifier avant de démarrer
docker compose config
# Toutes les ${VARIABLES} doivent être remplacées par de vraies valeurs

💣 Erreur #4 — Nginx qui dégrade silencieusement

Ces bugs ne génèrent pas d'erreur 500. Ils génèrent des comportements étranges impossibles à diagnostiquer sans savoir où chercher.

Les 4 symptômes

1. L'app reçoit toujours 127.0.0.1 — géolocalisation cassée, rate limiting inutile, logs inutilisables. Cause : headers proxy non configurés.

2. Uploads échouent au-delà d'1MB — valeur par défaut de client_max_body_size. Non documentée dans les tutos. Découverte en production.

3. WebSockets coupés toutes les 60 secondes — proxy_read_timeout par défaut : 60s. Pour un chat en temps réel, c'est catastrophique.

4. Contenu périmé servi aux utilisateurs — Nginx cache les réponses API sans qu'on lui demande.

La configuration production-ready

server {
    listen 80;
    client_max_body_size 50m;    # résout le symptôme #2
    server_tokens off;            # masque la version Nginx

    location /api/ {
        proxy_pass http://api:5000;
        proxy_read_timeout 300s;  # résout le symptôme #3

        # Résout le symptôme #1 :
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Résout le symptôme #4 :
        proxy_no_cache 1;
        add_header Cache-Control "no-store, no-cache, must-revalidate";
    }
}

💣 Erreur #5 — Le crash silencieux

Le symptôme

docker compose ps
# NAME      STATUS              PORTS
# db        Up 3 days (healthy) 5432/tcp
# nginx     Up 3 days (healthy) 0.0.0.0:80->80/tcp
# api       Exited (1) 2h ago   ←  mort depuis 2 heures

Aucune alerte. Aucun redémarrage. L'app était down depuis 2 heures quand le client a appelé.

La correction en 2 parties

Restart policy :

restart: unless-stopped
# Redémarre si crash ✅
# Redémarre au reboot du serveur ✅
# Respecte docker compose stop ✅
# N'entre pas en restart loop ✅

Pourquoi pas always ? Si ton app crashe en boucle à cause d'un bug, always redémarre en boucle — le serveur se sature et tu ne peux plus diagnostiquer.

Logs bornés :

logging:
  driver: "json-file"
  options:
    max-size: "10m"    # 10MB par fichier
    max-file: "5"      # 5 fichiers max = 50MB total

Sans ça, les logs grossissent indéfiniment. Sur un VPS avec 20GB de disque, ils peuvent tout saturer en quelques semaines — et quand le disque est plein, tout crashe.

La checklist — à garder ouverte à chaque déploiement

# Zone 1 — Health Checks
docker compose config | grep healthcheck
docker compose ps    # → tous "(healthy)"

# Zone 2 — Volumes
docker volume ls     # → volume nommé présent

# Zone 3 — Secrets
git log --all -- .env    # → aucun résultat
docker compose config | grep POSTGRES_PASSWORD    # → vraie valeur, pas ${VAR}

# Zone 4 — Nginx
docker exec nginx nginx -t    # → "syntax is ok"
grep "X-Real-IP" nginx.conf   # → présent

# Zone 5 — Restart & Logs
docker compose config | grep restart    # → "unless-stopped" partout
docker compose config | grep max-size   # → "10m" partout

La checklist complète avec toutes les commandes de vérification est disponible dans le repo GitHub : PRODUCTION.md

Conclusion

La différence entre un environnement de dev et un environnement de production se résume souvent à ces 5 zones. Les corriger toutes d'un coup, dès le départ, c'est exactement ce qui différencie un livrable junior d'un livrable senior.

Un Compose qui tourne en local, c'est un prototype.
Un Compose qui passe la checklist, c'est un livrable professionnel.

📎 Ressources

Repo GitHub complet : https://github.com/Bordley/docker-compose-production-checklist.git
Documentation officielle Docker : docs.docker.com/compose/compose-file
12-factor app methodology : 12factor.net

Par **Bordley* — IT Manager & DevOps Engineer, Cotonou, Bénin 🇧🇯*
Contenu DevOps en français pour les ingénieurs africains et les équipes internationales.

Comment travailler en équipe avec Git — Workflow complet pour débutants

Roméo DOSsOu — Wed, 01 Jul 2026 14:52:41 +0000

Branches, Pull Requests, code review, conflits : tout ce que personne ne t'a vraiment expliqué.

Quand tu apprends Git seul, tu maîtrises git add, git commit, git push. Puis tu rejoins une équipe et tu réalises que tu ne sais pas vraiment travailler à plusieurs. Les branches te font peur. Les conflits te paralysent. Les Pull Requests t'intimidaient.

Cet article va changer ça.

On va simuler une vraie session de travail en équipe : deux développeurs (Alice et Bob) qui implémentent deux features en parallèle, se font reviewer mutuellement, tombent sur un conflit, et le résolvent proprement. Chaque commande est expliquée. Chaque décision est justifiée.

Le contexte

On travaille sur une API REST Node.js. L'équipe utilise le GitHub Flow — le workflow le plus répandu dans l'industrie.

Principe fondamental du GitHub Flow :

main est toujours stable et déployable
Chaque feature vit sur sa propre branche
On merge via une Pull Request reviewée par un pair
On ne merge que si les tests passent

Deux features sont à développer en parallèle :

Alice → feature/PROJ-101-user-authentication (authentification JWT)
Bob → feature/PROJ-102-user-profile (profil utilisateur)

Les deux touchent src/routes.js — le conflit est inévitable. Et c'est voulu.

Phase 1 — Poser les fondations

Le lead initialise le projet avec une structure propre et un premier commit :

mkdir api-projet && cd api-projet
git init
mkdir -p src/{api,middleware,models,services} tests
git add .
git commit -m "chore: initialiser la structure du projet API"

Pourquoi ce format de message ?

chore: initialiser la structure du projet API suit la convention Conventional Commits. Le format est type(scope): description. Les types courants :

Type	Usage
`feat`	Nouvelle fonctionnalité
`fix`	Correction de bug
`chore`	Maintenance, config
`test`	Ajout/modification de tests
`refactor`	Refactorisation sans changement de comportement

Un historique de commits bien formaté se lit comme un journal de bord. Dans 6 mois, toi ou un collègue pourrez comprendre l'évolution du projet sans lire une seule ligne de code.

Phase 2 — Alice travaille sur l'authentification

Créer une branche, c'est créer un espace de travail isolé

git switch -c feature/PROJ-101-user-authentication

git switch -c crée la branche ET bascule dessus. À ce moment, la branche est une copie exacte de main. Ce que Alice fait ici n'affecte pas main ni le travail de Bob.

Des commits atomiques, pas un gros commit fourre-tout

Alice fait 5 commits distincts — un par responsabilité :

# 1. Le middleware JWT
git commit -m "feat(auth): implémenter le middleware JWT"

# 2. Le service (logique métier pure)
git commit -m "feat(auth): ajouter le service de génération JWT"

# 3. Le controller (pont entre HTTP et service)
git commit -m "feat(auth): ajouter le controller POST /auth/login"

# 4. Les routes
git commit -m "feat(auth): enregistrer les routes d'authentification"

# 5. Les tests
git commit -m "test(auth): ajouter les tests du module authentification"

Pourquoi pas tout en un seul commit ?

Parce que si demain le controller a un bug et qu'on doit faire un git revert, on veut pouvoir annuler seulement le controller — pas le middleware, pas le service, pas les tests. Des commits atomiques = des rollbacks précis.

Une décision sécurité intentionnelle

Dans auth-controller.js, le message d'erreur est volontairement identique dans les deux cas :

// L'email n'existe pas dans la base
return res.status(401).json({ error: 'Identifiants invalides' });

// Le mot de passe est faux
return res.status(401).json({ error: 'Identifiants invalides' });

Pourquoi ? Si les messages étaient différents ("Email inconnu" vs "Mot de passe incorrect"), un attaquant pourrait tester des milliers d'emails pour savoir lesquels sont enregistrés. On appelle ça l'énumération de comptes — une faille de sécurité classique.

Phase 3 — Bob travaille en parallèle

L'isolation des branches en pratique

git switch main          # Bob revient sur main
git switch -c feature/PROJ-102-user-profile

Bob part de main — pas de la branche d'Alice. Il développe GET /users/:id et modifie aussi src/routes.js sans le savoir.

Visualisation de la situation :

main          ──●────────────────────────
                 \              \
Alice             ●──●──●──●──●  (routes.js version Alice)
                 \
Bob               ●──●──●        (routes.js version Bob)

Les deux branches ont divergé depuis le même point. Elles vont devoir se rejoindre.

Ne jamais exposer les données sensibles

// user-controller.js
const { password_hash, ...safeUser } = user;
res.json(safeUser); // password_hash n'est jamais envoyé au client

C'est du JavaScript destructuring : on extrait password_hash pour l'écarter, et on retourne tout le reste. Simple et efficace.

Phase 4 — Pull Requests et code review

Alice ouvre la PR #1. Bob la review.

Ce qu'une bonne PR contient

Titre  : feat(auth): implémenter l'authentification JWT (PROJ-101)
Base   : main ← feature/PROJ-101-user-authentication

## Ce que fait cette PR
- Middleware de vérification des tokens JWT
- Service de génération/vérification
- Endpoint POST /auth/login

## Comment tester
npm test -- --testPathPattern=auth

## Checklist
✅ Tests ajoutés | ✅ Pas de secrets hardcodés

Une bonne description de PR répond à 3 questions : quoi (ce qui change), pourquoi (le contexte), comment (tester).

Bob trouve une faille critique

[SUGGESTION] JWT_SECRET ne devrait pas être optionnel en production.
Si JWT_SECRET n'est pas défini, les tokens sont signés avec
'dev-secret-change-in-prod' — n'importe qui connaissant ce secret
peut forger des tokens valides.

Alice corrige immédiatement :

if (!process.env.JWT_SECRET && process.env.NODE_ENV === 'production') {
    throw new Error('JWT_SECRET est requis en production');
}

C'est ça la valeur d'une code review. Un deuxième regard voit ce qu'on ne voit plus à force de travailler sur le même code.

Bob approuve. Alice merge dans main.

Phase 5 — Le conflit (ne pas paniquer)

Bob tente de mettre à jour sa branche :

git rebase main

Git s'arrête :

CONFLICT (content): Merge conflict in src/routes.js

Comprendre les marqueurs de conflit

<<<<<<< HEAD
const { login } = require('./api/auth-controller');
const { authenticate } = require('./middleware/auth');
=======
const { getUserById } = require('./api/user-controller');
>>>>>>> c8f3b2a

Entre <<<<<<< HEAD et ======= : la version de main (le travail d'Alice)
Entre ======= et >>>>>>> : la version de Bob

Git ne sait pas laquelle choisir — il n'est pas qualifié pour faire ce jugement métier. C'est toujours une décision humaine.

La résolution intelligente

Bob ne choisit pas entre Alice et lui — il combine les deux :

// Version finale — combine les deux features
const { login } = require('./api/auth-controller');
const { authenticate } = require('./middleware/auth');
const { getUserById } = require('./api/user-controller');

router.post('/auth/login', login);
router.get('/users/:id', authenticate, getUserById); // Bob ajoute authenticate !
router.get('/protected', authenticate, ...);

En voyant le middleware d'Alice, Bob réalise que /users/:id ne devrait pas être public. Le rebase l'a forcé à prendre une décision de sécurité qu'il aurait pu manquer.

git add src/routes.js
git rebase --continue
git push --force-with-lease origin feature/PROJ-102-user-profile

Pourquoi `--force-with-lease` et pas `--force` ?

--force écrase la branche distante sans vérification. Si un collègue a poussé quelque chose entre-temps, son travail est perdu.

--force-with-lease vérifie d'abord que personne n'a poussé depuis ta dernière synchronisation. Si c'est le cas, il refuse et t'alerte. C'est la version respectueuse de --force.

Rebase vs Merge — le débat tranché

# Avec merge
* Merge commit
|\
| * commit Bob
| * commit Bob
* Merge pull request d'Alice
|\
| * commit Alice

# Avec rebase
* commit Bob
* commit Bob
* Merge pull request d'Alice
* commit Alice
* commit initial

Le rebase donne un historique linéaire et lisible. On utilise :

rebase pour mettre à jour sa branche feature depuis main
merge --no-ff pour intégrer une PR dans main (conserve la trace de la branche)

Phase 6 — Merge final et leçon sur le scope des PRs

Alice review la PR de Bob et suggère un refactor du router. Bob répond :

"Excellente suggestion — je crée un ticket PROJ-115. Cette PR reste focalisée sur le profil utilisateur."

C'est la bonne réponse. Une PR qui gonfle en cours de review :

Retarde le merge
Mélange les responsabilités
Complique les rollbacks potentiels
Fatigue le reviewer

Une PR = une feature = un ticket. Toujours.

L'historique final : une histoire lisible

*   Merge pull request #2 — feat(users)
|\
| * test(users): tests GET /users/:id
| * feat(users): route GET /users/:id
| * feat(users): controller GET /users/:id
*   Merge pull request #1 — feat(auth)
|\
| * fix(auth): JWT_SECRET obligatoire en prod
| * test(auth): tests authentification
| * feat(auth): routes auth
| * feat(auth): controller login
| * feat(auth): service JWT
| * feat(auth): middleware JWT
|/
* chore: initialiser le projet

N'importe quel développeur qui rejoint l'équipe peut lire cet historique et comprendre comment le projet a évolué. C'est l'objectif.

Ce qu'on a appris

Sur Git :

Les branches isolent le travail — on ne pollue pas main
Les commits atomiques permettent des rollbacks précis
Le rebase nettoie l'historique avant de merger
Les conflits ne sont pas des bugs — ce sont des signaux que deux personnes ont travaillé sur la même zone

Sur le travail en équipe :

Une PR décrit le quoi et le pourquoi, pas seulement le comment
La code review est collaborative, pas confrontationnelle
Le scope d'une PR ne grandit pas en cours de review
Une deuxième paire d'yeux attrape ce qu'on ne voit plus

Sur la sécurité :

JWT_SECRET obligatoire en production
Messages d'erreur génériques pour éviter l'énumération de comptes
Ne jamais exposer les données sensibles dans les réponses API
Les routes avec données personnelles sont toujours protégées

Le code source complet de ce projet est disponible sur GitHub.

N'hésite pas à forker et rejouer les phases toi-même — c'est en faisant qu'on retient.

J'ai conteneurisé une app métier complète en 2h : Docker Compose, Nginx, Flask, PostgreSQL

Roméo DOSsOu — Wed, 01 Jul 2026 08:28:29 +0000

J'ai conteneurisé une app métier complète en 2h — Docker Compose, Nginx, Flask, PostgreSQL

La plupart des tutoriels Docker s'arrêtent à docker run hello-world ou au conteneur unique.

En entreprise, une vraie application c'est plusieurs services qui travaillent ensemble : une base de données, un backend, un serveur web. Ce guide montre comment orchestrer tout ça avec Docker Compose, en construisant une app de gestion de stock pour une PME africaine — de zéro à un environnement production-ready.

🎯 Ce qu'on va construire

taskflow-stock : une API REST de gestion de stock et facturation, avec 3 services Docker orchestrés :

INTERNET → NGINX (reverse proxy)
              ↓
           FLASK API (logique métier, Gunicorn)
              ↓
           POSTGRESQL (données persistées)

À la fin, une seule commande lance tout :

docker compose up --build

🏗️ Architecture — Pourquoi 3 services séparés ?

Chaque service a une seule responsabilité :

Service	Rôle	Image
`nginx`	Reçoit le trafic HTTP, redirige vers Flask	`nginx:alpine`
`api`	Logique métier, endpoints REST	Custom (Python 3.12 Alpine)
`db`	Stockage persistant	`postgres:15-alpine`

Principe clé : moindre exposition.
Seul Nginx a un ports: dans le Compose. Flask et PostgreSQL sont invisibles depuis l'extérieur — accessibles uniquement via le réseau Docker interne app-network.

📁 Structure du projet

taskflow-stock/
├── app/
│   ├── app.py              # Flask + SQLAlchemy
│   ├── requirements.txt
│   ├── Dockerfile          # Multi-stage Alpine
│   └── .dockerignore
├── nginx/
│   └── nginx.conf          # Reverse proxy config
├── postgres/
│   └── init.sql            # Init automatique au 1er démarrage
├── docker-compose.yml
├── .env                    # Secrets (jamais sur Git)
└── .env.example            # Modèle versionnable

🐍 Le backend Flask — Modèles métier contextualisés

J'ai délibérément choisi des entités qui parlent à la réalité des PME africaines :

class Produit(db.Model):
    __tablename__ = 'produits'
    id        = db.Column(db.Integer, primary_key=True)
    nom       = db.Column(db.String(100), nullable=False)  # "Huile de palme 1L"
    reference = db.Column(db.String(50), unique=True, nullable=False)
    prix      = db.Column(db.Float, nullable=False)         # En FCFA
    stock     = db.relationship('Stock', backref='produit', uselist=False)

class Stock(db.Model):
    __tablename__ = 'stocks'
    produit_id   = db.Column(db.Integer, db.ForeignKey('produits.id'))
    quantite     = db.Column(db.Integer, default=0)
    seuil_alerte = db.Column(db.Integer, default=10)  # Alerte si stock critique

La connexion à la base ne contient aucun mot de passe dans le code :

app.config['SQLALCHEMY_DATABASE_URI'] = os.environ.get('DATABASE_URL')

Tout vient du .env, jamais du code source.

🐳 Le Dockerfile — Multi-stage build

Le secret d'une image légère : séparer la compilation de l'exécution.

# Stage 1 : installation des dépendances (avec outils de compilation)
FROM python:3.12-alpine AS builder
RUN apk add --no-cache gcc musl-dev postgresql-dev
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

# Stage 2 : image finale (sans les outils de build)
FROM python:3.12-alpine
RUN apk add --no-cache libpq
RUN adduser -D appuser       # Utilisateur non-root
WORKDIR /app
COPY --from=builder /install /usr/local
COPY . .
RUN chown -R appuser:appuser /app
USER appuser
EXPOSE 5000
CMD ["gunicorn", "-w", "2", "-b", "0.0.0.0:5000", "app:app"]

Résultat : image finale < 90MB, sans compilateur, sans outils inutiles.

Astuce cache Docker : toujours copier requirements.txt AVANT le code source. Si les dépendances ne changent pas, Docker saute le pip install — le build prend 5 secondes au lieu de 2 minutes.

⚙️ Nginx — Le reverse proxy

upstream flask_app {
    server api:5000;  # "api" = nom du service Docker, résolu automatiquement
}

server {
    listen 80;

    location / {
        proxy_pass http://flask_app;
        proxy_set_header Host             $host;
        proxy_set_header X-Real-IP        $remote_addr;
        proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

La magie de api:5000 : dans un réseau Docker, chaque service est joignable par son nom. Docker maintient un DNS interne — pas besoin de connaître les IPs, elles changent à chaque recréation de conteneur.

🎼 Docker Compose — L'orchestrateur

La partie la plus importante : gérer l'ordre de démarrage correctement.

services:

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - pgdata:/var/lib/postgresql/data          # Persistance
      - ./postgres/init.sql:/docker-entrypoint-initdb.d/init.sql:ro
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 5s
      retries: 5

  api:
    build: ./app
    environment:
      DATABASE_URL: ${DATABASE_URL}
    depends_on:
      db:
        condition: service_healthy   # ← attend que db soit VRAIMENT prêt

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"                      # ← seul port exposé
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      api:
        condition: service_healthy

networks:
  app-network:
    driver: bridge

volumes:
  pgdata:
    driver: local

condition: service_healthy vs depends_on simple :

depends_on: - db : attend que le conteneur soit démarré
depends_on: db: condition: service_healthy : attend que PostgreSQL accepte vraiment des connexions

La différence élimine 90% des erreurs "connection refused" au démarrage.

🧪 Tests de résilience — Ce qui distingue un ingénieur

Test 1 — Persistance

docker compose down          # Arrête tout (volumes conservés)
docker compose up -d         # Redémarre
curl http://localhost/api/produits  # ✅ Données toujours là

Test 2 — Panne partielle

docker compose kill api                    # Simule un crash applicatif
curl http://localhost/api/produits         # → 502 (Nginx tient ✅)
docker compose up -d api                   # Relance uniquement Flask
curl http://localhost/api/produits         # → données de retour ✅

Un 502 Bad Gateway est ici une bonne nouvelle : Nginx reste opérationnel et signale proprement l'indisponibilité du backend, au lieu de crasher lui-même.

💡 Les 5 leçons que ce projet m'a enseignées

"Démarré" ≠ "Prêt" — service_healthy existe pour cette raison
DNS interne Docker — les noms de services sont des hostnames, pas des IPs
Le moindre port exposé — chaque port ouvert est une surface d'attaque
Les secrets vivent dans .env, jamais dans le code ou l'image
Un 502 bien géré vaut mieux qu'un timeout silencieux

🔄 La suite naturelle

Ce projet est la base de 3 extensions :

VPS + HTTPS — déployer sur Ubuntu avec Let's Encrypt
Monitoring — Prometheus + Grafana en conteneurs supplémentaires
CI/CD — GitHub Actions qui déploie automatiquement à chaque push

📎 Ressources

🔗 https://github.com/Bordley/Taskflow-stock.git
📹 https://youtu.be/cyUCMntb5KA?si=t0-N-sFcKciiGQZb
📚 Doc officielle Docker Compose : docs.docker.com/compose

Si ce guide t'a aidé, partage-le — et laisse un commentaire avec ta question ou ton propre projet Docker 👇

Bonne conteneurisation ! 🐳

Écrit par Bordley — IT Manager & DevOps Engineer, Bénin 🇧🇯
Je publie des contenus sur le Cloud et DevOps dans le contexte africain.

#docker #devops #python #flask #postgresql #nginx #francophone #beginners #tutorial #africa

J'ai écrit le Dockerfile que TOUT débutant écrit — puis je l'ai détruit erreur par erreur

Roméo DOSsOu — Fri, 26 Jun 2026 11:25:18 +0000

J'ai écrit le Dockerfile que TOUT débutant écrit — puis je l'ai détruit erreur par erreur

Il y a quelques semaines, j'ai écrit mon premier vrai Dockerfile "instinctif" — celui que n'importe qui produit en suivant juste sa logique, sans connaître les bonnes pratiques. Et il fonctionnait. L'application démarrait, je voyais ma page web, j'étais content.

Sauf que ce Dockerfile pesait 1,1 Go, exposait une clé API en clair, et faisait tourner mon code avec les pleins pouvoirs administrateur. Sans le savoir.

Cet article raconte comment je suis passé de ce Dockerfile naïf à une version professionnelle de 90 Mo, en corrigeant 7 erreurs une par une — avec, à chaque étape, la preuve concrète du problème avant la solution.

Si tu n'as jamais touché Docker, tu peux suivre cet article sans aucun prérequis. Si tu en as déjà fait, tu vas probablement reconnaître au moins 3 de ces erreurs dans tes propres projets (je ne juge pas, je les ai toutes faites).

Le point de départ : le Dockerfile qu'on écrit tous

Voici, mot pour mot, le genre de Dockerfile qu'on produit naturellement quand on découvre Docker :

FROM node:20
WORKDIR /app
COPY . .
RUN npm install
ENV API_KEY=mon_super_secret_123
EXPOSE 3000
CMD ["node", "app.js"]

Sept lignes. Ça marche. Et ça contient sept problèmes différents. Voyons-les un par un.

Erreur n°1 et 2 : l'ordre des instructions détruit le cache

Docker construit une image en couches. Chaque ligne du Dockerfile = une couche. Et Docker met en cache les couches qui n'ont pas changé, pour ne pas refaire un travail inutile.

Le souci avec COPY . . placé avant RUN npm install : si tu modifies un seul fichier de ton code, Docker considère que la couche COPY . . a changé — et il refait tout ce qui suit, y compris npm install, qui pourtant n'a rien à voir avec ton changement.

Résultat concret : 25 à 30 secondes perdues à chaque rebuild, pour rien.

La correction :

FROM node:20
WORKDIR /app

# On copie SEULEMENT les fichiers de dépendances d'abord
COPY package.json package-lock.json ./
RUN npm install

# Le code source, qui change souvent, vient APRÈS
COPY . .

Après cette correction, modifier ton code source ne déclenche plus jamais un npm install inutile. La ligne apparaît en cache (CACHED) à chaque rebuild, tant que tu ne touches pas à package.json.

La règle à retenir : dans un Dockerfile, on place ce qui change rarement en haut, et ce qui change souvent en bas.

Erreur n°3 : pas de `.dockerignore`

Sans ce fichier, l'instruction COPY . . copie absolument tout ce qui se trouve dans ton dossier de projet — y compris des choses que tu ne voudrais jamais voir dans une image : node_modules (inutile, il est recréé par npm install), .git (tout ton historique de commits), et surtout un éventuel fichier .env contenant tes mots de passe locaux.

J'ai testé en créant un faux .env avec un mot de passe factice, puis j'ai lancé :

docker run --rm mon-app ls -la /app

Le fichier .env apparaissait dans la liste. Sans aucune protection.

La correction, un fichier .dockerignore classique :

node_modules/
.git/
.env
*.log
tests/

Même logique qu'un .gitignore, mais pour Docker.

Erreur n°4 : la démonstration qui m'a le plus marqué — les secrets immuables

Celle-ci vaut la peine d'être détaillée parce qu'elle m'a vraiment surpris.

J'ai écrit ceci dans mon Dockerfile :

ENV API_KEY=mon_super_secret_123
RUN unset API_KEY

Mon intuition de débutant : "j'ai supprimé la variable juste après, donc elle ne devrait plus être visible". Faux.

docker history --no-trunc mon-app

Le secret apparaît, en clair, dans l'historique des couches. Pour toujours. Parce que chaque couche Docker est immuable — une fois écrite, elle ne disparaît jamais, même si une couche suivante "annule" son effet visible.

C'est exactement le genre de vulnérabilité qu'on retrouve régulièrement dans des images publiées par erreur sur des registries publics, avec des clés AWS ou des tokens GitHub encore lisibles dans l'historique.

La correction : ne jamais écrire de valeur sensible dans le Dockerfile. On déclare la variable vide, et on injecte sa vraie valeur au moment du docker run :

ENV API_KEY=""

docker run --env-file .env.runtime mon-app

Le fichier .env.runtime ne quitte jamais ta machine — il n'est jamais copié dans l'image.

Erreur n°5 : tourner en root

Par défaut, si tu ne précises rien, ton application tourne avec l'utilisateur root — l'équivalent administrateur sous Linux. Si quelqu'un trouve une faille dans ton code et l'exploite, il obtient directement les pleins pouvoirs sur le conteneur.

La correction :

RUN useradd -m -s /bin/sh appuser
RUN chown -R appuser:appuser /app
USER appuser

Après ça, docker run mon-app whoami répond appuser au lieu de root. C'est le principe du moindre privilège — un classique de la sécurité système, appliqué en deux lignes.

Erreurs n°6 et 7 : une image dix fois trop lourde

Mon image naïve pesait 1,1 Go. Pour comprendre pourquoi, il faut comprendre ce que contient réellement node:20 : un système Debian complet, avec des centaines d'outils dont mon application n'utilise jamais 1%.

Première correction, changer l'image de base :

FROM node:20-alpine

Alpine est une distribution Linux minimaliste. Ce seul changement m'a fait passer de 1,1 Go à environ 180 Mo.

Deuxième correction, le multi-stage build — la technique la plus puissante de tout ce projet. L'idée : séparer la phase de construction de l'application (qui a besoin de tous les outils) de la phase d'exécution (qui n'a besoin que du résultat final).

# Stage 1 : on construit, avec tous les outils nécessaires
FROM node:20-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install --omit=dev
COPY . .

# Stage 2 : on ne garde que le strict nécessaire
FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/app.js ./app.js
COPY --from=builder /app/package.json ./package.json
USER appuser
CMD ["node", "app.js"]

Résultat final : environ 90 Mo. Une réduction de 92% par rapport au point de départ.

Le bilan complet

Erreur	Risque	Gain après correction
Mauvais ordre des couches	Rebuild lent à chaque changement	30s → 0,1s
Pas de `.dockerignore`	Fichiers sensibles copiés	Image plus légère et sûre
Secrets en dur	Fuite de clés API permanente	Zéro secret dans l'image
Exécution en root	Accès total en cas de faille	Utilisateur limité
Image lourde	1,1 Go pour rien	-80% avec Alpine
Pas de multi-stage	Outils de build embarqués	-92% au total

Ce que j'en retiens

La leçon la plus importante de tout ce projet : un Dockerfile qui fonctionne et un Dockerfile qui est bien fait sont deux choses complètement différentes. La première version naïve ne plante jamais — c'est justement ce qui la rend dangereuse, parce qu'on ne voit aucun signal d'alarme.

J'ai documenté l'intégralité de ce projet, avec le code source testable des deux versions (avant/après) et un guide pas-à-pas niveau zéro absolu, dans ce dépôt GitHub :

👉 https://github.com/Bordley/mon-app.git

Si tu repères d'autres erreurs classiques que je n'ai pas couvertes, ou si tu veux discuter d'un point précis, les commentaires sont ouverts.

title: "Docker Volumes : pourquoi tes données disparaissent (et comment les protéger pour de bon)"

Roméo DOSsOu — Thu, 25 Jun 2026 11:39:14 +0000

published: true
tags: docker, devops, mysql, beginners
cover_image:
canonical_url:

Docker Volumes : pourquoi tes données disparaissent (et comment les protéger pour de bon)

Le piège dans lequel je suis tombé (et toi aussi, probablement)

Voici une expérience que je te conseille de faire toi-même, une seule fois, pour bien comprendre la leçon.

docker run -d --name mysql-demo -e MYSQL_ROOT_PASSWORD=secret mysql:8.0

Tu te connectes, tu crées une table clients, tu insères 3 lignes. Tu vérifies : tout est là.

Puis :

docker rm -f mysql-demo
docker run -d --name mysql-demo -e MYSQL_ROOT_PASSWORD=secret mysql:8.0

Tu te reconnectes :

SELECT * FROM clients;
-- ERROR 1146 (42S02): Table 'shop.clients' doesn't exist

Tout a disparu. Pas un bug. Pas une erreur de manipulation. C'est exactement comme ça que Docker est censé fonctionner — et c'est précisément pour ça que les volumes existent.

Dans cet article, je t'explique pourquoi ça arrive, et comment je l'ai résolu avec un projet complet simulant l'infrastructure d'une PME (base de données, fichiers clients, sessions).

Pourquoi Docker "oublie" tout par défaut

Un container Docker repose sur un système de fichiers en couches, appelé OverlayFS. Schématiquement :

┌─────────────────────────────────┐
│  COUCHE D'ÉCRITURE (container)  │ ← temporaire
├─────────────────────────────────┤
│  COUCHES DE L'IMAGE (lecture    │ ← permanentes
│  seule)                         │
└─────────────────────────────────┘

L'image (lecture seule) contient le système et les binaires — elle ne change jamais. Quand tu lances un container, Docker ajoute une couche d'écriture par-dessus, où vivent tous les fichiers créés ou modifiés pendant l'exécution.

Le problème : docker rm détruit cette couche d'écriture. Et comme rien n'a été écrit ailleurs, tout part avec elle.

L'analogie qui m'a aidé à vraiment comprendre : l'image est un livre imprimé. La couche d'écriture est un post-it collé dessus. Tu jettes le post-it → tes notes disparaissent, mais le livre reste intact. Le livre, ici, c'est l'image — jamais affectée par la suppression d'un container.

Les 3 solutions, et quand utiliser laquelle

1. Named Volume — pour les données critiques

Un named volume est un espace de stockage entièrement géré par Docker. Tu lui donnes un nom, Docker s'occupe du reste.

services:
  db:
    image: mysql:8.0
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

Quand l'utiliser : toute base de données (MySQL, Postgres, MongoDB...). C'est la protection minimale non-négociable pour n'importe quelle donnée que tu ne peux pas te permettre de perdre.

Preuve que ça fonctionne :

docker compose down        # supprime les containers, PAS le volume
docker compose up -d       # les données sont toujours là

2. Bind Mount — pour les fichiers accessibles depuis le serveur

Un bind mount connecte un dossier de ta machine hôte directement à un dossier du container. Les deux dossiers sont littéralement le même dossier, vu depuis deux côtés différents.

services:
  app:
    image: nginx:alpine
    user: "1000:1000"
    volumes:
      - ./uploads:/usr/share/nginx/html/uploads

Quand l'utiliser : fichiers uploadés par les utilisateurs, fichiers de configuration, code source en développement.

⚠️ Le piège classique : un fichier créé depuis l'intérieur du container appartient à root par défaut. Si ton script de déploiement tourne avec un utilisateur normal, il ne pourra pas le supprimer ou le modifier. La ligne user: "1000:1000" (ton UID Linux, trouvable avec la commande id) résout ce problème en alignant les permissions.

3. tmpfs — pour les données sensibles et temporaires

Un tmpfs est un espace de stockage qui vit exclusivement en RAM. Il n'est jamais écrit sur disque, et il disparaît automatiquement à l'arrêt du container.

services:
  app:
    tmpfs:
      - /tmp/sessions:size=64m,mode=1777

Quand l'utiliser : tokens de session, secrets temporaires, cache haute performance non-critique.

Pourquoi c'est important pour la sécurité : si un token de session n'existe qu'en RAM, il ne peut pas être lu via un backup disque ou un accès physique malveillant au serveur. C'est le même principe utilisé par des outils comme HashiCorp Vault pour la gestion de secrets.

Le tableau de décision

Besoin	Type à utiliser
Base de données	Named Volume
Fichiers uploadés / configuration	Bind Mount
Code source en dev (hot-reload)	Bind Mount
Sessions / secrets temporaires	tmpfs
Cache rapide non-critique	tmpfs

Et si le volume lui-même est supprimé ? (Backup & Restore)

Un named volume protège contre la suppression du container. Mais que se passe-t-il si le volume lui-même est supprimé, ou si le serveur entier est perdu ?

C'est là qu'intervient la sauvegarde. Comme Docker cache l'emplacement réel d'un named volume, on ne peut pas simplement faire un cp. La technique standard consiste à utiliser un container Alpine temporaire qui sert de pont entre le volume et un dossier de backup :

docker run --rm \
  -v db_data:/data:ro \
  -v $(pwd)/backups:/backups \
  alpine \
  tar czf /backups/db_backup_$(date +%Y%m%d_%H%M%S).tar.gz -C /data .

Et pour restaurer après une suppression totale du volume :

docker volume create db_data

docker run --rm \
  -v db_data:/data \
  -v $(pwd)/backups:/backups:ro \
  alpine \
  tar xzf /backups/db_backup_20260615.tar.gz -C /data

J'ai testé cette procédure de bout en bout : suppression volontaire du volume, puis restauration complète. Toutes les données sont revenues, exactement comme avant le sinistre.

La stack finale

Le projet complet assemble 3 services représentant une infrastructure réaliste de PME :

App (nginx) → Bind Mount pour les uploads + tmpfs pour les sessions
MySQL → Named Volume pour la base de données
Redis → Named Volume + tmpfs pour le cache

Avec un healthcheck pour fiabiliser le démarrage, un utilisateur dédié non-root pour la base de données (principe du moindre privilège), et une politique de redémarrage automatique.

Le code complet est disponible sur GitHub (lien à ajouter).

Ce que j'en retiens

Comprendre les volumes Docker, ce n'est pas mémoriser trois commandes. C'est comprendre que le cycle de vie d'un container et le cycle de vie d'une donnée sont deux choses complètement différentes. Un container est jetable par design — c'est même ce qui rend Docker puissant (scalabilité, mises à jour sans risque, reproductibilité). Une donnée, elle, ne l'est pas.

Une fois ce modèle mental posé, le choix entre Named Volume, Bind Mount et tmpfs n'est plus une question de mémorisation — c'est une question de bon sens appliqué au bon contexte.

Je documente mon apprentissage du Cloud et du DevOps, avec un focus sur des projets réalistes plutôt que des tutoriels abstraits. Si ce genre de contenu t'intéresse, n'hésite pas à me suivre.

docker #devops #mysql #beginners #cloudcomputing #infrastructure #containerization #backend #learning #africatech

# J'ai réduit mon image Docker Flask de 445MB à 35MB — voici exactement comment

Roméo DOSsOu — Mon, 22 Jun 2026 17:19:28 +0000

Temps de lecture : 8 minutes — niveau débutant/intermédiaire

Il y a quelques semaines, je dockerise une petite API Flask. Deux routes, 80 lignes de code. Je lance docker build, j'attends, et quand je tape docker images — 445MB.

Quatre cent quarante-cinq mégaoctets. Pour une app qui tient dans un fichier.

Je me suis dit : quelque chose ne va pas. Et j'ai décidé de comprendre exactement d'où venait ce poids, et comment l'éliminer. Ce que j'ai trouvé a transformé ma façon d'écrire tous mes Dockerfiles depuis.

Voici la méthode complète, chiffres à l'appui.

Le point de départ : le Dockerfile "débutant"

Voici le Dockerfile que j'avais écrit — et que la majorité des tutoriels en ligne t'apprennent à écrire :

FROM python:3.11
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["python", "app.py"]

Propre. Lisible. Fonctionnel. Et catastrophiquement inutile en production.

Étape 1 : diagnostiquer avant de toucher quoi que ce soit

Avant d'optimiser, j'ai fait la radiographie. La commande docker history flask-fat affiche chaque couche de l'image avec son poids :

RUN pip install -r requirements.txt    111MB
COPY . .                               37kB
[ couches de python:3.11 ]             ~900MB

Le verdict est immédiat : mon code pèse 37 kilooctets. Le reste — 99% du poids — c'est l'infrastructure que j'avais choisie sans y réfléchir.

Optimisation 1 : le `.dockerignore` (quick win)

Première chose facile : empêcher Docker de copier des fichiers inutiles.

Sans .dockerignore, COPY . . embarque dans l'image : l'environnement virtuel Python local (.venv/ — souvent 200MB+), l'historique Git complet, les fichiers .env avec les mots de passe...

.venv/
__pycache__/
.git/
.env
.env.*

⚠️ Ce point dépasse la performance : un fichier .env dans une image publiée sur Docker Hub, c'est tes clés API exposées à tout le monde. C'est l'une des fuites de secrets les plus fréquentes en entreprise.

Gain : marginal sur ce projet, critique en sécurité.

Optimisation 2 : changer l'image de base (-88%)

C'est là que tout se joue. Il existe trois "tailles" d'images Python officielles :

Image	Ce qu'elle contient	Poids
`python:3.11`	Debian complet + Python + compilateurs + outils	~900MB
`python:3.11-slim`	Debian minimal + Python	~130MB
`python:3.11-alpine`	Alpine Linux + Python (rien d'autre)	~50MB

Un seul mot à changer dans le Dockerfile :

# Avant
FROM python:3.11

# Après
FROM python:3.11-alpine

Résultat : 445MB → 53MB. Un changement d'une ligne pour -88%.

Le piège à connaître : Alpine utilise une bibliothèque système différente de Debian (musl libc vs glibc). Certaines librairies Python avec des extensions C (psycopg2, Pillow, cryptography) nécessitent des outils de compilation supplémentaires sur Alpine :

RUN apk add --no-cache gcc musl-dev libffi-dev

Ce n'est pas compliqué — mais il faut le savoir avant de se retrouver avec des erreurs cryptiques.

Optimisation 3 : le multi-stage build

Même avec Alpine, si tu installes des outils de compilation pour certaines librairies, ils restent dans l'image finale. C'est là qu'entre le multi-stage build.

L'analogie que j'utilise : imagine une maison en construction. Les maçons arrivent avec échafaudages, bétonnières, perceuses. Quand la maison est prête, tu n'emménages pas avec tout ça — tu livres la maison propre.

# Stage 1 : on construit ici, avec tous les outils nécessaires
FROM python:3.11-alpine AS builder
RUN apk add --no-cache gcc musl-dev libffi-dev
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt

# Stage 2 : image de production, table rase
FROM python:3.11-alpine AS runner
WORKDIR /app
# On copie UNIQUEMENT les packages installés — pas gcc, pas musl-dev
COPY --from=builder /install /usr/local
COPY . .
EXPOSE 5000
CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

La ligne magique : COPY --from=builder /install /usr/local. Elle va chercher uniquement les packages Python compilés dans le stage précédent, sans les outils qui ont servi à les compiler.

Gain : 53MB → 45MB (modeste ici, mais 50-100MB sur des projets avec des dépendances C).

Optimisation 4 : épurer les dépendances

Mon requirements.txt de départ contenait pytest, black, ipython. Ces outils ne servent qu'au développement. En production, ils ne s'exécutent jamais — mais ils pèsent, et surtout ils représentent des surfaces d'attaque potentielles.

La solution : deux fichiers distincts.

requirements.txt (production) :

flask==3.0.0
gunicorn==21.2.0
Werkzeug==3.0.1

requirements-dev.txt (développement local) :

-r requirements.txt
pytest==7.4.0
black==23.9.1
ipython==8.16.1

Le -r requirements.txt dans le fichier dev signifie "installe d'abord les deps de prod". Un seul fichier à maintenir pour la prod, un seul pour le dev, et zéro duplication.

Gain : 45MB → 35MB.

Le bilan final

Technique	Avant	Après	Gain
`.dockerignore`	445MB	441MB	-1%
Image Alpine	441MB	53MB	-88%
Multi-stage build	53MB	45MB	-8%
Dépendances épurées	45MB	35MB	-8%
Total	445MB	35MB	-92%

Les 3 règles que j'applique maintenant sur chaque projet

1. Commencer par -alpine ou -slim par défaut, et ne revenir à l'image complète que si une dépendance l'exige vraiment.

2. Multi-stage build systématique dès qu'une dépendance nécessite compilation.

3. .dockerignore dans chaque projet dès le premier commit — pas quand on pense à l'optimisation, dès le début.

Ce que ça change concrètement

Déploiement plus rapide : 35MB à transférer au lieu de 445MB. Sur une connexion lente ou un budget bande passante limité (context africain : pertinent), c'est significatif.
Moins de CVEs : moins de packages = moins de surface d'attaque = moins de vulnérabilités détectées par les scanners de sécurité comme Trivy.
Coût réduit : sur AWS ECR, Docker Hub, ou tout registry cloud, le stockage et le transfert d'images se facturent au mégaoctet.

Pour aller plus loin

Le repo GitHub complet avec tous les Dockerfiles (naïf → optimisé) : https://github.com/Bordley/flask-docker-optimization.git
Le tutoriel complet étape par étape (niveau zéro débutant) : [TUTORIAL.md dans le repo]
Prochaine étape : scanner l'image avec Trivy pour mesurer la réduction des CVEs

Tu travailles sur un projet DevOps ou Cloud ? Je publie régulièrement des contenus techniques en français, avec un angle contexte africain (contraintes réseau, budget VPS, stack locale). Retrouve-moi sur [www.linkedin.com/in/roméo-dossou3777] et [Roméo Bordley Tech].

DEV Community: Roméo DOSsOu

Comment dockeriser une API FastAPI de A à Z — Dockerfile expliqué ligne par ligne

Introduction

Ce qu'on va construire

Étape 1 — L'API FastAPI

Structure du projet

database.py

models.py

schemas.py

main.py

requirements.txt

Étape 2 — Le piège du cache Docker

❌ L'erreur classique du débutant

✅ L'ordre correct

Étape 3 — Le Dockerfile, ligne par ligne

Étape 4 — Builder et observer le cache

Étape 5 — Lancer le conteneur

Étape 6 — Tester via Swagger UI

Résumé — Le Dockerfile complet commenté

Limites documentées

Conclusion

Dockeriser une API Flask de zéro sur Ubuntu : le guide complet pour ingénieurs africains

Dockeriser une API Flask de zéro sur Ubuntu : le guide complet

Ce qu'on va construire

Prérequis

Étape 1 — Installer Docker sur Ubuntu

Étape 2 — Cloner et analyser le projet Flask

Étape 3 — Écrire le Dockerfile

Pourquoi cet ordre précis ?

Pourquoi Gunicorn ?

Pourquoi 0.0.0.0 ?

Étape 4 — Créer le .dockerignore

Étape 5 — Builder l'image

Étape 6 — Lancer le container et tester

Étape 7 — Sécuriser avec les variables d'environnement

Étape 8 — Publier sur Docker Hub

Ce que ce projet t'a appris

Pour aller plus loin

Conclusion

Docker Compose en production : les 5 erreurs que personne ne te dit

Docker Compose en production : les 5 erreurs que personne ne te dit

Le fichier qui a l'air correct — mais qui contient 5 bombes

💣 Erreur #1 — Le health check qui ment

Le symptôme

La cause racine

La correction

💣 Erreur #2 — Les volumes qui font disparaître les données

Le symptôme

La cause racine

La correction

💣 Erreur #3 — Les secrets exposés

Le symptôme (découvert 48h plus tard)

Les 3 vecteurs d'exposition

La correction

💣 Erreur #4 — Nginx qui dégrade silencieusement

Les 4 symptômes

La configuration production-ready

💣 Erreur #5 — Le crash silencieux

Le symptôme

La correction en 2 parties

La checklist — à garder ouverte à chaque déploiement

Conclusion

Comment travailler en équipe avec Git — Workflow complet pour débutants

Le contexte

Phase 1 — Poser les fondations

Phase 2 — Alice travaille sur l'authentification

Créer une branche, c'est créer un espace de travail isolé

Des commits atomiques, pas un gros commit fourre-tout

Une décision sécurité intentionnelle

Phase 3 — Bob travaille en parallèle

L'isolation des branches en pratique

Ne jamais exposer les données sensibles

Phase 4 — Pull Requests et code review

Ce qu'une bonne PR contient

Bob trouve une faille critique

Phase 5 — Le conflit (ne pas paniquer)

Comprendre les marqueurs de conflit

La résolution intelligente

Pourquoi --force-with-lease et pas --force ?

Rebase vs Merge — le débat tranché

`database.py`

`models.py`

`schemas.py`

`main.py`

`requirements.txt`

Pourquoi `0.0.0.0` ?

Pourquoi `--force-with-lease` et pas `--force` ?

Erreur n°3 : pas de `.dockerignore`

Optimisation 1 : le `.dockerignore` (quick win)