Docker Desktop 4.94 change le pilote de logs par défaut

Docker Desktop 4.94, publiée le 5 octobre 2026, modifie un réglage que beaucoup de développeurs n'ont jamais touché : le pilote de logs par défaut. Les nouveaux conteneurs Linux utilisent désormais le pilote local au lieu de json-file. Selon les notes de version, l'objectif est d'activer la rotation automatique des journaux et de réduire l'occupation disque. Un changement discret, mais qui peut surprendre les outils habitués à lire directement les fichiers de logs.

Ce qui change concrètement

Jusqu'ici, Docker enregistrait par défaut la sortie standard et la sortie d'erreur des conteneurs avec le pilote json-file. La documentation de Docker Engine le rappelle : avec ce pilote, « aucune rotation des journaux n'est effectuée » par défaut. Un conteneur bavard pouvait donc remplir progressivement le disque de la machine virtuelle de Docker Desktop.

Le pilote local, lui, fait tourner les fichiers sans configuration supplémentaire. D'après la documentation officielle, il conserve par défaut 100 Mo de messages par conteneur : la taille maximale d'un fichier (max-size) est fixée à 20 Mo, le nombre de fichiers (max-file) à 5, et la compression est activée. Docker recommandait déjà ce pilote pour la plupart des usages, en gardant json-file par défaut surtout pour des raisons de compatibilité ascendante.

Les conteneurs existants ne bougent pas

Le changement ne s'applique qu'aux nouveaux conteneurs Linux. La documentation de Docker est explicite : les conteneurs existants n'adoptent pas automatiquement une nouvelle configuration de journalisation. Pour qu'un conteneur passe au pilote local, il faut le recréer.

À l'inverse, si vous souhaitez conserver l'ancien comportement, il reste possible de fixer le pilote par conteneur avec l'option --log-driver json-file de docker run, ou de définir les clés log-driver et log-opt dans le fichier daemon.json, accessible depuis les réglages Docker Engine de Docker Desktop. Le démon doit ensuite redémarrer pour que la modification soit prise en compte.

Attention aux outils qui lisent les fichiers

C'est le principal point de vigilance. Les fichiers produits par le pilote local sont, selon Docker, « conçus pour être accessibles exclusivement par le démon Docker ». La documentation prévient que des outils externes qui y accèdent peuvent perturber la journalisation et provoquer des comportements inattendus. Les scripts ou agents de collecte qui lisaient directement les fichiers JSON des conteneurs devront donc être revus, ou les conteneurs concernés explicitement configurés en json-file.

Pour un usage courant de Docker Desktop, en revanche, la commande docker logs reste le moyen normal de consulter les journaux. Si vous découvrez les conteneurs, notre guide Docker, par où commencer reprend ces notions de base.

Le reste de la version 4.94

La mise à jour embarque Docker Engine 29.8.2, Buildx 0.37.2, containerd 2.3.6 et NVIDIA Container Toolkit 1.20.1. Côté correctifs, Docker indique notamment que les clés d'API enregistrées n'apparaissent plus dans les logs ni dans les diagnostics, que la création du disque de la machine virtuelle est plus rapide et consomme moins d'espace sur l'hôte, et que kubectl logs fonctionne désormais avec kubeadm. Sous Linux, quitter Docker Desktop ne ferme plus des applications sans rapport ; sous Windows, les messages d'erreur au démarrage de WSL ont été améliorés.

Ce qu'il faut retenir

• Nouveaux conteneurs Linux : pilote local par défaut, avec rotation et compression.
• Conteneurs existants : inchangés tant qu'ils ne sont pas recréés.
• Outils de collecte : vérifier ceux qui lisent les fichiers de logs sur disque.
• Retour en arrière : possible par conteneur ou via daemon.json.

Ce changement concerne Docker Desktop, l'environnement de poste de travail. Les serveurs de production qui font tourner Docker Engine ou des clusters Kubernetes gardent leur propre configuration de journalisation.