Top 5 des Erreurs Docker qui Crashent vos Conteneurs en Prod

Vos conteneurs Docker plantent en production sans prévenir ? Dans la majorité des cas, le problème ne vient pas de Docker mais d’une poignée d’erreurs de configuration que l’on retrouve partout. Voici les 5 plus coûteuses, et surtout comment les corriger.

Sommaire

1. Pourquoi Docker plante en production
2. Erreur n°1 – Faire tourner vos conteneurs en root
3. Erreur n°2 – Construire des images obèses sans multi-stage
4. Erreur n°3 – Stocker secrets et données dans l’image
5. Erreur n°4 – Oublier les health checks et les limites de ressources
6. Erreur n°5 – Naviguer sans logs ni monitoring
7. La checklist Docker production
8. Conclusion
9. FAQ Docker en production

Aujourd’hui, Docker reste l’outil de conteneurisation le plus déployé au monde, et ces cinq erreurs font partie des causes les plus fréquentes d’incidents Docker observées en production par les équipes DevOps en Suisse romande. Ces erreurs ne sont pas des bugs Docker. Ce sont des choix de configuration faits trop vite, souvent en développement, et qui se retournent contre vous le jour où le trafic monte ou qu’un attaquant cherche une faille.

En production, un conteneur qui redémarre en boucle, une image qui pèse 2 Go inutiles ou un secret committé dans un Dockerfile coûtent du temps, de l’argent et parfois la confiance des clients. La bonne nouvelle, c’est que toutes ces erreurs sont évitables avec un peu de méthode et les bons réflexes. Encore faut-il savoir lesquelles.

Pourquoi Docker plante en production

D’abord, un conteneur n’est pas une machine virtuelle. C’est un processus isolé qui partage le noyau de l’hôte. Par conséquent, toute mauvaise configuration se répercute directement sur le serveur. De plus, contrairement au développement où vous redémarrez sans conséquence, la production ne pardonne pas la moindre négligence.

Selon une étude Snyk de 2024, plus de 60% des images Docker scannées contiennent au moins une vulnérabilité critique. En somme, l’écart entre un environnement Docker robuste et un environnement fragile tient souvent à cinq décisions clés.

Les trois symptômes qui doivent vous alerter

• Conteneurs en boucle de redémarrage : généralement un problème de health check, de variable d’environnement manquante ou de permissions.
• Consommation mémoire qui grimpe sans raison : absence de limites --memory et --cpus, fuite mémoire ou logs non rotés.
• Latence qui explose en pic de trafic : image trop volumineuse au démarrage, base de données partageant le réseau Docker par défaut, absence d’orchestration.

Bien entendu, ces symptômes ne sont que la partie visible. Toutefois, en production, ce sont eux qui réveillent vos équipes à 3h du matin. Voyons les cinq erreurs qui les provoquent.

Erreur n°1 – Faire tourner vos conteneurs en root

Par défaut, un conteneur Docker s’exécute en utilisateur root. C’est pratique en développement, mais c’est une faille de sécurité majeure en production. Si un attaquant compromet votre application, il dispose immédiatement des droits root sur le conteneur. De plus, dans certaines configurations, il peut s’évader vers l’hôte.

Le scénario typique d’attaque

Un développeur publie une image basée sur node:18. Ainsi, l’image hérite de l’utilisateur root. En production, l’application Node expose une faille SSRF. Toutefois, l’attaquant exécute aussitôt une commande arbitraire dans le conteneur. Comme il est root, il peut modifier des fichiers, installer des outils, voire abuser d’un volume mal configuré pour atteindre le système hôte.

Comment corriger l’erreur

Toutefois, la correction est simple. En pratique, il suffit d’ajouter un utilisateur dédié dans votre Dockerfile. Ensuite, il faut basculer dessus avant la commande de démarrage.

• Créer un utilisateur applicatif : RUN addgroup --system app && adduser --system --ingroup app app
• Basculer dessus : USER app juste avant CMD ou ENTRYPOINT.
• Vérifier en runtime : docker exec mon-conteneur whoami doit afficher autre chose que root.

Par ailleurs, pensez à utiliser le flag --read-only pour rendre le système de fichiers du conteneur immuable. En conséquence, même un attaquant root sur le conteneur ne pourra pas écrire de fichiers persistants. C’est une bonne pratique imposée par la CIS Docker Benchmark, référence en sécurité conteneurs.

Erreur n°2 – Construire des images obèses sans multi-stage

En premier lieu, une image Docker de 2 Go pour une application qui en fait 50 Mo reste l’erreur la plus visible et la plus courante. Elle ralentit chaque déploiement, gonfle votre facture de stockage et augmente la surface d’attaque. En particulier, plus une image contient de paquets, plus elle contient de vulnérabilités potentielles.

Les trois causes principales du surpoids

1. Image de base trop riche : ubuntu:latest pèse 80 Mo, alpine:3.19 seulement 7 Mo, distroless 2 Mo.
2. Outils de build laissés dans l’image finale : compilateurs, gestionnaires de paquets, fichiers temporaires.
3. Couches non optimisées : chaque RUN crée une couche, et un RUN apt-get install mal écrit peut doubler la taille.

La solution : le multi-stage build

Par conséquent, le pattern multi-stage permet de compiler dans une image lourde puis de copier uniquement le binaire final dans une image minimale. Autrement dit, vous gardez le confort du build complet et la légèreté du runtime.

Par exemple, voici un Dockerfile pour une application Go :

• Stage 1 (builder) : FROM golang:1.22 AS builder, copie des sources, go build.
• Stage 2 (runtime) : FROM gcr.io/distroless/static, COPY --from=builder /app/bin /app.
• Résultat : image finale de 15 Mo au lieu de 800 Mo.

De ce fait, le déploiement passe de 45 secondes à 3 secondes, et la surface d’attaque chute drastiquement. Pour aller plus loin, lisez la documentation officielle Docker sur les best practices de build, qui détaille les patterns avancés.

Erreur n°3 – Stocker secrets et données dans l’image

Par exemple, mettre un mot de passe de base de données dans un Dockerfile ou une variable d’environnement passée au démarrage paraît anodin. En réalité, c’est l’une des fuites les plus fréquentes que Snyk identifie chaque année dans les images publiques. De plus, une fois committé dans une couche, un secret y reste même si vous le supprimez plus tard.

Pourquoi les variables d’environnement ne suffisent pas

Les variables passées via docker run -e DB_PASS=... ou un fichier .env apparaissent en clair à plusieurs endroits. Par exemple, docker inspect les expose, et tout processus du conteneur peut les lire dans /proc/1/environ. En somme, ce n’est pas du secret, c’est de la configuration en clair.

Les trois solutions à privilégier

• Docker Secrets (Swarm) : injecte les secrets en mémoire dans /run/secrets/, jamais sur le disque.
• HashiCorp Vault ou AWS Secrets Manager : récupération à l’exécution via une API authentifiée, rotation automatique.
• BuildKit secret mounts : RUN --mount=type=secret pendant le build, sans persister la valeur dans la couche finale.

Par ailleurs, ne committez jamais de fichier .env dans Git. Configurez un pre-commit hook avec Gitleaks pour bloquer toute fuite. C’est une pratique courante dans les équipes DevOps suisses qui gèrent du pipeline CI/CD critique.

Le cas particulier des données utilisateur

De plus, ne stockez jamais de données dans le conteneur lui-même. Utilisez systématiquement des volumes persistants. Toutefois, attention aux volumes mal configurés. Un volume monté sans permissions correctes peut écraser des fichiers système. Pire, il peut permettre une évasion vers l’hôte. Testez toujours avec docker volume inspect avant de partir en production.

Erreur n°4 – Oublier les health checks et les limites de ressources

Un conteneur qui tourne n’est pas un conteneur qui fonctionne. C’est la nuance que beaucoup d’équipes apprennent dans la douleur. Ainsi, sans HEALTHCHECK dans votre Dockerfile, Docker ne sait pas si votre application répond réellement aux requêtes. De ce fait, l’orchestrateur continue d’envoyer du trafic vers un conteneur zombie.

Anatomie d’un health check propre

Par exemple, voici un health check typique pour une API HTTP :

• HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3
• CMD curl -fsS http://localhost:8080/health || exit 1

Ensuite, l’orchestrateur (Docker Swarm, Kubernetes ou Nomad) peut alors redémarrer automatiquement le conteneur s’il échoue. En particulier, start-period évite les faux positifs au démarrage des applications lourdes (Java, .NET).

Les limites de ressources : votre garde-fou contre les voisins

Sans limites, un conteneur qui fuit consomme toute la RAM de l’hôte. Les autres conteneurs tombent alors avec lui. C’est ce qu’on appelle le noisy neighbor effect. Pour l’éviter, configurez systématiquement :

• Mémoire : --memory=512m --memory-swap=512m pour empêcher tout débordement.
• CPU : --cpus=1.5 pour plafonner l’usage processeur.
• PIDs : --pids-limit=200 pour éviter les fork bombs.
• Logs : --log-opt max-size=10m --log-opt max-file=3 pour éviter de remplir le disque.

Bien entendu, ces valeurs dépendent de votre charge réelle. Mesurez d’abord avec docker stats en charge nominale. Ensuite, ajoutez 30% de marge de sécurité. C’est la méthode recommandée par les guides DevOps de référence comme Stéphane Robert.

Erreur n°5 – Naviguer sans logs ni monitoring

Pour finir, le dernier piège est sans doute le plus sous-estimé. En pratique, beaucoup d’équipes mettent Docker en production sans monitoring centralisé, en s’appuyant sur docker logs à la demande. Bien entendu, c’est jouable pour un seul conteneur. C’est ingérable dès qu’il y en a dix.

La pile minimale recommandée

Pour une production sereine, trois briques complémentaires deviennent indispensables :

1. Logs centralisés : Grafana Loki, ELK ou un service managé comme Datadog. Configurez Docker pour pousser via le driver json-file avec rotation, puis Promtail ou Filebeat pour l’agrégation.
2. Métriques : Prometheus + cAdvisor exposent CPU, RAM, I/O par conteneur. Grafana affiche les dashboards.
3. Alerting : Alertmanager ou PagerDuty avec des seuils sur les health checks failed, restart count et OOM kills.

Les trois métriques à surveiller en priorité

• Restart count : un conteneur qui redémarre plus de 3 fois par heure indique un problème non résolu.
• Memory usage trend : une courbe qui monte sans redescendre signale une fuite mémoire.
• Latence p95 et p99 : ces percentiles révèlent les ralentissements que la moyenne cache.

Par ailleurs, pensez à activer les events Docker via docker events. Ces logs détaillent chaque action sur le démon (start, stop, kill, OOM) et sont précieux pour comprendre un incident a posteriori. Couplés à un SIEM, ils permettent aussi de détecter des comportements anormaux.

La checklist Docker production

Pour finir, voici la checklist condensée à intégrer à votre pipeline de déploiement avant chaque mise en production. Si l’une des cases reste vide, vous avez un risque non maîtrisé sur les bras.

Cette checklist couvre les principaux risques Docker que l’on retrouve régulièrement dans les environnements de production des équipes que nous formons. Elle ne remplace pas une revue de code ni un audit de sécurité, mais elle vous évite les erreurs les plus coûteuses.

Conclusion

Docker n’est ni complexe ni capricieux. En revanche, il ne pardonne pas les raccourcis pris en production. Les cinq erreurs que nous venons de voir représentent l’écrasante majorité des incidents Docker en production. Conteneurs en root, images obèses, secrets exposés, absence de health checks et monitoring négligé : voilà le quotidien des équipes DevOps suisses.

Corriger ces cinq points reste à la portée d’une équipe organisée et le retour sur investissement est rapide. Vos déploiements deviennent plus rapides, votre infrastructure plus stable et votre surface d’attaque diminue nettement. Par conséquent, la prochaine fois qu’un conteneur plante en production, posez-vous la question : laquelle de ces cinq erreurs avons-nous laissée passer ?

Pour aller plus loin, complétez votre maîtrise avec un parcours structuré. Il couvre Docker, Kubernetes et l’orchestration cloud-native. C’est exactement ce que proposent nos formations DevOps à Genève et Lausanne, conçues pour des équipes qui livrent en production réelle.

FAQ Docker en production

Quelle est la principale cause de plantage des conteneurs Docker en production ?
Dans la majorité des cas, c’est l’absence de health check combinée à une absence de limites de ressources. Le conteneur tombe sans qu’aucun garde-fou ne le redémarre, ou il consomme toute la RAM de l’hôte et fait chuter les autres services.

Faut-il vraiment éviter d’utiliser root dans un conteneur Docker en production ?
Oui, sans exception. En effet, tourner en root augmente massivement l’impact d’une compromission. Un simple USER app dans le Dockerfile suffit à neutraliser la majorité des techniques d’évasion de conteneur connues.

Comment réduire la taille d’une image Docker en production ?
Utilisez le multi-stage build pour séparer la phase de compilation du runtime, choisissez une image de base minimale comme Alpine ou distroless, et regroupez vos commandes RUN pour limiter le nombre de couches.

Quels outils utiliser pour monitorer Docker en production ?
En pratique, la pile standard combine Prometheus + cAdvisor pour les métriques, Grafana pour la visualisation, et Loki ou ELK pour les logs. Pour les équipes qui veulent du managé, Datadog ou New Relic couvrent les trois besoins en une seule offre.

Docker est-il adapté pour des charges critiques en production ?
Oui, à condition d’utiliser un orchestrateur comme Kubernetes ou Docker Swarm en complément, et de respecter les bonnes pratiques de sécurité, monitoring et limites de ressources. Sans orchestrateur, un Docker isolé reste une solution viable pour des charges non critiques uniquement.