Docker daemon.json

Fiche express
Type	Fichier de configuration du démon Docker
Emplacement	/etc/docker/daemon.json
Format	JSON
Application	Redémarrage du service (systemctl restart docker), parfois précédé d'un daemon-reload
Voir aussi	Docker socket · Docker registry · LVM

Le fichier daemon.json centralise les options de démarrage du démon Docker (dockerd) : pilote de stockage, pilote et rétention des logs, réseau du pont par défaut, registres considérés comme non sécurisés, résolution DNS des conteneurs, etc. Il vient en complément (ou en remplacement partiel) des options passées en ligne de commande via l'unit systemd du service — voir Docker socket pour l'activation de l'API distante.

Emplacement et application des changements

Le fichier n'existe pas forcément par défaut ; il suffit de le créer :

vi /etc/docker/daemon.json

Toute modification nécessite un redémarrage du démon :

systemctl restart docker

Si un fichier drop-in systemd a également été modifié (voir la section socket de Docker pratiques), il faut recharger la configuration systemd avant de redémarrer :

systemctl daemon-reload
systemctl restart docker

Un JSON syntaxiquement invalide empêche le démon de démarrer : penser à valider le fichier (par exemple avec python3 -m json.tool daemon.json) avant de relancer le service en production.

Pilote de stockage

Le pilote de stockage (storage-driver) détermine comment Docker empile les couches d'images sur le système de fichiers de l'hôte.

overlay2 est le pilote recommandé sur les noyaux Linux récents :

{
  "storage-driver": "overlay2"
}

devicemapper (mode direct-lvm) a longtemps été utilisé sur les distributions plus anciennes, en s'appuyant sur un volume LVM dédié :

{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.directlvm_device=/dev/nvme1n1",
    "dm.thinp_percent=95",
    "dm.thinp_metapercent=1",
    "dm.thinp_autoextend_threshold=80",
    "dm.thinp_autoextend_percent=20",
    "dm.directlvm_device_force=true"
  ]
}

Ce pilote est considéré comme obsolète depuis plusieurs versions de Docker au profit d'overlay2 (à vérifier selon la version exacte) ; il ne devrait plus être choisi pour un nouveau déploiement.

Journalisation

Par défaut, chaque conteneur écrit ses logs dans un fichier JSON non tourné : sans limite, ce fichier peut croître indéfiniment et saturer le disque. Le pilote json-file accepte des options de rotation et d'étiquetage :

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "labels": "production_status",
    "env": "os,customer"
  }
}

• max-size / max-file : taille maximale par fichier et nombre de fichiers conservés (rotation).
• labels / env : labels de conteneur ou variables d'environnement à injecter dans les métadonnées de logs, utile pour le filtrage côté collecteur (Fluentd, Loki, etc.).

Ces réglages ne s'appliquent qu'aux nouveaux conteneurs créés après la modification.

Réseau

Adressage du pont par défaut (docker0) — la clé bip (bridge IP) fixe la plage utilisée par le pont docker0 et, par extension, par les conteneurs qui n'utilisent pas de réseau dédié :

{
  "bip": "172.20.0.1/16"
}

Le détail de la procédure complète (suppression de l'interface existante, redémarrage) est décrit dans Docker pratiques.

Résolution DNS des conteneurs :

{
  "dns": ["8.8.8.8"]
}

En pratique, on préfère souvent pointer vers un résolveur interne plutôt qu'un DNS public, notamment dans un environnement isolé du réseau.

Registres non sécurisés

La clé insecure-registries autorise Docker à dialoguer en HTTP (ou en HTTPS avec un certificat non reconnu par le magasin de confiance système) avec les registres listés. Elle est surtout utile en développement ou avec un registre interne utilisant un certificat auto-signé :

{
  "insecure-registries": ["registry.example.local:5050", "registry.example.local:443"]
}

À éviter en production dès que possible : la meilleure pratique reste de distribuer le certificat racine interne (ou d'utiliser un certificat public valide) plutôt que de désactiver la vérification. Voir Docker registry pour la mise en place d'un registre avec un certificat correctement validé.

Exemple consolidé

{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "bip": "172.20.0.1/16",
  "insecure-registries": ["registry.example.local:5050"]
}