Unifier l'environnement de développement avec les paramètres globaux du démon Docker

Unifier l'environnement de développement de l'équipe grâce aux paramètres globaux du démon Docker

Que vous travailliez en local ou sur un serveur, Docker vous fait souvent copier-coller les mêmes réglages dans le docker-compose.yml de chaque projet.

• Fixer le DNS sur 1.1.1.1, 8.8.8.8
• Fixer le driver de log sur json-file + max-size=10m
• Proxy, registre non sécurisé, plage réseau par défaut…

Ces réglages sont plus simples à gérer lorsqu'ils sont définis comme valeurs par défaut de l'hôte plutôt que sur chaque conteneur. Le mécanisme qui permet cela est le fichier de configuration globale du démon Docker (daemon.json).

Dans cet article, nous allons aborder :

• Où placer ce fichier
• Comment le rédiger
• Dans quels cas il est utile pour les développeurs ou les équipes

1. Deux façons de configurer le démon Docker

Le démon Docker (dockerd) peut être configuré de deux manières principales :

1. Fichier JSON (daemon.json) ← recommandé
2. Flags CLI lors du lancement de dockerd

Il est possible de mélanger les deux, mais définir la même option dans les deux endroits provoque l'échec du démarrage du démon. Par exemple, si vous spécifiez --log-driver en flag et dans daemon.json, Docker échouera au démarrage.

Pour une standardisation d'équipe ou de serveur, il est généralement conseillé de :

“Regrouper autant que possible dans daemon.json et limiter les flags”

2. Où se trouve daemon.json ?

Voici un tableau récapitulatif des emplacements par système d'exploitation et méthode d'installation :

• Le fichier peut ne pas exister par défaut ; il faut le créer manuellement si besoin.
• Pour les équipes ou serveurs, on se réfère généralement à /etc/docker/daemon.json sur Linux.

3. Modèle de base : “Créer le fichier → redémarrer le démon”

Sur Linux, le flux de travail le plus courant est le suivant.

1. Écrire/Modifier daemon.json

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

2. Vérifier la validité

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Si "configuration OK" apparaît, tout est correct

3. Redémarrer le démon

sudo systemctl restart docker

Les nouveaux conteneurs hériteront désormais de ces paramètres globaux, sauf s'ils sont explicitement surchargés.

4. Exemple 1 – Fixer le serveur DNS globalement

4.1 Pourquoi fixer le DNS ?

Si les conteneurs rencontrent souvent des problèmes comme « ne trouve pas l'API externe » ou « ne résout pas les domaines internes », c'est généralement dû à la configuration DNS de l'hôte.

• Toute l'équipe souhaite utiliser Cloudflare DNS (1.1.1.1)
• Certains endpoints ne sont accessibles qu'à travers le DNS interne de l'entreprise

Dans ces cas, il est plus simple de fixer le DNS au niveau du démon Docker plutôt que d'ajouter dns: dans chaque docker-compose.yml.

4.2 Exemple de configuration (daemon.json)

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

Si un daemon.json existe déjà, ajoutez simplement la clé "dns": [...] à la racine { ... } (attention aux virgules).

⚠️ Attention : la configuration DNS est appliquée dans /etc/resolv.conf des conteneurs. Les conteneurs déjà en cours d'exécution ne seront pas affectés ; seuls les nouveaux conteneurs le seront.

4.3 Qui en bénéficiera ?

• Développeurs travaillant derrière un proxy ou DNS interne
• Équipes multi-cloud nécessitant un DNS spécifique
• Développeurs locaux alternant VPN

5. Exemple 2 – Driver de log et options globales

Les logs des conteneurs sont par défaut stockés par le driver json-file dans /var/lib/docker/containers/.... En les configurant globalement, vous appliquez la même politique de log à tous les conteneurs.

5.1 Driver json-file + rotation

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

• Taille maximale d'un fichier log : 10 MB
• Nombre maximal de fichiers : 5
• Les fichiers excédentaires sont supprimés automatiquement.

5.2 Driver centralisé (fluentd, journald, etc.)

Pour envoyer les logs vers un système centralisé, par exemple Fluentd :

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

Avec journald (Linux systemd) :

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

Vous pourrez alors filtrer les logs via journalctl -t {container_name}.

5.3 Relation avec Compose / docker run

• Le driver global sert de valeur par défaut.
• Si un conteneur spécifie logging: (Compose) ou --log-driver/--log-opt (CLI), il surchargera la configuration globale.

Stratégie recommandée : valeurs communes dans daemon.json, surcharges spécifiques uniquement lorsqu'elles sont nécessaires.

6. Exemple 3 – Proxy, registre non sécurisé et autres paramètres réseau globaux

6.1 Proxy

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

Le démon utilisera ces paramètres lors du pull d'images ou de la construction.

6.2 Registre non sécurisé

{
  "insecure-registries": ["my-registry.local:5000"]
}

Utiliser uniquement dans des environnements de test internes.

7. Exemple 4 – Plage réseau par défaut, pilote de stockage, etc.

7.1 Plage réseau par défaut

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

Les nouvelles bridges utiliseront 10.20.x.0/24.

7.2 Pilote de stockage

{
  "storage-driver": "overlay2"
}

Vérifiez la compatibilité avec votre distribution Linux.

8. À qui s'adresse particulièrement cette approche ?

8.1 Développeur individuel

• Utilise les mêmes options Docker sur plusieurs projets
• Travaille avec VPN ou proxy qui changent fréquemment
• Souhaite éviter la gestion manuelle des logs et du disque

→ Un seul daemon.json suffit pour uniformiser l'environnement.

8.2 Petites à moyennes équipes

• Éviter les divergences de configuration Docker entre les machines
• Harmoniser les paramètres réseau et de log entre CI et local
• Imposer des DNS, proxy ou registres internes

→ Définir une convention d'équipe via daemon.json (déployé par Ansible, Chef, Terraform, Cloud‑Init, etc.).

8.3 Équipes plateforme / DevOps / SRE

• Gérer des nœuds avec des dizaines ou centaines de conteneurs
• Standardiser logs, stockage, réseau
• Appliquer des règles de sécurité au niveau de l'hôte

→ daemon.json devient le fichier de politique du nœud Docker.

9. Astuces de débogage

1. Flags et doublons - Vérifiez le fichier d'unité systemd (/lib/systemd/system/docker.service) pour des flags comme --log-driver. - Un même paramètre dans un flag et dans daemon.json provoque l'échec du démon.
2. Docker Desktop - Les paramètres UI modifient ~/.docker/daemon.json en interne. - Évitez de modifier le fichier manuellement si vous utilisez l'interface graphique.

Conclusion

• Les valeurs globales du démon Docker sont gérées via daemon.json.
• Emplacement typique : /etc/docker/daemon.json (Linux), C:\ProgramData\Docker\config\daemon.json (Windows), ~/.docker/daemon.json (Docker Desktop).
• Exemples courants : DNS, driver de log, proxy, registre non sécurisé, plage réseau, pilote de stockage.
• Les paramètres globaux simplifient la vie des développeurs individuels et des équipes, tout en réduisant les erreurs de configuration.

Si vous avez toujours dupliquer les mêmes options dans docker-compose.yml ou docker run, il est temps de les centraliser dans daemon.json.