Bonnes pratiques Docker pour projets web

Docker bien utilisé accélère une équipe web. Docker mal cadré produit des images de 2 Go, des secrets dans l’historique, des conteneurs zombies et des dimanches de debug. Ce guide regroupe des bonnes pratiques concrètes : images légères, .dockerignore, secrets, santé des conteneurs, pièges de prod — pour des projets web (Node, front statique, stacks Compose).

1. Traiter l’image comme un artefact de release

• Taggez de façon explicite : api:1.6.2, éventuellement digest en prod.
• Évitez latest comme seule référence déployée.
• Construisez en CI, pas seulement sur le laptop d’un lead.
• Gardez le Dockerfile sous Git, revu comme du code.

Une image n’est pas un dossier magique : c’est ce que vous déployez. La discipline de versioning évite le « on ne sait plus ce qu’il y a en prod ».

Pour ancrer ces réflexes dans une formation web, Academy Yunt reste un cadre plus sûr que la collecte de snippets au fil des incidents.

2. Alléger les images sans fetish

Bases raisonnables

• *-slim ou distroless quand c’est compatible ;
• Alpine si l’écosystème natif le permet, sinon slim Debian pour Node ;
• multi-stage : outils de build absents du runtime.

Dépendances

• npm ci --omit=dev (ou équivalent) en stage final ;
• pas de caches package laissés traîner (rm -rf /var/lib/apt/lists/* après apt) ;
• un seul process métier principal par conteneur.

Mesurer

3. .dockerignore : non négociable

Exemple pour une API Node :

node_modules
.git
.env
.env.*
!.env.example
coverage
dist
npm-debug.log
Dockerfile*
README.md
.vscode

Sans ce fichier, le contexte de build gonfle, le cache devient imprévisible, et un .env local peut finir dans une layer. C’est l’une des corrections les plus rentables d’un projet.

4. Secrets : jamais dans les layers

À éviter :

• ENV DATABASE_PASSWORD=... dans le Dockerfile de prod ;
• COPY .env . ;
• arguments de build ARG contenant des tokens (visibles dans l’historique).

Préférer :

• variables injectées au runtime (Compose, orchestrateur, platform secrets) ;
• fichiers secrets montés en lecture seule ;
• rotation possible sans rebuild.

En local, .env gitignoré + .env.example suffisent souvent. En prod, un gestionnaire de secrets digne de ce nom.

5. Utilisateur non-root et filesystem

USER node

6. Healthchecks et démarrage ordonné

Une route /health (liveness) et éventuellement /ready (dépendance DB OK) simplifient Compose et les load balancers.

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD node -e "fetch('http://127.0.0.1:3000/health').then(r=>process.exit(r.ok?0:1)).catch(()=>process.exit(1))"

(Adaptez selon l’image ; parfois curl/wget absents — d’où un petit check Node ou un binary dédié.)

Dans Compose : depends_on + condition: service_healthy.

7. Logs et observabilité

• stdout/stderr uniquement (drivers Docker / plateforme) ;
• pas de logs critiques uniquement dans /var/log du conteneur jetable ;
• corrélation request-id si l’API est servie derrière un proxy ;
• métriques et traces : selon la maturité, mais au minimum des logs structurés.

Quand la prod « marche mais c’est lent », Docker n’est qu’une couche : un audit perf applicative complète le diagnostic conteneur.

8. Réseau et surface d’attaque

• n’exposez que les ports nécessaires ;
• base de données souvent sans publication publique en prod ;
• séparez réseaux front et back si l’orchestrateur le permet ;
• mettez à jour régulièrement les images de base (CVE) ;
• scannez de temps en temps (docker scout, Trivy, etc. selon votre chaîne).

9. Dev vs prod : deux profils assumés

Local : volumes de code, npm run dev, outils (mailpit, adminer) en profiles.
Prod : image immuable, pas de bind m

Les livraisons soignées côté Agency Yunt séparent clairement ces modes pour que le client ne hérite pas d’un Compose de demo en production.

10. CI : build, test, push

Pipeline type :

1. checkout ;
2. docker build (cache layers) ;
3. tests (unitaires hors Docker ou compose d’intégration) ;
4. scan basique ;
5. push registry avec tag commit/semver ;
6. déploiement qui tire ce tag précis.

Évitez de builder à la main sur le serveur de prod (git pull && docker build sans traçabilité).

Cas concret : checklist avant mise en staging

• .dockerignore présent et testé
• multi-stage si build front/back
• user non-root
• secrets absents de l’image
• tag semver poussé
• /health OK derrière le proxy
• Postgres non exposé publiquement
• compose/chart de staging sans volumes de code
• rollback possible (tag précédent)

Si trois cases manquent, ce n’est pas « de la dette acceptable », c’est un incident en puissance.

Erreurs fréquentes (et correctifs

« Ça marche en local Compose, pas en prod »

Cause : env manquantes, hostname localhost, volumes absents, CPU/RAM plus bas. Correctif : parité des variables, readiness, ressources documentées.

Conteneur qui restart en boucle

Cause : crash au boot (migration, conf). Correctif : docker logs, exit codes, ne pas masquer avec des restart policies agressives sans alerte.

Docker.sock monté dans l’app

Cause : « besoin de lancer des conteneurs ». Risque : clé de la machine. Correctif : architecture différente, DinD contrôlé, ou API d’infra dédiée.

Dérive de configuration

Cause : changements manuels dans un conteneur vivant. Correctif : cattle — rebuild/redeploy, pas docker exec permanent comme mode de config.

Bonnes pratiques Compose associées

• Projet nommé clairement (-p) en multi-stacks.
• Volumes nommés pour les données, backups pensés hors Docker uniquement.
• Documentation onboarding en trois commandes.
• Profiles pour outils optionnels.
• Healthchecks sur db et api.

L’écosystème Yunt relie ces détails d’ingénierie à la formation et à la qualité produit : Docker n’est pas un îlot.

Pièges spécifiques prod web

• caches front mal hashés derrière un volume Nginx mal monté ;
• uploads utilisateurs stockés **dan

Revue d’équipe : cinq questions avant merge d’un Dockerfile

Avant d’accepter une PR qui touche Docker, posez-vous :

1. Le cache des dépendances survit-il à un changement de code source seul ?
2. Un secret peut-il apparaître dans docker history ?
3. Qui exécute le process (root ou non) ?
4. Que se passe-t-il si le conteneur est tué puis recréé (données, migrations) ?
5. Le tag publié permet-il un rollback en une commande ?

Ces questions forment une revue courte et efficace. Elles évitent les débats esthétiques (« Alpine ou pas ») sans regarder les risques réels.

Aller plus loin

Reprenez Dockerfile multi-stage, Compose de stack locale, puis ajoutez scan CVE et politique de rebuild mensuelle des bases. La sécurité des conteneurs est un continuum, pas un checkbox unique.

Pour progresser avec méthode, Academy Yunt. Pour une mise en œuvre sur projet client, agency.yunt.fr. Pour un état des lieux site déjà en ligne, audit.yunt.fr.

FAQ

Faut-il HEALTHCHECK dans chaque Dockerfile ?

Utile souvent, parfois géré plutôt par l’orchestrateur. L’important est d’avoir un endpoint de santé fiable.

Alpine est-il toujours plus sûr ?

Plus petit ≠ automatiquement plus sûr. La fraîcheur des patches et la surface réelle comptent davantage.

Quelle fréquence de rebuild des images de base ?

Dès qu’une CVE critique touche votre stack, et périodiquement (mensuel) pour rester à jour. Automatisez si possible.

Distroless, ça vaut le coup ?

Excellent pour réduire la surface si votre process est un binaire/Node autonome et que vous acceptez un debug plus exigeant.

Comment gérer plusieurs environnements ?

Même image, variables différentes. Évitez trois Dockerfiles quasi identiques « dev/staging/prod » sauf besoin réel.

Conclusion

Les bonnes pratiques Docker pour le web tiennent en quelques principes : images petites et versionnées, secrets hors layers, utilisateur non-root, santé observable, séparation dev/prod, CI traçable, données hors conteneur jetable. Le reste est de la discipline d’équipe.

Appliquez d’abord .dockerignore, multi-stage et tags semver. Puis healthchecks et politique de secrets. Vous éliminerez déjà la majorité des incidents « conteneur » du quotidien.

Pour faire de ces gestes une compétence solide plutôt qu’une checklist oubliée, poursuivez avec Academy Yunt.

Où stocker les uploads ?

Object storage (S3/MinIO) de préférence. Volume persistant si contrainte, avec backup. s** le conteneur (perdus au redeploy) — utiliser object storage ou volume backupé ;

• jobs cron dans le même conteneur web sans stratégie de leader (doublons multi-replicas) ;
• timeouts reverse proxy plus courts que les uploads longs ;
• horloges / timezones : préférez UTC dans les conteneurs. )

Images monstrueuses

Cause : stage unique, COPY . . trop tôt, caches apt. Correctif : multi-stage + dockerignore + ordre des layers. ount du source, NODE_ENV=production, ressources limitées (mem_limit / requests-limits).

Mélanger les deux dans un seul fichier sans override, c’est inviter l’accident.

Ou utilisateur dédié créé dans l’image. Montez les volumes avec des permissions cohérentes. Évitez privileged: true « pour que ça marche ». Si un besoin kernel apparaît, documentez-le comme exception, pas comme défaut.

docker images mon-api

Suivez la taille dans le temps. Une régression +300 Mo mérite une explication (souvent un COPY . . trop large ou un stage unique).