Harmonisez votre environnement de développement avec la configuration globale du démon Docker

Unifier l'environnement de développement de l'équipe avec la configuration globale du démon Docker

Que vous utilisiez Docker en local ou sur un serveur, vous vous retrouvez souvent à copier-coller les mêmes configurations dans chaque docker-compose.yml de vos projets.

• Définir systématiquement les DNS à 1.1.1.1, 8.8.8.8,
• Fixer le pilote de log sur json-file avec max-size=10m,
• Ou encore configurer le proxy, l'insecure registry, la plage réseau par défaut, etc.

Ces éléments, plutôt que d'être des configurations individuelles de conteneur, peuvent être définis comme des « valeurs par défaut pour l'ensemble de l'hôte », ce qui simplifie grandement leur gestion. C'est précisément le rôle de la configuration globale du démon Docker (daemon.json).

Ci-dessous, nous allons explorer :

• Quel fichier créer,
• Où le placer,
• Comment le configurer,
• Et dans quelles situations il est le plus utile pour les développeurs et les équipes.

1. Deux méthodes de configuration du démon Docker {#sec-7390246eab38}

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

1. Utilisation d'un fichier de configuration JSON (daemon.json) ← Recommandé
2. Transmission d'options via des flags CLI lors de l'exécution de dockerd.

Bien qu'il soit possible de combiner les deux, si la même option est spécifiée dans les deux méthodes, le démon ne démarrera pas du tout. Par exemple, si vous définissez le pilote de log à la fois via le flag --log-driver et dans daemon.json, Docker rencontrera une erreur au démarrage et s'arrêtera.

Pour harmoniser les environnements d'équipe/serveur, il est généralement recommandé de : « regrouper autant que possible dans daemon.json et utiliser les flags avec parcimonie. »

2. Emplacement du fichier daemon.json

L'emplacement du fichier est /etc/docker/daemon.json, sur les systèmes Linux bien sûr.

Bien que j'utilise Docker principalement sous Linux et que je sois moins familier avec les autres systèmes d'exploitation, voici un tableau récapitulatif des emplacements par défaut selon l'OS :

• Ce fichier peut ne pas exister par défaut ; si c'est le cas, vous devez le créer vous-même.

3. Modèle d'utilisation de base : « Créer le fichier → Redémarrer le démon » {#sec-bffe465cc36f}

Sous Linux, le flux de travail typique est le suivant :

1. Création/modification de daemon.json

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

2. Validation préalable du fichier de configuration

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Si "configuration OK" s'affiche, c'est que tout est normal :contentReference[oaicite:7]{index=7}

3. Redémarrage du démon Docker

sudo systemctl restart docker

Désormais, les nouveaux conteneurs hériteront de ces configurations globales par défaut, à moins d'une spécification contraire.

4. Configuration clé : Fixer les serveurs DNS globalement {#sec-d9c2238a423f}

4.1 Pourquoi un DNS global ?

Si vos conteneurs rencontrent fréquemment des problèmes comme « ne pas trouver d'API externe de manière inattendue » ou « ne pas résoudre les domaines internes », c'est souvent parce qu'ils dépendent de la configuration/l'environnement DNS de l'hôte.

Par exemple :

• Toute l'équipe souhaite utiliser le DNS Cloudflare (1.1.1.1)
• Il existe des points de terminaison accessibles uniquement via le serveur DNS interne de l'entreprise.

Dans ces situations, il est bien plus pratique d'unifier les paramètres DNS au niveau du démon Docker, plutôt que d'ajouter dns: à chaque docker-compose.yml de chaque projet.

4.2 Exemple de configuration (daemon.json)

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

Si un daemon.json existe déjà, il suffit d'ajouter l'entrée "dns": [...] à l'intérieur de l'objet racine { ... }.

⚠️ Attention : La configuration DNS est répercutée dans /etc/resolv.conf à l'intérieur du conteneur. Elle n'est pas appliquée immédiatement aux conteneurs déjà en cours d'exécution, mais seulement aux nouveaux conteneurs qui démarrent.

5. Configuration clé 2 – Pilote de journalisation et options globales {#sec-360ddebc7b6c}

Les logs des conteneurs sont par défaut stockés via le pilote json-file sous /var/lib/docker/containers/.... En le modifiant globalement, vous pouvez :

• Le format des logs
• L'emplacement de stockage des logs
• La politique de rotation des logs

Appliquer de manière uniforme ces paramètres à l'ensemble des conteneurs.

5.1 Pilote json-file par défaut + rotation

Le modèle le plus courant est d'« utiliser simplement json-file, mais avec une rotation des logs pour éviter de saturer le disque ».

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

Avec cette configuration :

• La taille maximale du fichier de log par conteneur est de 10MB.
• Seuls 5 fichiers maximum sont conservés.
• Les fichiers excédentaires sont automatiquement supprimés.

5.2 Pilotes pour la collecte centralisée des logs (fluentd, journald, etc.)

Pour les équipes plateforme ou infrastructure, il est souvent souhaitable d'envoyer les logs de tous les conteneurs vers un système de journalisation centralisé.

Par exemple, avec Fluentd :

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

Ainsi configuré, tous les logs des conteneurs sont automatiquement envoyés à Fluentd, sans avoir besoin de spécifier docker run --log-driver=... séparément.

Personnellement, j'apprécie également le pilote journald. Dans un environnement Linux basé sur systemd, il permet de centraliser les logs des applications et des conteneurs Docker en un seul endroit, offrant ainsi une gestion unifiée pour la consultation, le filtrage et les politiques de rétention via journalctl.

Si vous souhaitez utiliser journald comme pilote de log global, vous pouvez le configurer comme suit, par exemple :

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

En utilisant le nom du conteneur comme tag :

• Vous pouvez parcourir rapidement les logs en temps réel avec journalctl -f | grep {container_name}.
• Vous pouvez également combiner des options comme --since "10m ago" pour afficher les logs à partir d'un moment précis.
• Et en utilisant l'option -t (par tag/identifiant) comme journalctl -f -t {container_name}, vous pouvez cibler spécifiquement les logs d'un conteneur donné.

Bien sûr, il est aussi possible de visualiser par unité, comme avec journalctl -u docker.service, mais filtrer par nom de conteneur est plus intuitif et plus rapide à taper, ce qui le rend beaucoup plus utilisé en pratique.

5.3 Relation avec Compose / docker run

• Le log-driver + log-opts global agit comme une « valeur par défaut ».
• Si vous spécifiez logging: (Compose) ou --log-driver, --log-opt (CLI) pour un conteneur individuel, seul ce conteneur sera surchargé.

Stratégiquement :

• Les valeurs communes dans daemon.json.
• Les services spécifiques sont surchargés individuellement.

Cette configuration est recommandée.

6. Configuration clé 3 – Paramètres réseau globaux : proxy, insecure registry, etc. {#sec-0d687ac65460}

Voici d'autres options fréquemment utilisées dans la configuration globale.

6.1 Configuration du proxy

Si l'accès externe n'est possible que via un proxy d'entreprise, vous pouvez configurer le proxy au niveau du démon plutôt que d'ajouter des variables d'environnement à chaque fois.

{
  "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"
  }
}

De cette manière, le démon Docker utilisera cette configuration de proxy lors du téléchargement des images ou de l'utilisation du réseau pendant la construction.

6.2 Registre non sécurisé (insecure registry)

Si vous devez absolument utiliser un registre sans TLS (pour le développement interne, par exemple) :

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

Cela peut présenter des risques de sécurité, il est donc important de l'utiliser uniquement dans des environnements de test internes.

7. Configuration clé 4 – Plage réseau par défaut, pilote de stockage, etc. {#sec-3598d5fb02d3}

Des options plus axées sur l'infrastructure :

7.1 Personnalisation de la plage réseau bridge par défaut

Pour éviter que les adresses IP ne se chevauchent avec celles de votre VPN ou de votre réseau d'entreprise :

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

De cette manière, Docker utilisera la plage 10.20.x.0/24 lors de la création de nouveaux réseaux bridge.

7.2 Forcer le pilote de stockage

Le pilote de stockage par défaut peut varier selon les distributions Linux. Si votre équipe a décidé d'utiliser uniquement overlay2 :

{
  "storage-driver": "overlay2"
}

Les pilotes de stockage réellement pris en charge varient selon l'OS/noyau ; il est impératif de consulter la documentation de dockerd et le guide de votre distribution.

8. Si vous avez déjà eu ce « déjà-vu », il est temps d'adopter cette solution {#sec-807a100451aa}

Pas besoin de connaître les subtilités complexes de l'infrastructure. Si vous avez récemment vécu l'une des situations suivantes, c'est le moment idéal pour vous intéresser à daemon.json.

• Vous copiez-collez les configurations de log en fouillant dans votre docker-compose.yml à chaque nouveau projet : Si vous vous retrouvez à rechercher les réglages max-size et max-file dans votre code d'hier pour les coller à nouveau, vous perdez déjà un temps précieux. Une fois définies globalement, tous les conteneurs démarreront automatiquement en mode 'allégé'.
• Un conteneur qui fonctionne parfaitement au bureau n'a plus d'accès Internet dans un café ou un environnement VPN : C'est le cas typique du « ça marchait sur ma machine ! ». Si vous voulez que vos conteneurs communiquent de manière cohérente avec l'extérieur, quel que soit l'environnement réseau, sans être influencés par la configuration DNS de l'hôte, la fixation globale du DNS est la solution.
• Vous êtes épuisé à ajuster manuellement les configurations de nombreux nœuds de serveur : Vous vous arrachez les cheveux à cause de « bugs fantômes » dus à des configurations Docker légèrement différentes sur chaque serveur ? Un simple fichier daemon.json déployé peut transformer tous vos serveurs en une armée obéissant aux mêmes règles.

Le moment idéal pour adopter cette configuration est lorsque les réglages répétitifs sont devenus fastidieux, ou que vous êtes lassé de résoudre des problèmes liés aux changements d'environnement.

Résumé

• Les valeurs par défaut globales de Docker sont gérées dans daemon.json.
• L'emplacement est généralement /etc/docker/daemon.json.
• Exemples de configurations globales typiques :
  • DNS: "dns": ["1.1.1.1", "8.8.8.8"]
  • Pilote de journalisation: "log-driver": "json-file", "log-opts": {...}
  • Proxy, registre non sécurisé, plage réseau par défaut, pilote de stockage…
• Les configurations globales sont utiles pour éviter les réglages répétitifs et lors du déploiement de nombreux nœuds dans des environnements variés.

Si vous utilisez constamment les mêmes options dans docker-compose.yml ou docker run, il est peut-être temps de les remonter dans daemon.json.