DevOps

Docker en production : les bonnes pratiques

15 mars 2026
8 min de lecture
Synthèse de veille

Comment éviter les erreurs classiques avec Docker en production : multi-stage builds, gestion des secrets, monitoring et logs.

Docker est devenu un standard du déploiement applicatif moderne. Mais son utilisation en production demande une vraie rigueur.

Voici une synthèse des bonnes pratiques que j'applique pour mes projets, notamment ce portfolio.

01Multi-stage builds

Le multi-stage build permet de séparer les étapes : installation des dépendances, compilation, runtime. L'image finale ne contient que ce qui est nécessaire à l'exécution.

Bénéfices : taille de l'image réduite, surface d'attaque diminuée, build plus rapide grâce au cache.

dockerfile
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM node:18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:18-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next/standalone ./
EXPOSE 3000
CMD ["node", "server.js"]

02Gestion des secrets

Ne jamais hardcoder de secrets dans les Dockerfile ou les images. Utiliser Docker secrets, des variables d'environnement injectées au runtime, ou des solutions externes comme Vault.

Erreur classique
Mettre un mot de passe dans une variable ENV au build est une mauvaise idée : il sera visible dans l'historique des layers de l'image, même si supprimé ensuite.

03Healthchecks et logs

Configurer un healthcheck sur chaque conteneur permet à l'orchestrateur de redémarrer un service défaillant. Centraliser les logs (driver json-file ou solution dédiée comme Loki) facilite le debug.

Points clés à retenir

  • 01Toujours utiliser des images officielles ou auditées
  • 02Privilégier les multi-stage builds pour optimiser les images
  • 03Ne jamais hardcoder de secrets dans les Dockerfile
  • 04Configurer des healthchecks pour chaque service
  • 05Limiter les capacités du conteneur avec --cap-drop

Sources consultées