¿Por qué la imagen de la ventana acoplable está consumiendo mi espacio en disco que no utiliza la ventana acoplable

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/1está 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 la ventana acoplable y ejecuto contenedores de la ventana acoplable, parece que el otro disco duro /dev/xvda1también está agotado.

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

¿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 del 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 al iniciar y reiniciar los contenedores.

El proyecto Docker es consciente de esto, y el kernel 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 consume su espacio en disco" ). En realidad, esto no le impide comer espacio, simplemente derriba otras partes de su sistema después de que lo hace.

Mi solución fue desinstalar la ventana acoplable, luego eliminar todos sus archivos y 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 simplemente lanzar una instancia de reemplazo. No he encontrado una mejor solución.

Eliminar mi / var / lib / docker completo 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 para Windows, verifique la ubicación de la imagen de su disco aquí .

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. Generalmente es seguro eliminar esto. (La próxima vez que ejecute un contenedor, es posible que se extraiga del registro de Docker)

Salida de ejemplo:

Total reclaimed space: 1.243GB

A continuación, puede volver a ejecutar la información de la ventana acoplable para ver qué se ha limpiado

docker info

Solución 2:

Junto con esto, asegúrese de que sus programas dentro del contenedor de la ventana acoplable no escriban muchos archivos en el sistema de archivos.

Verifique el tamaño de uso de espacio de su 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

A continuación, puede eliminar los contenedores infractores

docker rm <CONTAINER ID>

Encuentre al posible culpable que puede estar usando gigas de espacio

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

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

( Nathaniel Waisbrot mencionó en la respuesta aceptada este problema y obtuve algo de información del problema)

O

Comandos en versiones anteriores de Docker, por ejemplo, 1.13.x (ejecutar como root, no como 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

Mueva el /var/lib/dockerdirectorio.

Suponiendo que el /datadirectorio tiene suficiente espacio, si no, sustitúyalo por uno que lo tenga,

sudo systemctl stop docker

sudo mv /var/lib/docker /data


sudo ln -s /data/docker /var/lib/docker

sudo systemctl start docker

De esta forma, no es necesario volver a configurar la ventana acoplable.

Tuvo el mismo problema. En mi escenario, mi vbox se estaba quedando sin espacio de almacenamiento. Después de una investigación, descubrí que los volúmenes locales de mi Docker consumían 30 GB. Host Ubuntu 16.04.

Para averiguar el tuyo.

docker system df

TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              3                   0                   1.361GB             1.361GB (100%)
Containers          0                   0                   0B                  0B
Local Volumes       7                   0                   9.413GB             9.413GB (100%)
Build Cache                                                 0B                  0B



docker system prune --volumes


  WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all volumes not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N]

Esto libera espacio en disco de volúmenes locales no utilizados. En mi escenario, liberé 20 GB de espacio de almacenamiento. Asegúrese de que los contenedores que desea mantener se estén ejecutando antes de hacer esto si desea conservarlos, ya que esto elimina todos los contenedores detenidos.

Tuve un problema similar y creo que esto sucede cuando no tienes suficiente espacio en el disco para todas tus imágenes de Docker. Tenía 6GB reservados para imágenes de docker 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 parte del espacio estaba siendo utilizada 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 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 metadatos de docker rm -rf / var / lib / docker

  sudo rm -rf / var / lib / docker

• Pase las siguientes opciones al demonio de Docker: -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.mountopt = discard

• Inicie el demonio de la ventana acoplable.

Para los dos últimos pasos, ejecuto:

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

Docker poda de forma predeterminada no elimina volúmenes,

puedes probar algo como

docker volume prune -f

Como se mencionó en el número 18867 - Eliminar datos en un contenedor devicemapper no puede liberar espacio usado de Github.com

Intente ejecutar el siguiente comando:

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

Utiliza la fstrimherramienta para recortar el disco de aprovisionamiento fino del mapeador de dispositivos.

tal vez puedas intentar docker system pruneeliminar todas las imágenes que no son importantes

Para los que se encuentran con este problema en MacOS, la solución que me ha funcionado fue buscar el archivo Docker.raw, que es el que usa Docker para reservar el espacio lógico en el host y luego eliminarlo. Si tiene Docker Desktop, puede ir a:

Preferences -> Resources -> Advancedy luego mire debajo de la Disk image locationpestaña.

Navegue a esa carpeta en la terminal y simplemente elimine el Docker.rawarchivo ( $ rm -rf Docker.raw)

Nota importante : solo haga esto si no necesita ninguna de sus imágenes o volúmenes existentes.

Sí, Docker usa la carpeta / var / lib / docker para almacenar las capas. Hay formas de recuperar el espacio y mover el almacenamiento a algún 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 hacer 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 puedes eliminar las capas intermedias.

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