¿Es seguro limpiar la ventana acoplable / overlay2 /

Tengo algunos contenedores docker ejecutándose en AWS EC2, la carpeta / var / lib / docker / overlay2 crece muy rápido en tamaño de disco.

Me pregunto si es seguro eliminar su contenido. o si Docker tiene algún tipo de comando para liberar algo de uso del disco.

ACTUALIZAR:

De hecho docker system prune -a, ya lo intenté , lo que reclamó 0Kb.

Además, el tamaño de mi disco / docker / overlay2 es mucho mayor que la salida de docker system df

Después de leer la documentación de la ventana acoplable y la respuesta de BMitch, creo que es una idea estúpida tocar esta carpeta e intentaré otras formas de recuperar mi espacio en disco.

Docker usa / var / lib / docker para almacenar sus imágenes, contenedores y volúmenes locales con nombre. Eliminar esto puede provocar la pérdida de datos y posiblemente detener el funcionamiento del motor. El subdirectorio overlay2 contiene específicamente las diversas capas del sistema de archivos para imágenes y contenedores.

Para limpiar contenedores e imágenes no utilizados, consulte docker system prune. También hay opciones para eliminar volúmenes e incluso imágenes etiquetadas, pero no están habilitadas de forma predeterminada debido a la posibilidad de pérdida de datos.

Encontré que esto funcionó mejor para mí:

docker image prune --all

De forma predeterminada, Docker no eliminará las imágenes con nombre, incluso si no se utilizan. Este comando eliminará las imágenes no utilizadas.

Tenga en cuenta que cada capa de una imagen es una carpeta dentro del /usr/lib/docker/overlay2/ carpeta.

Tuve este problema ... Era el registro lo que era enorme. Los registros están aquí:

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

Puede administrar esto en la línea de comando de ejecución o en el archivo de redacción. Ver allí: Configurar controladores de registro

Personalmente agregué estas 3 líneas a mi archivo docker-compose.yml:

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

también tuvo problemas con el crecimiento rápido overlay2

/var/lib/docker/overlay2 - es una carpeta donde la ventana acoplable almacena capas grabables para su contenedor. docker system prune -a- puede funcionar solo si el recipiente se detiene y se retira.

en mi pude averiguar qué consume espacio al entrar overlay2e investigar.

esa carpeta contiene otras carpetas con nombre hash. cada uno de ellos tiene varias carpetas, incluida la diffcarpeta.

diff carpeta: contiene la diferencia real escrita por un contenedor con la estructura de carpeta exacta como su contenedor (al menos en mi caso, ubuntu 18 ...)

Así que solía du -hsc /var/lib/docker/overlay2/LONGHASHHHHHHH/diff/tmpdescubrir que /tmpdentro de mi contenedor está la carpeta que se contamina .

Entonces, como solución temporal, he usado el -v /tmp/container-data/tmp:/tmpparámetro para el docker runcomando para asignar la /tmpcarpeta interna al host y configurar un cron en el host para limpiar esa carpeta.

La tarea cron fue simple:

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

NOTA: overlay2es la carpeta de la ventana acoplable del sistema y pueden cambiar su estructura en cualquier momento. Todo lo anterior se basa en lo que vi allí. Tuve que ir a la estructura de carpetas de la ventana acoplable solo porque el sistema estaba completamente sin espacio e incluso no me permitía ingresar al contenedor de la ventana acoplable.

Fondo

La culpa del problema se puede dividir entre nuestra mala configuración de los volúmenes de contenedores y un problema con la ventana acoplable que filtra (no se libera) los datos temporales escritos en estos volúmenes. Deberíamos estar mapeando (ya sea a carpetas de alojamiento u otras reclamaciones de almacenamiento persistentes) todas las carpetas temporales / registros / temporales del contenedor donde nuestras aplicaciones escriben con frecuencia y / o mucho. Docker no asume la responsabilidad de la limpieza de todos los llamados EmptyDirs creados automáticamente ubicados por defecto en/var/lib/docker/overlay2/*/diff/* . El contenido de estas carpetas "no persistentes" debe ser purgado automáticamente por la ventana acoplable después de que se detenga el contenedor, pero aparentemente no es así (pueden ser incluso imposibles de purgar desde el lado del host si el contenedor aún se está ejecutando, y puede estar ejecutándose durante meses a la vez).

Solución alterna

Una solución requiere una limpieza manual cuidadosa y, aunque ya se describió en otra parte, aún puede encontrar algunas sugerencias de mi estudio de caso, que traté de hacer lo más instructivo y generalizable posible.

Entonces, lo que sucedió es que la aplicación culpable (en mi caso clair-scanner) logró escribir durante unos meses cientos de gigas de datos en la /diff/tmpsubcarpeta de docker'soverlay2

du -sch /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp

271G total

Entonces, como todas esas subcarpetas en /diff/tmperan bastante autoexplicativas (todas tenían el formulario clair-scanner-*y tenían fechas de creación obsoletas), detuve el contenedor asociado ( docker stop clair) y eliminé cuidadosamente estas subcarpetas obsoletas diff/tmp, comenzando prudentemente con una sola (la más antigua), y probando el impacto en el motor de la ventana acoplable (que requirió reiniciar [ systemctl restart docker] para recuperar espacio en disco):

rm -rf $(ls -at /var/lib/docker/overlay2/<long random folder name seen as bloated in df -haT>/diff/tmp | grep clair-scanner | tail -1)

Recuperé cientos de gigas de espacio en disco sin la necesidad de volver a instalar la ventana acoplable o purgar todas sus carpetas. Todos los contenedores en ejecución tenían que detenerse en un momento dado, porque se requería el reinicio del demonio de la ventana acoplable para recuperar espacio en el disco, así que asegúrese primero de que sus contenedores de conmutación por error se estén ejecutando correctamente en otro / otro nodo / s). Sin embargo, me gustaría que el docker prunecomando pudiera cubrir los datos obsoletos /diff/tmp(o incluso /diff/*) también (a través de otro interruptor).

Es un problema de 3 años ahora, puede leer su rica y colorida historia en los foros de Docker, donde se propuso una variante destinada a los registros de aplicaciones de la solución anterior en 2019 y parece haber funcionado en varias configuraciones: https: // foros.docker.com/t/some-way-to-clean-up-identify-contents-of-var-lib-docker-overlay/30604

ADVERTENCIA: NO UTILIZAR EN UN SISTEMA DE PRODUCCIÓN

/# df
...
/dev/xvda1      51467016 39384516   9886300  80% /
...

Ok, primero intentemos podar el sistema

#/ docker system prune --volumes
...
/# df
...
/dev/xvda1      51467016 38613596  10657220  79% /
...

No tan bien, parece que limpió algunos megabytes. Vamos a volvernos locos ahora:

/# sudo su
/# service docker stop
/# cd /var/lib/docker
/var/lib/docker# rm -rf *
/# service docker start
/var/lib/docker# df
...
/dev/xvda1      51467016 8086924  41183892  17% /
...

¡Agradable! Solo recuerde que esto NO se recomienda en nada más que en un servidor desechable. En este punto, la base de datos interna de Docker no podrá encontrar ninguna de estas superposiciones y puede causar consecuencias no deseadas.

NO HAGA ESTO EN PRODUCCIÓN

La respuesta dada por @ ravi-luthra técnicamente funciona, ¡pero tiene algunos problemas!

En mi caso, solo estaba intentando recuperar espacio en disco. loslib/docker/overlay carpeta ocupaba 30 GB de espacio y solo ejecuto algunos contenedores con regularidad. Parece que Docker tiene algún problema con la fuga de datos y algunos de los datos temporales no se borran cuando el contenedor se detiene.

Así que seguí adelante y eliminé todo el contenido de la lib/docker/overlaycarpeta. Después de eso, Mi instancia de Docker se volvió inutilizable. Cuando intenté ejecutar o construir cualquier contenedor, me dio este error:

failed to create rwlayer: symlink ../04578d9f8e428b693174c6eb9a80111c907724cc22129761ce14a4c8cb4f1d7c/diff /var/lib/docker/overlay2/l/C3F33OLORAASNIYB3ZDATH2HJ7: no such file or directory

Luego, con un poco de prueba y error, resolví este problema ejecutando

(ADVERTENCIA: Esto eliminará todos sus datos dentro de los volúmenes de la ventana acoplable)

docker system prune --volumes -a

Por lo tanto, no se recomienda realizar limpiezas tan sucias a menos que comprenda completamente cómo funciona el sistema.

Todo en / var / lib / docker son sistemas de archivos de contenedores. Si detiene todos sus contenedores y los poda, debería terminar con la carpeta vacía. Probablemente no quieras eso, así que no borres cosas al azar allí. No elimine cosas en / var / lib / docker directamente. Puede que a veces te salgas con la tuya, pero no es aconsejable por muchas razones.

Haz esto en su lugar:

sudo bash
cd /var/lib/docker
find . -type f | xargs du -b  | sort -n

Lo que verá son los archivos más grandes que se muestran en la parte inferior. Si lo desea, averigüe en qué contenedores están esos archivos, ingrese esos contenedores docker exec -ti containername -- /bin/shy elimine algunos archivos.

También puede realizar docker system prune -a -fun trabajo cron diario / semanal siempre que no deje contenedores y volúmenes detenidos que le interesen. Es mejor averiguar las razones por las que está creciendo y corregirlas a nivel de contenedor.

Recientemente tuve un problema similar, overlay2 se hizo cada vez más grande, pero no pude averiguar qué consumía la mayor parte del espacio.

df me mostró que overlay2 tenía un tamaño aproximado de 24 GB.

Con dutraté de averiguar qué ocupaba el espacio ... y fallé.

La diferencia provino del hecho de que los archivos eliminados (principalmente archivos de registro en mi caso) todavía estaban siendo utilizados por un proceso (Docker). Por lo tanto, el archivo no aparece con, dupero el espacio que ocupa se mostrará con df.

Un reinicio de la máquina host ayudó. Reiniciar el contenedor de la ventana acoplable probablemente ya hubiera ayudado ... Este artículo en linuxquestions.org me ayudó a resolver eso.

agregando al comentario anterior, en el que las personas sugieren podar el sistema como volúmenes colgantes claros, imágenes, contenedores de salida, etc., en algún momento su aplicación se vuelve culpable, generó demasiados registros en poco tiempo y si usa un volumen directo vacío (volúmenes locales ) esto llena las particiones / var. En ese caso, encontré el siguiente comando muy interesante para averiguar qué está consumiendo espacio en mi disco de partición / var.

du -ahx / var / lib | sort -rh | cabeza -n 30

Este comando enumerará los 30 primeros, que consume la mayor parte del espacio en un solo disco. Significa que si está utilizando almacenamiento externo con sus contenedores, consume mucho tiempo para ejecutar du command. Este comando no contará los volúmenes de montaje. Y es mucho más rápido. Obtendrá los directorios / archivos exactos que consumen espacio. Luego puede ir a esos directorios y verificar qué archivos son útiles o no. Si estos archivos son necesarios, puede moverlos a algún almacenamiento persistente haciendo un cambio en la aplicación para usar el almacenamiento persistente para esa ubicación o cambiar la ubicación de esos archivos. Y para descansar puedes limpiarlos.

Usé "docker system prune -a" y limpió todos los archivos debajo de los volúmenes y 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 ..