tag run remove library hub compose docker diskspace device-mapper

run - ¿Por qué la imagen de Docker está consumiendo mi espacio en disco que Docker no utiliza?



docker-compose (9)

He configurado la ventana acoplable y he usado un dispositivo de bloque completamente diferente para almacenar los datos del sistema de la ventana acoplable:

[root@blink1 /]# cat /etc/sysconfig/docker # /etc/sysconfig/docker other_args="-H tcp://0.0.0.0:9367 -H unix:///var/run/docker.sock -g /disk1/docker"

Tenga en cuenta que /disk/1 está utilizando un disco duro completamente diferente /dev/xvdi

Filesystem Size Used Avail Use% Mounted on /dev/xvda1 7.8G 5.1G 2.6G 67% / devtmpfs 1.9G 108K 1.9G 1% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm /dev/xvdi 20G 5.3G 15G 27% /disk1 /dev/dm-1 9.8G 1.7G 7.6G 18% /disk1/docker/devicemapper/mnt/bb6c540bae25aaf01aedf56ff61ffed8c6ae41aa9bd06122d440c6053e3486bf /dev/dm-2 9.8G 1.7G 7.7G 18% /disk1/docker/devicemapper/mnt/c85f756c59a5e1d260c3cdb473f3f4d9e55ac568967abe190eeaf9c4087afeac

El problema es que cuando continúo descargando imágenes de Docker y ejecuto contenedores de Docker, parece que el otro disco duro /dev/xvda1 también está agotado.

Puedo verificar este problema eliminando algunas imágenes acoplables. Después de eliminar algunas imágenes de la /dev/xvda1 acoplable, /dev/xvda1 tiene más espacio adicional ahora.

¿Me estoy perdiendo de algo?

Mi versión de docker:

[root@blink1 /]# docker info Containers: 2 Images: 42 Storage Driver: devicemapper Pool Name: docker-202:1-275421-pool Pool Blocksize: 64 Kb Data file: /disk1/docker/devicemapper/devicemapper/data Metadata file: /disk1/docker/devicemapper/devicemapper/metadata Data Space Used: 3054.4 Mb Data Space Total: 102400.0 Mb Metadata Space Used: 4.7 Mb Metadata Space Total: 2048.0 Mb Execution Driver: native-0.2 Kernel Version: 3.14.20-20.44.amzn1.x86_64 Operating System: Amazon Linux AMI 2014.09

Es un problema de kernel con devicemapper, que afecta a la familia de sistemas operativos RedHat (RedHat, Fedora, CentOS y Amazon Linux). Los contenedores eliminados no liberan espacio en disco asignado. Esto significa que en los sistemas operativos afectados se quedará sin espacio lentamente a medida que inicia y reinicia los contenedores.

El proyecto Docker es consciente de esto, y el núcleo supuestamente está arreglado en sentido ascendente ( https://github.com/docker/docker/issues/3182 ).

Una solución alternativa es darle a Docker su propio volumen para escribir ( "Cuando Docker te consume espacio en el disco" ). En realidad, esto no impide que coma espacio, solo que derribe otras partes de su sistema después de que lo haga.

Mi solución fue desinstalar Docker, luego eliminar todos sus archivos, luego reinstalar:

sudo yum remove docker sudo rm -rf /var/lib/docker sudo yum install docker

Esto recuperó mi espacio, pero no es muy diferente a solo lanzar una instancia de reemplazo. No he encontrado una mejor solución.

La poda de Docker por defecto no elimina volúmenes,

puedes probar algo como

docker system prune --volume

Mueva el directorio /var/lib/docker .

Suponiendo que el directorio /data tenga suficiente espacio, si no, sustituya por uno que lo tenga,

# docker ps -qa | xargs docker inspect --format=''{{ .State.Pid }}'' | xargs -IZ fstrim /proc/Z/root/

De esta manera, no tiene que volver a configurar la ventana acoplable.

Sí, Docker usa la carpeta / var / lib / docker para almacenar las capas. Hay formas de recuperar el espacio y mover el almacenamiento a otro directorio.

Puede montar un espacio de disco más grande y mover el contenido de / var / lib / docker a la nueva ubicación de montaje y crear un enlace simbólico.

Hay una explicación detallada sobre cómo hacer la tarea anterior.

http://www.scmtechblog.net/2016/06/clean-up-docker-images-from-local-to.html

También puede eliminar las capas intermedias.

https://github.com/vishalvsh1/docker-image-cleanup

Tuve este problema de vez en cuando en mi MacOS con Engine: 19.03.2 . En mi caso, reconstruir la imagen lleva mucho tiempo y no era una opción viable. Por lo tanto, eliminar las imágenes / podas no era una opción.

La solución fue guardar la imagen en un alquitrán, eliminar la imagen, salir de la ventana acoplable, volver a cargar la imagen desde el archivo tar. Comandos para cada paso de la siguiente manera.

  1. docker save -o <name>.tar <image-name>
  2. docker rmi <image-name>
  3. Salga de Docker (observe que el archivo Docker.qcow2 se encoge después de esto)
  4. Reiniciar la ventana acoplable
  5. docker load -q -i <name>.tar

Pruebe estos pasos para todas las imágenes si el tamaño no se reduce para una sola imagen. Mi sugerencia es comenzar desde imágenes más antiguas en lugar de nuevas. (Puede guardarlos y eliminarlos de una vez).

Referencia: https://dbaontap.com/2017/07/18/clean-qcow2-docker-macbook/

Tuve un problema similar y creo que esto sucede cuando no tienes suficiente espacio en el disco para todas tus imágenes acoplables. Tenía 6 GB reservados para las imágenes de la ventana acoplable, que resultó no ser suficiente en mi caso. De todos modos, había eliminado todas las imágenes y contenedores y aún el disco parecía lleno. La mayoría del espacio estaba siendo utilizado por / var / lib / docker / devicemapper y / var / lib / docker / tmp.

Este comando no funcionó para mí:

# docker ps -qa | xargs docker inspect --format=''{{ .State.Pid }}'' | xargs -IZ fstrim /proc/Z/root/

Primero, detuve el servicio de docker:

sudo service docker stop

Luego eliminé / var / lib / docker:

Luego hice lo que alguien sugirió aquí en https://github.com/docker/docker/issues/18867#issuecomment-232301073

  • Eliminar la instancia existente de los metadatos de docker rm -rf / var / lib / docker

    sudo rm -rf / var / lib / docker

  • Pase las siguientes opciones al docker daemon: -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.mountopt = descartar

  • Inicia docker daemon.

Para los últimos dos pasos, ejecuto:

sudo dockerd -s devicemapper --storage-opt dm.fs=xfs --storage-opt dm.mountopt=discard

tal vez puedas probar la docker system prune para eliminar todas las imágenes que no son importantes

Eliminar todo / var / lib / docker no está bien para mí. Estas son formas más seguras:

Solución 1:

Los siguientes comandos del problema me aclaran el espacio y es mucho más seguro que eliminar / var / lib / docker o Windows para verificar la ubicación de la imagen del disco here .

Antes de:

docker info

Salida de ejemplo:

Metadata file: Data Space Used: 53.38 GB Data Space Total: 53.39 GB Data Space Available: 8.389 MB Metadata Space Used: 6.234 MB Metadata Space Total: 54.53 MB Metadata Space Available: 48.29 MB

Comando en versiones más recientes de Docker, por ejemplo, 17.x +

docker system prune -a

Le mostrará una advertencia de que eliminará todos los contenedores, redes, imágenes y caché de compilación detenidos. En general, es seguro eliminar esto. (La próxima vez que ejecute un contenedor, puede extraerlo del registro de Docker)

Salida de ejemplo:

Total reclaimed space: 1.243GB

Luego puede volver a ejecutar la información del acoplador para ver qué se ha limpiado.

docker info

Solución 2:

Junto con esto, asegúrese de que sus programas dentro del contenedor docker no estén escribiendo muchos / grandes archivos en el sistema de archivos.

Verifique el tamaño de uso de espacio del proceso de Docker en ejecución

docker ps -s #may take minutes to return

o para todos los contenedores, incluso salidos

docker ps -as #may take minutes to return

Luego puede eliminar el / los contenedor (s) ofensivo (s)

docker rm <CONTAINER ID>

Encuentra al posible culpable que puede estar usando conciertos de espacio

docker exec -it <CONTAINER ID> "/bin/sh" du -h

En mi caso, el programa estaba escribiendo conciertos de archivos temporales.

( mencionó en la respuesta aceptada este https://github.com/docker/docker/issues/3182 y obtuve información del problema)

O

Comandos en versiones anteriores de Docker, por ejemplo, 1.13.x (se ejecuta como root, no sudo):

# Delete ''exited'' containers docker rm -v $(docker ps -a -q -f status=exited) # Delete ''dangling'' images (If there are no images you will get a docker: "rmi" requires a minimum of 1 argument) docker rmi $(docker images -f "dangling=true" -q) # Delete ''dangling'' volumes (If there are no images you will get a docker: "volume rm" requires a minimum of 1 argument) docker volume rm $(docker volume ls -qf dangling=true)

Después :

> docker info Metadata file: Data Space Used: 1.43 GB Data Space Total: 53.39 GB Data Space Available: 51.96 GB Metadata Space Used: 577.5 kB Metadata Space Total: 54.53 MB Metadata Space Available: 53.95 MB