Déployer un nouvel hôte Docker dans son home lab ou en production est une étape rapide et gratifiante. Pourtant, laisser Docker tourner avec ses configurations d’usine est le meilleur moyen de s’exposer à des pannes silencieuses quelques mois plus tard. Disque système saturé par les logs, plantage complet de l’OS ou conteneurs exposés sans protection : les pièges par défaut sont nombreux.
Pour éviter ces désagréments, voici un retour d’expérience précieux basé sur les 6 configurations incontournables à appliquer sur chaque nouvel hôte Docker.
1. Optimiser la configuration du démon (daemon.json)
Par défaut, Docker centralise ses données dans /var/lib/docker et écrit ses logs conteneurs au format JSON sans aucune limite de taille. Si votre système d’exploitation tourne sur un petit SSD ou une carte SD (comme sur un Raspberry Pi), c’est la panne assurée lorsque le disque sature.
La bonne pratique consiste à regrouper ces optimisations globales au sein du fichier /etc/docker/daemon.json pour accomplir deux actions indispensables en une seule fois :
- Déplacer le stockage (
data-root) vers un disque secondaire ou une partition dédiée (par exemple montée sous/docker-storage). - Activer la rotation des logs (
log-opts) pour limiter la taille de chaque fichier à 10 Mo et conserver un maximum de 5 fichiers de rotation.
Créez ou modifiez le fichier /etc/docker/daemon.json :
{
"data-root": "/docker-storage",
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "5"
}
}
Appliquez les changements en redémarrant le service Docker :
sudo systemctl restart docker
[!NOTE] Si vous préférez gérer cette restriction au cas par cas, vous pouvez également spécifier ces options de logs directement dans vos fichiers
docker-compose.yml:logging: driver: json-file options: max-size: "10m" max-file: "5"
2. Gérer Docker sans les privilèges root (le groupe docker)
Par défaut, l’accès au socket Unix de Docker (/var/run/docker.sock) est réservé à l’utilisateur root. Devoir saisir sudo à chaque commande docker ou docker compose est fastidieux et augmente le risque d’exécuter des scripts ou commandes avec trop de privilèges.
Pour utiliser Docker en toute sécurité avec votre utilisateur standard, ajoutez ce dernier au groupe système docker :
sudo usermod -aG docker $USER
Pour appliquer ce changement immédiatement à votre terminal actif sans avoir à fermer et rouvrir votre session SSH :
newgrp docker
Vous pouvez maintenant exécuter vos commandes directement :
docker ps
3. Sécuriser l’exposition des ports (Liaison à 127.0.0.1)
C’est l’un des pièges les plus célèbres sous Linux : Docker contourne le pare-feu UFW par défaut. Lorsque vous exposez un port avec -p 8080:80, Docker insère ses propres règles iptables avant celles d’UFW. Votre conteneur se retrouve exposé directement sur Internet, même si votre pare-feu indique que le port est fermé !
Si vous utilisez un reverse proxy (comme Traefik, Nginx Proxy Manager ou Caddy) hébergé sur le même serveur, il est inutile d’exposer vos conteneurs sur toutes les interfaces réseau (0.0.0.0).
La bonne pratique consiste à lier systématiquement vos ports à l’adresse de bouclage locale 127.0.0.1 dans vos configurations :
services:
mon-app:
image: nginx:alpine
ports:
- "127.0.0.1:8080:80"
De cette façon, le port 8080 ne sera accessible que depuis le serveur lui-même (et donc uniquement par votre reverse proxy local), garantissant une sécurité optimale.
4. Automatiser les politiques de redémarrage (Restart Policies)
Si vous ne spécifiez rien lors de la création d’un conteneur, celui-ci restera hors-ligne si son processus plante, si le démon Docker redémarre ou si le serveur physique subit une coupure de courant. Pour des services d’infrastructure critiques (serveurs DNS AdGuard/Pi-hole, serveurs DHCP, outils de supervision), cette absence de résilience est problématique.
Il est recommandé de systématiser l’usage d’une politique de redémarrage automatique dans vos déploiements Docker Compose :
restart: unless-stopped
L’alternative always est également courante, mais unless-stopped a l’avantage de ne pas relancer automatiquement un conteneur que vous auriez délibérément arrêté vous-même avant le reboot de la machine. Grâce à cela, vos conteneurs se relancent de manière transparente et autonome en cas d’incident.
5. Planifier un nettoyage régulier (Docker Prune)
À force de mettre à jour des conteneurs et de compiler des images, Docker accumule une quantité impressionnante de « déchets » : anciennes images obsolètes, volumes orphelins, réseaux inutilisés et caches de build.
Prendre l’habitude d’intégrer le nettoyage dans son administration système est capital. Les commandes suivantes permettent de faire le ménage manuellement :
- Nettoyer les images inutilisées :
docker image prune - Nettoyer les conteneurs arrêtés :
docker container prune - Nettoyer les volumes orphelins (attention aux données persistantes) :
docker volume prune - Tout nettoyer d’un coup :
docker system prune -a
Pour suivre l’occupation de vos ressources Docker au fil de l’eau, n’hésitez pas à lancer la commande suivante pour obtenir un bilan immédiat :
docker system df
Automatisation du nettoyage via Cron
Pour éviter d’avoir à y penser, vous pouvez planifier une tâche Cron pour nettoyer automatiquement les ressources inutilisées chaque semaine. Ouvrez votre crontab :
crontab -e
Ajoutez la ligne suivante pour exécuter un nettoyage complet automatique chaque dimanche à 4h du matin :
0 4 * * 0 docker system prune -af --volumes > /dev/null 2>&1
6. Automatiser les mises à jour avec Watchtower
Pour aller encore plus loin dans la maintenance automatisée de votre serveur, vous pouvez déléguer la mise à jour de vos conteneurs à Watchtower. Cet outil surveille vos conteneurs actifs et applique automatiquement les nouvelles images dès qu’elles sont disponibles sur les registres (comme vos conteneurs utilisant les tags :latest).
[!TIP] Le projet d’origine
containrrr/watchtowern’étant plus maintenu, la communauté recommande d’utiliser le fork actifnickfedor/watchtower:latest, qui résout notamment les problèmes de compatibilité avec les API Docker récentes.
Pour le déployer de manière autonome, vous pouvez créer un service dédié dans un fichier docker-compose.yml :
services:
watchtower:
image: nickfedor/watchtower:latest
container_name: watchtower
restart: unless-stopped
volumes:
- /var/run/docker.sock:/var/run/docker.sock
environment:
- WATCHTOWER_CLEANUP=true
- WATCHTOWER_POLL_INTERVAL=86400
Quelques détails sur la configuration :
/var/run/docker.sock: Permet à Watchtower d’analyser l’état de l’hôte Docker et de relancer les conteneurs.WATCHTOWER_CLEANUP=true: Supprime l’ancienne image après avoir déployé la nouvelle version pour éviter d’accumuler des images orphelines.WATCHTOWER_POLL_INTERVAL=86400: Vérifie la présence de nouvelles versions toutes les 24 heures (en secondes).
Conclusion
Ces 6 étapes simples transforment un serveur Docker basique en un environnement robuste, stable et capable de tourner pendant des années sans intervention manuelle d’urgence. Appliquez-les systématiquement dès la mise en route de vos machines pour vous épargner des heures de dépannage fastidieuses !