🐳 Docker en Production : Les 10 Erreurs Fatales et Comment les Éviter

📚 Prérequis

• Connaissances de base de Docker (images, conteneurs, volumes)
• Familiarité avec la ligne de commande Linux
• Accès administrateur à un serveur Linux

---

Docker a révolutionné le déploiement d’applications, mais son apparente simplicité cache de nombreux pièges en production. Après des années à déployer et maintenir des infrastructures Docker, voici les 10 erreurs les plus courantes que nous observons — et surtout, comment les éviter.

---

❌ Erreur #1 : Ne Pas Configurer la Rotation des Logs

Le problème : Par défaut, Docker stocke les logs des conteneurs sans aucune limite. Un conteneur bavard peut facilement générer des gigaoctets de logs et saturer votre disque en quelques jours.

La solution : Configurez le driver de logs avec une rotation automatique dans /etc/docker/daemon.json :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Cette configuration limite chaque fichier de log à 10 Mo et conserve les 3 derniers fichiers. Simple, mais ça peut vous sauver d’une nuit blanche.

❌ Erreur #2 : Ignorer le Live Restore

Le problème : Par défaut, redémarrer le daemon Docker (mise à jour, configuration) arrête tous vos conteneurs. En production, c’est catastrophique.

La solution : Activez le Live Restore :

{
  "live-restore": true
}

Avec cette option, vos conteneurs continuent de tourner même pendant un redémarrage du daemon. C’est la différence entre un upgrade transparent et une interruption de service.

❌ Erreur #3 : Laisser les Données Docker sur /var

Le problème : Docker stocke tout dans /var/lib/docker par défaut. Si votre partition root est limitée (souvent le cas sur des VMs cloud), vous allez rapidement manquer d’espace.

La solution : Déplacez le répertoire de données vers un volume dédié :

{
  "data-root": "/mnt/docker-data"
}

Conseil bonus : Utilisez un SSD pour ce volume. Les performances I/O de Docker en dépendent fortement.

❌ Erreur #4 : Ne Pas Nettoyer les Ressources Orphelines

Le problème : À chaque build, pull ou suppression de conteneur, Docker accumule des couches d’images, des volumes orphelins et des réseaux inutilisés. Après quelques mois, des dizaines de Go peuvent être gaspillés.

La solution : Mettez en place un nettoyage automatique via cron :

# Crontab - Nettoyage quotidien à 3h du matin
0 3 * * * docker system prune --all --force --filter 'until=24h'

Cette commande supprime les images non utilisées depuis 24h, les conteneurs arrêtés et les réseaux orphelins.

❌ Erreur #5 : Exécuter les Conteneurs en Root

Le problème : Par défaut, les conteneurs s’exécutent avec l’utilisateur root. En cas de vulnérabilité dans votre application, l’attaquant a les pleins pouvoirs.

La solution : Spécifiez un utilisateur non-root dans vos Dockerfiles :

FROM node:20-alpine
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
WORKDIR /app
COPY --chown=appuser:appgroup . .

C’est une pratique de sécurité fondamentale trop souvent négligée.

❌ Erreur #6 : Utiliser :latest en Production

Le problème : Le tag :latest change à chaque nouveau push. Vous n’avez aucune garantie de reproductibilité et un simple docker pull peut casser votre environnement.

La solution : Utilisez toujours des tags versionnés explicites :

# ❌ Mauvais
image: nginx:latest

# ✅ Bon
image: nginx:1.25.3-alpine

Encore mieux : utilisez le digest SHA256 pour une reproductibilité totale.

❌ Erreur #7 : Négliger les Health Checks

Le problème : Un conteneur peut être « running » selon Docker mais complètement planté en interne (application bloquée, connexion DB perdue, etc.).

La solution : Définissez des health checks dans votre Compose ou vos orchestrateurs :

services:
  api:
    image: mon-api:1.0.0
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Docker marquera le conteneur comme « unhealthy » dès que le check échouera, permettant aux orchestrateurs de le redémarrer.

❌ Erreur #8 : Exposer le Socket Docker Sans Protection

Le problème : Certains outils (Portainer, Traefik, agents CI) nécessitent un accès au socket Docker. Mais donner accès à /var/run/docker.sock, c’est donner les clés du royaume.

La solution : Si vous devez exposer le socket :

• Utilisez un proxy comme docker-socket-proxy qui limite les appels API autorisés
• Montez le socket en read-only quand c’est suffisant
• Évitez absolument d’exposer le socket sur le réseau (port 2375/2376)

❌ Erreur #9 : Oublier les Métriques et le Monitoring

Le problème : Vous ne pouvez pas améliorer ce que vous ne mesurez pas. Sans métriques, vous ne saurez pas que vos conteneurs sont en stress mémoire avant qu’ils ne crashent.

La solution : Activez les métriques Prometheus du daemon Docker :

{
  "metrics-addr": "127.0.0.1:9323",
  "experimental": true
}

Combinez avec cAdvisor pour des métriques détaillées par conteneur (CPU, mémoire, I/O, réseau).

❌ Erreur #10 : Configuration Manuelle sur Chaque Serveur

Le problème : Copier-coller des configurations daemon.json sur chaque serveur, c’est :

• Source d’erreurs et d’incohérences
• Impossible à auditer
• Un cauchemar à maintenir à grande échelle

La solution : Automatisez avec un outil de configuration management comme Ansible. Un rôle bien conçu peut :

• Installer Docker avec les bons dépôts
• Configurer le daemon.json intelligemment (fusion, pas écrasement)
• Mettre en place la rotation des logs, le nettoyage cron, les métriques
• Gérer les utilisateurs et les proxys
• Être testé et validé avec Molecule

---

🚀 Conclusion : L’Automatisation Comme Solution

Chacune de ces erreurs est évitable, mais les gérer manuellement sur une flotte de serveurs devient vite ingérable. C’est pourquoi nous avons développé un rôle Ansible complet qui applique toutes ces bonnes pratiques automatiquement.

Notre rôle docker_engine gère :

• ✅ Rotation des logs configurée par défaut
• ✅ Live Restore activé
• ✅ Data-root personnalisable
• ✅ Cron de nettoyage automatique
• ✅ Métriques Prometheus prêtes à l’emploi
• ✅ Gestion des proxys via systemd drop-in
• ✅ Tests Molecule sur Debian 12/13 et Ubuntu 22.04/24.04

Prêt à industrialiser vos déploiements Docker ? Découvrez notre rôle Ansible docker_engine et passez à la vitesse supérieure.

---

📖 Glossaire

• daemon.json : Fichier de configuration principal du daemon Docker, situé dans /etc/docker/
• Live Restore : Fonctionnalité Docker permettant aux conteneurs de continuer à tourner pendant un redémarrage du daemon
• Health Check : Commande exécutée périodiquement pour vérifier qu’un conteneur fonctionne correctement
• Docker Socket : Interface Unix (/var/run/docker.sock) permettant de communiquer avec le daemon Docker
• Prometheus : Système de monitoring open-source spécialisé dans la collecte de métriques
• cAdvisor : Outil Google qui collecte les métriques de ressources des conteneurs
• Molecule : Framework de test pour les rôles Ansible

Cet article vous a été utile ? Partagez-le avec votre équipe et restez connectés pour notre prochain article sur la mise en place d’une stack d’observabilité complète avec Prometheus, Grafana et Loki.