DEV Community: Roméo DOSsOu

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

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

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

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

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

Erreur n°3 : pas de .dockerignore

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

Erreur n°5 : tourner en root

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

Le bilan complet

Ce que j'en retiens

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

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)

Pourquoi Docker "oublie" tout par défaut

Les 3 solutions, et quand utiliser laquelle

1. Named Volume — pour les données critiques

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

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

Le tableau de décision

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

La stack finale

Ce que j'en retiens

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

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

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

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

Optimisation 1 : le .dockerignore (quick win)

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

Optimisation 3 : le multi-stage build

Optimisation 4 : épurer les dépendances

Le bilan final

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

Ce que ça change concrètement

Pour aller plus loin

Erreur n°3 : pas de `.dockerignore`

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