Libérer de l'espace disque utilisé par Docker

Il peut arriver que l’espace alloué à Docker soit plein. Cette page présente des pistes pour résoudre ce problème.

La partition montée sur /var/lib/docker est un volume logique. Nous avons fait le choix de ne pas tout mettre dans une unique partition montée sur / pour éviter que le reste du système ne soit impacté si le stockage de docker explose.

Quand le volume monté sur /var/lib/docker arrive à saturation il y a plusieurs solutions complémentaire :

1. Supprimer les données non utilisées,
2. Allouer plus d’espace disque à la partition montée sur /var/lib/docker,
3. Augmenter la taille des disques de la machine virtuelle.

On peut commencer par regarder ce qui prend le plus de place dans le dossier /var/lib/docker.

On cherche donc à savoir ce qui prend le plus de place :

snippet.bash

du -sh /var/lib/docker/*

On voit ainsi quels sont les éléments qui occupent le plus de place en mémoire, par exemple :

• volumes pour le contenu persistant des conteneurs (bases de données par exemple)
• overlay2 pour les conteneurs

Une fois que l’on a déterminé le dossier qui prend le plus de place, On peut regarder par exemple quels sont les dix plus gros fichiers les plus gros dans /var/lib/docker/overlay2 :

du -sh /var/lib/docker/overlay2/* | sort -rh | head -10

Mais cette commande ne nous donne pas d’information exploitable sur les containeurs qui prennent le plus de place, il faut donc utiliser cette commande pour faire correspondre les noms (à adapter si on regarde plutôt des volumes par exemple) :

for overlayID in $(du -sh /var/lib/docker/overlay2/* | sort -rh | head -10 | grep -P -o "[^/]*$"); do docker ps -a -q | xargs docker inspect | jq --arg ID "$overlayID" '.[] | select(.GraphDriver.Data.LowerDir | contains($ID)) | .Name'; done

En gros, cette commande récupère les ID des containeurs qui prennent le plus de place, puis pour chacun d’eux elle fait correspondre depuis la liste des conteneurs de la machine le nom du containeur via la sortie json de la commande docker inspect.

Si un conteneur prend plusieurs Go de mémoire, c’est mauvais signe : les données devraient être dans un volume, il doit y avoir un souci. Typiquement, une configuration des logs en DEBUG à des fins de tests qui n’a jamais été enlevée, faisant grossir le fichier des logs à l’infini.

On peut utiliser des commandes similaires pour les volumes.

On peut également regarder si le registre ne prend pas trop de place du -sh /var/lib/docker/volumes/registry-data.

Une fois cette petite enquête menée on va pouvoir commencer par éteindre ce qui ne sert à rien (attention à ne pas éteindre n’importe quoi en production), par exemple les anciens services, les anciennes dépendances, les services que l’on ne teste plus. On fais docker ps pour savoir ce qui tourne actuellement.

On peut maintenant lancer une commande qui supprime tout ce qui n’est pas utilisé par docker (réseaux, images, containeurs et volumes) :

docker system prune -a --volumes

/!\Faire attention en production/!\ Cette commande supprime tout ce qui n’est pas utilisé donc si un service a été temporairement arrêté, un volume de backup est présent, … Ce sera supprimé !

Il s’agit soit d’attribuer toute la place restante au LV puis de redimensionner le système de fichier sous jacent pour suivre (ext4) avec

lvextend -l +100%FREE --resizefs /dev/mapper/pica01--test--vg-var

soit de spécifier la taille en absolu à ajouter au LV

lvextend -L 10G --resizefs /dev/mapper/pica01--test--vg-var

S’il n’y a plus de place sur le Physical Volume il faut augmenter la taille de celui-ci, cela se passe dans Proxmox et la modification est prise en charge à chaud (pas besoin de redémarrer la VM) puis il faut augmenter la taille de la partition qui sert de PV pour LVM (le disque entier ne sert pas car d’autres parties servent à monter /boot par exemple). Puis enfin indiquer à LVM que le PV à été modifié pour qu’il se mette à jour. La procédure est décrite ici.