Le matin d’une journée de boulot… la première chose que je fais (après ma douche), c’est de regarder si mon blog va bien. Évidemment, j’ai UptimeKuma pour m’aider à voir d’un coup d’œil comment se passe ma mini-prod… mais aujourd’hui, quelle n’a pas été mon horreur de constater que le / de mon serveur dédié, où se trouve notamment vBlog.io, était full…
Branlebas de combat, évidemment. Je me connecte, confirme le diagnostic et commence donc à regarder ce qui ne va pas. Bon, je ne vais pas vous détailler tout ce que j’ai regardé, mais la raison de ce / full : le répertoire /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots pesait plus de 30 Go, alors que d’habitude, j’n’en entends jamais parler !
On pense toujours qu’on maîtrise Docker et je pensais connaître pas mal les arcanes de cette enveloppe d’exécution de conteneurs ainsi que son fonctionnement interne… SAUF QUE (un peu de meme des Internets ne fait pas de mal) !
Je savais que Docker utilisait un moteur spécifique, containerd, chargé de faire tourner les environnements d’exécution et de gérer les nombreux layers associés. Docker n’étant finalement qu’un orchestrateur mono-serveur chargé de fournir une interface de pilotage de containerd (il en existe d’autres, comme Podman par exemple, ou évidemment les versions dites « à l’échelle » comme Kubernetes ou Docker Swarm, pour les plus connues).
Mais je pensais que tous les aspects « fichiers » des conteneurs étaient gérés totalement par Docker… ce qui était faux ! En fait, sachez que Docker s’appuie sur ce qu’on appelle le containerd image store, qui est lui-même, comme son nom l’indique, géré directement par containerd. C’est containerd qui stocke lui-même tous les layers (et leurs snapshotslogiques associés) de la peau d’oignon que constitue l’environnement d’exécution d’un conteneur.
Dans la pratique, containerd (et pas Docker) stocke tout cela dans un répertoire sous /var/lib/containerd. Je vous ai fait un screenshot de toutes ces couches, qui sont super bien présentées par DockHand, je trouve :
Il y a deux types de snapshots, dans la plupart des moteurs de conteneurs : les committed snapshots, en lecture seule (immuables) et qui peuvent être utilisés par plusieurs environnements d’exécution (c’est là, entre autres, une des forces des conteneurs), ainsi que les active snapshots, qui sont, la plupart du temps, les dernières couches (writable), par définition, et qui autorisent donc le conteneur lancé à écrire dans son propre espace de travail. C’est là que sont stockées toutes les modifications lors d’un docker build (vous savez, les conteneurs avec un Dockerfile).
Mais, mais, mais… revenons à nos moutons !
Toutes ces explications pour vous dire que j’avais totalement zappé la couche de layering… Et pour le coup, les versions récentes de Docker (les distributions officielles que j’utilise personnellement) utilisent containerd pour la majorité de leur stockage des images, du layering, des snapshots, etc. Docker ne stocke que les conteneurs et quelques métadonnées, par ailleurs. Ceci dit, cela peut dépendre de votre distribution et de la version de votre environnement… Donc, il y a un moyen simple de vérifier quel driver vous utilisez : docker info --format '{{json .DriverStatus}}'
Si Docker vous renvoie quelque chose comme ceci : [["driver-type", "io.containerd.snapshotter.v1"]] … c’est que vous utilisez containerd. Plus spécifiquement, aujourd’hui, il faut faire attention, quel que soit votre setup, à l’engine, en plus du gestionnaire lui-même, car Docker, aujourd’hui, s’est mis en conformité avec l’OCI, et ce depuis déjà plusieurs années (a priori 2022/2023).
Bref, mon souci initial d’espace disque était donc lié à cette complexité particulière… et je ne connaissais pas cette subtilité. Bon, dans la pratique, si vous gérez des environnements Docker, le mieux est d’avoir pensé à la consommation disque au préalable, d’avoir correctement taillé vos répertoires /var et de le superviser pour être certain de ne pas tomber dans un cas que vous n’avez pas anticipé… Et, comme toujours, LVM est votre ami, bien sûr !
Tout ça pour vous dire qu’on en apprend tout les jours ! et que la transmission d’info est très importante. Corriger un souci, c’est bien, mais ce n’est que le début. Faire un RETEX et documenter c’est mieux 🙂
Référence :
– La doc officielle de Docker au sujet de containerd et son image store : https://docs.docker.com/engine/storage/containerd/
– Le readme des snapshotters sur GitHub : https://github.com/containerd/containerd/blob/main/docs/snapshotters/README.md