## Harmonisez l'environnement de développement de votre équipe avec la configuration globale du démon [[Docker]] {#sec-b2e039a7f45a}

Que ce soit en local ou sur un serveur, l'utilisation de Docker implique souvent de copier-coller les mêmes configurations dans chaque `docker-compose.yml` pour chaque projet.

*   Définir systématiquement les DNS à `1.1.1.1` et `8.8.8.8`,
*   Fixer le pilote de logs sur `json-file` avec `max-size=10m`,
*   Les proxys, les registres non sécurisés, la plage réseau par défaut, etc.

Plutôt que des configurations individuelles pour chaque conteneur, il est bien plus simple de gérer ces éléments comme des **« valeurs par défaut pour l'ensemble de l'hôte »**. C'est précisément le rôle de la **configuration globale du démon Docker (`daemon.json`)**.

Ci-dessous, nous allons détailler :

*   Quel fichier,
*   Où le créer,
*   Comment le rédiger,
*   Et dans quelles situations il est utile pour quels développeurs ou équipes.

<br>
## 1. Deux méthodes de configuration du démon Docker {#sec-9c4e8fa25a41}

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

1.  **Utilisation du 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 logs à la fois avec le flag `--log-driver` et dans `daemon.json`, Docker affichera une erreur et s'arrêtera au démarrage.

Pour harmoniser les environnements d'équipe ou de serveur, il est généralement recommandé :

> « De regrouper autant que possible les configurations dans `daemon.json` et de n'utiliser les flags qu'au strict minimum. »

## 2. Emplacement du fichier `daemon.json` {#sec-97a08839a2de}

L'emplacement du fichier est **`/etc/docker/daemon.json`**. Ceci est bien sûr pour les systèmes Linux.

Bien que je ne sache pas si beaucoup de gens utilisent Docker en dehors de Linux, étant donné que je l'utilise uniquement sur Linux, je ne suis pas très familier avec les autres systèmes d'exploitation. Cependant, voici un tableau récapitulatif des emplacements par défaut pour chaque OS :

| Environnement | Chemin par défaut | Remarques |
| --- | ----- | --- |
| Linux (installation standard) | `/etc/docker/daemon.json` | Cas le plus courant |
| Linux (Docker installé via snap) | `/var/snap/docker/current/config/daemon.json` | Paquet snap Ubuntu |
| Windows Server / Docker Engine | `C:\ProgramData\Docker\config\daemon.json` |  |
| Docker Desktop (Mac / Windows) | `~/.docker/daemon.json` |  |

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

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

Voici le flux de travail typique sous Linux :

1.  **Création/Modification de `daemon.json`**

```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** de la validité du fichier de configuration

```bash
sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Si "configuration OK" apparaît, c'est bon
```

3.  **Redémarrage** du démon Docker

```bash
sudo systemctl restart docker
```

Désormais, les nouveaux conteneurs hériteront de ces configurations globales **par défaut**, sauf indication contraire.

## 4. Configuration principale : Fixer les serveurs DNS globalement {#sec-c284419e45cd}

### 4.1 Pourquoi un DNS global ? {#sec-78011cf35f17}

Si vos conteneurs rencontrent fréquemment des problèmes comme « ils ne trouvent pas étrangement l'API externe » ou « le domaine interne ne se résout pas », 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 les DNS de 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 ces paramètres au niveau du démon Docker, **plutôt que d'ajouter `dns:` dans chaque `docker-compose.yml` pour chaque projet**.

### 4.2 Exemple de configuration (`daemon.json`) {#sec-2a85a418cbea}

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

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

> ⚠️ **Attention :** Les paramètres DNS sont reflétés dans `/etc/resolv.conf` à l'intérieur du conteneur. Ils ne s'appliquent pas immédiatement aux conteneurs déjà en cours d'exécution, mais **uniquement aux nouveaux conteneurs lancés**.

## 5. Configuration principale 2 – Pilote de logs et options globales {#sec-fe09c43b83b1}

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

*   Définir le format des logs,
*   L'emplacement de stockage des logs,
*   La politique de rotation des logs.

Et les **appliquer de manière uniforme à tous les conteneurs**.

### 5.1 Pilote `json-file` par défaut + rotation {#sec-26c5fb9056b5}

Le modèle le plus courant est « utiliser simplement `json-file`, mais configurer la rotation pour éviter de saturer le disque ».

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

Avec cette configuration :

*   La taille maximale des fichiers de logs par conteneur est de `10 Mo`,
*   Un maximum de `5` fichiers est conservé,
*   Et les fichiers excédentaires sont automatiquement supprimés.

### 5.2 Pilotes pour la collecte centralisée des logs (fluentd, journald, etc.) {#sec-e7499afd6f5d}

Les équipes plateforme ou infrastructure souhaitent souvent envoyer les logs de tous les conteneurs vers un **système de logging centralisé**.

Par exemple, si vous utilisez Fluentd :

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

Avec cette configuration, les logs de tous les conteneurs sont automatiquement envoyés à Fluentd, sans avoir besoin d'un `docker run --log-driver=...` séparé.

Personnellement, j'apprécie également beaucoup 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, unifiant ainsi la consultation, le filtrage et les politiques de conservation via `journalctl`.

Si vous souhaitez utiliser `journald` comme pilote de logs global, vous pouvez le configurer comme ceci, par exemple :

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

L'utilisation du nom du conteneur comme `tag` permet :

*   De **parcourir rapidement les logs en temps réel** via `journalctl -f | grep {container_name}`,
*   De consulter **uniquement les logs depuis un certain moment** en combinant des options comme `--since "10m ago"`,
*   Et de **filtrer précisément les logs d'un conteneur spécifique** en utilisant l'option `-t` (par tag/identifiant) comme `journalctl -f -t {container_name}`.

Bien sûr, il est également possible de visualiser les logs par unité, comme avec `journalctl -u docker.service`, mais le filtrage 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` {#sec-8d284e8a0dfd}

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

Stratégiquement, il est recommandé :

*   De placer les valeurs communes dans `daemon.json`,
*   Et de ne surcharger individuellement que les services spécifiques.

Cette configuration est recommandée.

***

## 6. Configuration principale 3 – Proxy, registres non sécurisés et autres paramètres réseau globaux {#sec-bc2f973bcb11}

D'autres options fréquemment utilisées dans la configuration globale existent.

### 6.1 Configuration du proxy {#sec-753696ea7a1f}

Si l'accès à l'extérieur ne peut se faire que via un proxy d'entreprise, il est possible de **configurer le proxy au niveau du démon**, plutôt que d'ajouter des variables d'environnement à chaque fois.

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

Ainsi, le démon Docker utilisera ces paramètres de proxy lors du pull d'images ou de l'utilisation du réseau pendant la construction.

### 6.2 Registres non sécurisés (insecure registry) {#sec-fe7d1c14ce8d}

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

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

Cela peut être dangereux du point de vue de la sécurité, il convient donc de l'utiliser **uniquement dans des environnements de test internes**.

***

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


### 7.1 Personnalisation de la plage réseau `bridge` par défaut {#sec-00d891d2b55d}

Pour éviter les conflits d'adresses IP avec un VPN ou le réseau interne de l'entreprise :

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

Ainsi, 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 {#sec-04d867ec1442}

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

```json
{
  "storage-driver": "overlay2"
}
```

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

***

## 8. Adoptez cette configuration si vous avez l'impression d'un 'déjà-vu' {#sec-e2c8a9ca03d5}

Pas besoin d'être un expert en infrastructure complexe. Si vous avez récemment vécu l'une des expériences suivantes, il est temps de vous pencher sur `daemon.json`.

*   **À chaque nouveau projet, vous fouillez dans `docker-compose.yml` pour copier-coller les configurations de logs :** Si vous vous retrouvez à rechercher les réglages `max-size` et `max-file` dans le code d'hier pour les coller à nouveau, vous êtes déjà en train de perdre un temps précieux. Une seule configuration globale et tous les conteneurs démarreront automatiquement en mode 'léger'.
*   **Un conteneur qui fonctionnait parfaitement au bureau n'a plus d'accès internet en environnement café ou 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, quelle que soit l'environnement réseau, sans être influencés par les paramètres DNS de l'hôte, la fixation globale du DNS est la solution.
*   **Vous êtes épuisé à devoir ajuster manuellement la configuration de nombreux nœuds de serveur :** Êtes-vous en train de vous débattre avec des « bugs fantômes » causés par des configurations Docker légèrement différentes sur chaque serveur ? Un seul fichier `daemon.json` à déployer, et tous les serveurs fonctionneront selon les mêmes règles.

***

> Le moment idéal pour adopter cette configuration est lorsque les réglages répétitifs deviennent fastidieux, ou que vous êtes lassé des problèmes dus aux changements d'environnement.

## En résumé {#sec-857c80428df3}

*   Les valeurs par défaut globales de Docker sont gérées via **`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 logs : `"log-driver": "json-file"`, `"log-opts": {...}`
    *   Proxy, registres non sécurisés, 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 divers environnements.

Si vous continuez à utiliser les mêmes options dans `docker-compose.yml` ou `docker run`, **il est peut-être temps de les remonter dans `daemon.json`**.

![image de la configuration daemon.json de Docker](https://blog.mikihands.com/media/editor_temp/6/00f7dbc8-f71e-485b-b9a9-e9514af1ba73.png)