Est-il sûr de nettoyer docker/overlay2/

Question

J'ai quelques conteneurs docker qui tournent sur AWS EC2 le dossier /var/lib/docker/overlay2 prend très rapidement de l'ampleur sur le disque.

Je me demande s'il est possible de supprimer son contenu en toute sécurité ? Je ne suis pas sûr que ce soit le cas, ni que docker dispose d'une commande permettant de libérer de l'espace disque.

---

UPDATE :

J'ai en fait essayé docker system prune -a déjà, ce qui a permis de récupérer 0Kb.

De plus, la taille de mon disque /docker/overlay2 est beaucoup plus importante que celle indiquée par la commande docker system df

Après avoir lu la documentation de docker et la réponse de BMitch, je pense que c'est une idée stupide de toucher à ce dossier et je vais essayer d'autres moyens de récupérer mon espace disque.

Answer 1

Docker utilise /var/lib/docker pour stocker vos images, vos conteneurs et vos volumes locaux nommés. La suppression de ce répertoire peut entraîner une perte de données et éventuellement empêcher le moteur de fonctionner. Le sous-répertoire overlay2 contient spécifiquement les différents éléments suivants couches du système de fichiers pour les images et les conteneurs.

Pour nettoyer les conteneurs et les images inutilisés, voir docker system prune . Il existe également des options permettant de supprimer des volumes et même des images marquées, mais elles ne sont pas activées par défaut en raison du risque de perte de données :

$ docker system prune --help

Usage:  docker system prune [OPTIONS]

Remove unused data

Options:
  -a, --all             Remove all unused images not just dangling ones
      --filter filter   Provide filter values (e.g. 'label=<key>=<value>')
  -f, --force           Do not prompt for confirmation
      --volumes         Prune volumes

Ce qu'un pruneau ne supprimera jamais inclut :

• les conteneurs en cours d'exécution (liste avec docker ps )
• sur ces conteneurs (voir ce poste pour plus de détails sur la limitation de la taille des journaux)
• les modifications du système de fichiers effectuées par ces conteneurs (visibles à l'aide de la fonction docker diff )

De plus, tout ce qui est créé en dehors des dossiers normaux de docker peut ne pas être vu par docker pendant ce garbage collection. Cela peut provenir d'une autre application écrivant dans ce répertoire, ou d'une configuration précédente du moteur de docker (par exemple en passant d'AUFS à overlay2, ou éventuellement après avoir activé les espaces de noms des utilisateurs).

Que se passerait-il si ce conseil était ignoré et que vous supprimiez un seul dossier comme overlay2 de ce système de fichiers ? Les systèmes de fichiers des conteneurs sont assemblés à partir d'une collection de couches de systèmes de fichiers, et le dossier overlay2 est l'endroit où docker effectue certains de ces montages (vous les verrez dans la sortie de mount lorsqu'un conteneur est en cours d'exécution). La suppression de certains d'entre eux lorsqu'ils sont utilisés supprimerait des morceaux du système de fichiers d'un conteneur en cours d'exécution, et briserait probablement la capacité de démarrer un nouveau conteneur à partir d'une image affectée. Voir t pour l'un des nombreux résultats possibles.

---

Pour rafraîchir complètement docker à un état propre, vous pouvez supprimer le répertoire entier, et pas seulement les sous-répertoires comme overlay2 :

# danger, read the entire text around this code before running
# you will lose data
sudo -s
systemctl stop docker
rm -rf /var/lib/docker
systemctl start docker
exit

Le moteur redémarrera dans un état complètement vide, ce qui signifie que vous perdrez tout :

• images
• conteneurs
• volumes nommés
• réseaux créés par les utilisateurs
• état de l'essaim

Answer 2

C'est ce qui me convient le mieux :

docker image prune --all

Par défaut, Docker ne supprime pas les images nommées, même si elles sont inutilisées. Cette commande supprimera les images inutilisées.

Notez que chaque couche d'une image est un dossier à l'intérieur du fichier /usr/lib/docker/overlay2/ dossier.

Answer 3

J'ai eu ce problème... C'est le journal qui était énorme. Les logs sont ici :

/var/lib/docker/containers/<container id>/<container id>-json.log

Vous pouvez gérer cela dans la ligne de commande d'exécution ou dans le fichier de composition. Voir ici : Configuration des pilotes de journalisation

J'ai personnellement ajouté ces 3 lignes à mon fichier docker-compose.yml :

my_container:
  logging:
    options:
      max-size: 10m

Answer 4

A également rencontré des problèmes liés à la croissance rapide des overlay2

/var/lib/docker/overlay2 - est un dossier dans lequel docker stocke les couches inscriptibles de votre conteneur. docker system prune -a - ne peut fonctionner que si le conteneur est arrêté et retiré.

Dans mon système, j'ai pu déterminer ce qui consomme de l'espace en allant dans la rubrique overlay2 et d'enquêter.

ce dossier contient d'autres dossiers nommés "hash". chacun d'entre eux contient plusieurs dossiers, notamment diff dossier.

diff folder - contient la différence réelle écrite par un conteneur dont la structure de dossier est identique à celle de votre conteneur (du moins c'était le cas pour moi - ubuntu 18...)

J'ai donc utilisé du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmp pour comprendre que /tmp à l'intérieur de mon conteneur, c'est le dossier qui est pollué .

J'ai donc utilisé comme solution de contournement -v /tmp/container-data/tmp:/tmp paramètre pour docker run pour mettre en correspondance les /tmp sur l'hôte et mettre en place un cron sur l'hôte pour nettoyer ce dossier.

La tâche cron était simple :

• sudo nano /etc/crontab
• */30 * * * * root rm -rf /tmp/container-data/tmp/*
• save and exit

NOTE : overlay2 est le dossier docker du système, et ils peuvent en changer la structure à tout moment. Tout ce qui précède est basé sur ce que j'ai vu à l'intérieur. J'ai dû aller dans la structure du dossier Docker uniquement parce que le système était complètement à court d'espace et ne me permettait même pas d'accéder au conteneur Docker par ssh.

Answer 5

J'ai utilisé "docker system prune -a" qui a nettoyé tous les fichiers sous les volumes et overlay2.

    [root@jasontest volumes]# docker system prune -a
    WARNING! This will remove:
            - all stopped containers
            - all networks not used by at least one container
            - all images without at least one container associated to them
            - all build cache
    Are you sure you want to continue? [y/N] y
    Deleted Images:
    untagged: ubuntu:12.04
    untagged: ubuntu@sha256:18305429afa14ea462f810146ba44d4363ae76e4c8dfc38288cf73aa07485005
    deleted: sha256:5b117edd0b767986092e9f721ba2364951b0a271f53f1f41aff9dd1861c2d4fe
    deleted: sha256:8c7f3d7534c80107e3a4155989c3be30b431624c61973d142822b12b0001ece8
    deleted: sha256:969d5a4e73ab4e4b89222136eeef2b09e711653b38266ef99d4e7a1f6ea984f4
    deleted: sha256:871522beabc173098da87018264cf3e63481628c5080bd728b90f268793d9840
    deleted: sha256:f13e8e542cae571644e2f4af25668fadfe094c0854176a725ebf4fdec7dae981
    deleted: sha256:58bcc73dcf4050a4955916a0dcb7e5f9c331bf547d31e22052f1b5fa16cf63f8
    untagged: osixia/openldap:1.2.1
    untagged: osixia/openldap@sha256:6ceb347feb37d421fcabd80f73e3dc6578022d59220cab717172ea69c38582ec
    deleted: sha256:a562f6fd60c7ef2adbea30d6271af8058c859804b2f36c270055344739c06d64
    deleted: sha256:90efa8a88d923fb1723bea8f1082d4741b588f7fbcf3359f38e8583efa53827d
    deleted: sha256:8d77930b93c88d2cdfdab0880f3f0b6b8be191c23b04c61fa1a6960cbeef3fe6
    deleted: sha256:dd9f76264bf3efd36f11c6231a0e1801c80d6b4ca698cd6fa2ff66dbd44c3683
    deleted: sha256:00efc4fb5e8a8e3ce0cb0047e4c697646c88b68388221a6bd7aa697529267554
    deleted: sha256:e64e6259fd63679a3b9ac25728f250c3afe49dbe457a1a80550b7f1ccf68458a
    deleted: sha256:da7d34d626d2758a01afe816a9434e85dffbafbd96eb04b62ec69029dae9665d
    deleted: sha256:b132dace06fa7e22346de5ca1ae0c2bf9acfb49fe9dbec4290a127b80380fe5a
    deleted: sha256:d626a8ad97a1f9c1f2c4db3814751ada64f60aed927764a3f994fcd88363b659
    untagged: centos:centos7
    untagged: centos@sha256:2671f7a3eea36ce43609e9fe7435ade83094291055f1c96d9d1d1d7c0b986a5d
    deleted: sha256:ff426288ea903fcf8d91aca97460c613348f7a27195606b45f19ae91776ca23d
    deleted: sha256:e15afa4858b655f8a5da4c4a41e05b908229f6fab8543434db79207478511ff7

    Total reclaimed space: 533.3MB
    [root@jasontest volumes]# ls -alth
    total 32K
    -rw-------  1 root root  32K May 23 21:14 metadata.db
    drwx------  2 root root 4.0K May 23 21:14 .
    drwx--x--x 14 root root 4.0K May 21 20:26 ..