Administration d'un hôte Docker Engine : daemon.json, utilisation du disque et live-restore

Objectif

Configurer la journalisation et le stockage du démon Docker Engine, contrôler l'utilisation du disque et libérer de l'espace sans supprimer de ressources encore utilisées.

Prérequis

Être root ou membre du groupe docker sur l'hôte. L'appartenance au groupe docker équivaut à un accès root sur cet hôte, car le démon s'exécute en root et le groupe permet de lui faire monter par bind mount des chemins arbitraires de l'hôte : l'appartenance au groupe docker doit être traitée avec le même soin qu'un accès sudo.

Étapes

1. Au démarrage, le démon lit /etc/docker/daemon.json (JSON). La référence de dockerd documente ses options de ligne de commande, dont la plupart ont une clé JSON correspondante. Clés courantes au niveau de l'hôte :

{
  "data-root": "/var/lib/docker",
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "live-restore": true
}

2. data-root déplace l'emplacement de stockage des images, des conteneurs et des volumes. Ce déplacement exige d'arrêter le démon (docker.service et docker.socket, faute de quoi l'activation par socket le relance), de copier le répertoire existant en conservant propriétaires, permissions et attributs étendus, de modifier la clé, puis de redémarrer. Tous les conteneurs sont alors arrêtés, même avec live-restore.
3. log-driver/log-opts définissent le pilote de journalisation par défaut des nouveaux conteneurs. Sans max-size/max-file pour le pilote json-file, les logs des conteneurs peuvent croître indéfiniment sur le disque. Les conteneurs existants conservent leur ancienne configuration de logs tant qu'ils ne sont pas recréés.
4. live-restore: true maintient les conteneurs Linux autonomes (standalone) en cours d'exécution lorsque le démon est arrêté, plante ou est mis à jour vers une version corrective plus récente (YY.MM.x). Cette option n'est pas prise en charge lors des mises à niveau majeures (YY.MM), ne s'applique pas aux services Swarm et peut échouer si des options du démon, comme le pilote de stockage ou les adresses du bridge, ont changé. Tant que le démon est arrêté, un conteneur qui remplit son tampon de 64K du pipe de logs se bloque à l'écriture. Pour l'activer, utilisez sudo systemctl reload docker (SIGHUP) plutôt qu'un redémarrage, qui arrêterait les conteneurs en cours puisque live-restore n'est pas encore actif ; vérifiez avec docker info --format '{{.LiveRestore}}'.
5. Appliquer les changements de façon non interactive : sauvegardez daemon.json, validez-le avec sudo dockerd --validate --config-file /etc/docker/daemon.json (Docker 23.0 et versions ultérieures), puis exécutez sudo systemctl restart docker (arrête les conteneurs sauf si live-restore est déjà actif) ou reload pour les options rechargeables. Un paramètre défini à la fois dans daemon.json et comme option dans l'unité de service (typiquement hosts/-H) empêche le démarrage du démon ; surveillez journalctl -u docker --no-pager. Pour annuler, restaurez la sauvegarde.
6. Contrôler l'utilisation du disque par catégorie : docker system df (-v pour le détail par élément, y compris l'espace récupérable).
7. Récupérer de l'espace avec prudence : docker system prune supprime tous les conteneurs arrêtés, les réseaux inutilisés par un conteneur, les images dangling et le cache de build inutilisé. -a supprime aussi toutes les images non utilisées par un conteneur, et --volumes supprime aussi les volumes anonymes non utilisés par un conteneur (les volumes nommés sont conservés). La commande demande confirmation ; -f supprime cette demande pour les scripts. Exécutez d'abord docker system df, et lancez le nettoyage sans -a/--volumes tant que vous n'avez pas confirmé que rien de nécessaire n'est référencé uniquement par un conteneur arrêté.

Résultat attendu

docker info reflète les nouvelles valeurs de data-root/live-restore ; docker system df indique moins d'espace récupérable après un nettoyage, les conteneurs actifs et leurs images restant intacts.

Limites et base de vérification

Le périmètre exact de docker system prune dépend de ses options et a changé d'une version à l'autre (les anciens moteurs supprimaient aussi les volumes nommés inutilisés avec --volumes). Lancer la commande sans avoir examiné docker system df au préalable peut supprimer un conteneur arrêté encore nécessaire à une tâche planifiée.