Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:docker:admin:nettoyer_docker [2020/10/13 19:20] qduchemitechnique:docker:admin:nettoyer_docker [2022/10/29 12:02] (Version actuelle) qduchemi
Ligne 4: Ligne 4:
 Il peut arriver que l'espace alloué à Docker soit plein. Cette page présente des pistes pour résoudre ce problème. Il peut arriver que l'espace alloué à Docker soit plein. Cette page présente des pistes pour résoudre ce problème.
  
-<bootnote>Traditionnellement, Docker [[ technique:infrastructure:machines_virtuelles:install#partitionnement_des_disques|sa propre partition]] (LVM), montée sur `/var/lib/docker`</bootnote>+<bootnote>Traditionnellement, les données de Docker sont stockées dans [[ technique:infrastructure:machines_virtuelles:install#partitionnement_des_disques|une partition spécifique]] (LVM), montée sur `/var/lib/docker`. On suppose que c'est le cas pour le reste de cette page.</bootnote>
  
 <bootnote web>Le contexte et les éléments d'ébauche de cette page peuvent être retrouvés sur [ce fil Mattermost](https://team.picasoft.net/picasoft/pl/bn5nwzcgotraxxfznqqgftoqfe).</bootnote> <bootnote web>Le contexte et les éléments d'ébauche de cette page peuvent être retrouvés sur [ce fil Mattermost](https://team.picasoft.net/picasoft/pl/bn5nwzcgotraxxfznqqgftoqfe).</bootnote>
Ligne 10: Ligne 10:
 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. 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 : +Quand le volume monté sur `/var/lib/docker` arrive à saturation il y a plusieurs solutions complémentaire 
-  - Supprimer les données non utilisées +  - Supprimer les données non utilisées, 
-  - Allouer l'espace libre du `Volume Group` au `Logical Volume` correspondant à `/var/lib/docker` +  - Allouer plus d'espace disque à la partition montée sur `/var/lib/docker`, 
-  - Augmenter la taille des disques de la `Virtual Machine`+  - Augmenter la taille des disques de la machine virtuelle.
  
-===== Mener une enquête =====+## Nettoyage des données non-utilisées
  
-On peut commencer par regarder ce qui prend le plus de place dans le dossier `/var/lib/docker`la commande du nous aide à connaître le poids du contenu d'un dossieron lance donc cette commande pour savoir ce qui prend le plus de place dans le dossier concerné+<bootnote important>Opération destructrice : si vous vous foirez, vous pouvez supprimer des données de production. Faites particulièrement attention avant d'exécuter la commande, qui est sûre en elle même.</bootnote> 
 + 
 +Au fil des mises à jour, il y a du stockage pris par Docker qui n'est plus utilisé. 
 + 
 +<bootnote question>Quel genre de stockage ?</bootnote> 
 + 
 +* Les images qui ont été récupérées mais ne sont plus utilisées (*e.g.* ancienne version)les images dites *dangling* (anciens *layers* d'un tag qui ont été écrasées par une nouvelle version du même tag). 
 +* Les conteneurs éteints mais pas supprimés, qui consomment du stockage si des modifications ont été apportées aux images de base. 
 +* Les volumes Docker qui ne correspondent plus à aucun conteneur. 
 +* Les réseaux Docker utilisés par aucun conteneur. 
 +* Le cache des images. 
 + 
 +On peut obtenir une estimation de l'espace récupérable avec la commande : 
 + 
 +```bash 
 +docker system df
 ``` ```
-du -sh /var/lib/docker/*+ 
 +Afin de supprimer l'ensemble de ces données, on lancera la commande suivante. 
 + 
 +<bootnote>Si un conteneur s'est éteint à cause d'un bug, alors cette commande le supprimera. Vérifiez qu'aucun conteneur n'est éteint alors qu'il devrait tourner avec cette commande :
 ``` ```
-On voit ainsi quels sont les éléments qui occupent le plus de place en mémoire, par exemple : +docker ps --filter "status=exited"
-  * `volumes` pour le contenu persistant des containeurs (bases de données par exemple) +
-  * `overlay2` pour les containeurs +
-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+On peut utiliser le [[technique:graph_services|graphe des services]] pour savoir ce qui est censé tourner sur la machine. 
 +</bootnote> 
 + 
 +<bootnote>Cette commande ne supprime volontairement pas les volumes non-utilisés, pour se laisser une chance en cas de mauvaise manipulation.</bootnote> 
 + 
 +```bash 
 +docker system prune
 ``` ```
-Mais cette commande ne nous donne pas d'information exploitable sur les containeurs qui prennent le plus de placeil faut donc utiliser cette commande pour faire correspondre les noms (à adapter si on regarde plutôt des volumes par exemple) :+ 
 +Inspectez le résultat de la commande et vérifiez que ce qui a été supprimé n'était plus utilisé. Une fois que vous en êtes convaincusvous pouvez supprimer les volumes non-utilisés : 
 + 
 +```bash 
 +docker volume prune -a
 ``` ```
-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+ 
 +Il faut aussi rajouter une commande pour supprimer toutes les images non-associées à un conteneur : 
 + 
 +```bash 
 +docker image prune -a
 ``` ```
-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.+## Recherche d'un stockage inhabituel
  
-On peut utiliser des commandes similaires pour les volumes.+### Première tentative
  
-On peut également regarder si le registre ne prend pas trop de place `du -sh /var/lib/docker/volumes/registry-data`.+Si le stockage récupéré n'est pas suffisant, on peut regarder si un conteneur n'utilise pas plus de stockage que prévu, par exemple à cause d'un bug.
  
-===== Supprimer ce qui ne sert à rien =====+La commande suivante permet de lister le stockage utilisé par chaque conteneur, image et volume :
  
-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 pspour savoir ce qui tourne actuellement. +```bash 
- +docker system df -v
-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 ---volumes+ 
 +Ensuite, on traite au cas par cas. On peut par exemple découvrir des services qui tournent alors qu'ils n'ont plus rien à faire là (dans ce cas on les éteindra et on relancera un `prune`), ou des conteneurs qui prennent trop de place (par exemple, parce qu'ils loggent dans un fichier en mode `DEBUG`). 
 + 
 +De manière générale, un conteneur ne devrait jamais utiliser plus Go d'espace : les données volumineuses doivent être dans un volume, il y a donc un problème à investiguer. 
 + 
 +<bootnote>Si le [[technique:docker:general:mise_en_place_d_un_registry_docker|registre Docker]] est en cause, voir [[technique:adminsys:tips:menage_registre|la page dédiée au ménage du registre]].</bootnote> 
 + 
 +### Recherche supplémentaire 
 + 
 +<bootnote question>Que faire si l'espace disponible sur `/var/lib/docker` est anormalement faible, alors que `docker system df` ne reporte pas de grosse utilisation ?</bootnote> 
 + 
 +Franchement, ça ne devrait pas arriver. On peut tout de même regarder à la main ce qui prend le plus de place dans `/var/lib/docker`, et qui ne serait pas géré ou pris en compte par Docker. 
 + 
 +<bootnote>La commande `du -sh <dossier>` permet de connaître la taille d'un dossier et de ses sous-dossiers.</bootnote> 
 + 
 +<bootnote>`/var/lib/docker` est organisé en sous-dossiers : un pour les conteneurs, un pour les images, un pour les volumes...</bootnote> 
 + 
 +On cherche donc à savoir ce qui prend le plus de place : 
 + 
 +```bash 
 +du -sh /var/lib/docker/*
 ``` ```
-**/!\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é ! 
  
-===== Augmenter la taille du Logical Volume monté sur /var =====+On voit ainsi quels sont les éléments qui occupent le plus de place en mémoire, par exemple :
  
-Il s'agit soit d'attribuer toute la place restante au LV puis de redimensionner le système de fichier sous jacent pour suivre (ext4avec+  * `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` :
 ``` ```
-lvextend -l +100%FREE --resizefs /dev/mapper/pica01--test--vg-var+du -sh /var/lib/docker/overlay2/* | sort -rh | head -10
 ``` ```
-soit de spécifier la taille en absolu à ajouter au LV+ 
 +Mais cette commande ne nous donne pas d'information exploitable sur les conteneurs 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) : 
 + 
 ``` ```
-lvextend -L 10G --resizefs /dev/mapper/pica01--test--vg-var+for overlayID in $(du -sh /var/lib/docker/overlay2/* | sort -rh | head -10 | grep --o "[^/]*$"); do docker ps -a -q | xargs docker inspect | jq --arg ID "$overlayID" '.[] | select(.GraphDriver.Data.LowerDir | contains($ID)) | .Name'; done
 ``` ```
  
-===== Augmenter la taille du disque (PV) =====+On peut utiliser des commandes similaires pour les volumes. 
 + 
 +<bootnote>Cette commande récupère les ID des conteneurs qui prennent le plus de place, puis pour chacun d'eux elle fait correspondre le nom du conteneurs via la sortie JSON de la commande `docker inspect`.</bootnote> 
 + 
 +## Augmenter l'espace disponible
  
-S'il n'a plus de place sur le Physical Volume il faut augmenter la taille de celui-cicela se passe dans Proxmox et la modification est prise en charge à chaud (pas besoin de redémarrer la VM) +Si aucune des solutions précédentes n'fonctionné et que Docker a réellement besoin de plus de place, on suivra la [[technique:infrastructure:resize_vm_disks|documentation d'augmentation d'une partition]].
-{{ :technique:docker:0b2a7d60a3da6105fa5c6109de8e8e68.jpg?nolink&400 |}} +
-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 [[technique:infrastructure:machines_virtuelles:resize_vm_disks|ici]].+
  • technique/docker/admin/nettoyer_docker.1602609641.txt.gz
  • de qduchemi