Error de Docker: no queda espacio en el dispositivo

329

Instalé docker en una máquina Debian 7 de la siguiente manera

$ echo deb http://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list
$ sudo apt-get update
$ curl -sSL https://get.docker.com/ubuntu/ | sudo sh

Después de eso, cuando intenté crear una imagen por primera vez, falló con el siguiente error

 time="2015-06-02T14:26:37-04:00" level=info msg="[8] System error: write /sys/fs/cgroup/docker/01f5670fbee1f6687f58f3a943b1e1bdaec2630197fa4da1b19cc3db7e3d3883/cgroup.procs: no space left on device"

Aquí está la información del acoplador

Containers: 2
Images: 21
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 25
Dirperm1 Supported: true
Execution Driver: native-0.2
Kernel Version: 3.16.0-0.bpo.4-amd64
Operating System: Debian GNU/Linux 7 (wheezy)
CPUs: 2
 Total Memory: 15.7 GiB


WARNING: No memory limit support
 WARNING: No swap limit support

¿Cómo puedo aumentar la memoria? ¿Dónde se almacenan las configuraciones del sistema?

De las sugerencias de Kal:

Cuando me deshice de todas las imágenes y contenedores, liberó algo de espacio y la construcción de la imagen se ejecutó por más tiempo antes de fallar con el mismo error. Entonces, la pregunta es, ¿a qué espacio se refiere esto y cómo lo configuro?

user_mda
fuente
1
A veces, puede alcanzar un límite de tamaño por contenedor , dependiendo de su back-end de almacenamiento. Ese enlace muestra cómo solucionarlo para devicemapper.
jpaugh
44
Tuve este error cuando mi disco se quedó sin inodos. Compruebedf -ih
Kevin Smyth
@KevinSmyth Muchas gracias por señalar esto. Ni siquiera era consciente de la importancia de los límites de inodo antes de esto.
yosefrow

Respuestas:

337

Tuve el mismo error y lo solucioné de esta manera:

1) Elimine los volúmenes huérfanos en Docker, puede usar el comando incorporado de volumen docker. El comando incorporado también elimina cualquier directorio en / var / lib / docker / volume que no sea un volumen, así que asegúrese de no poner nada allí que desee guardar.

Advertencia, tenga mucho cuidado con esto si tiene algunos datos que desea conservar

Limpiar:

$ docker volume rm $(docker volume ls -qf dangling=true)

Comandos adicionales:

Lista de volúmenes colgantes:

$ docker volume ls -qf dangling=true

Listar todos los volúmenes:

$ docker volume ls

2) También considere eliminar todas las imágenes no utilizadas.

Primero, elimine las <none>imágenes (a veces se generan mientras se construye una imagen y si por alguna razón la construcción de la imagen se interrumpió, permanecen allí).

aquí hay un buen script que uso para eliminarlos

docker rmi $(docker images | grep '^<none>' | awk '{print $3}')

Luego, si está utilizando Docker Compose para crear imágenes localmente para cada proyecto. Terminará con muchas imágenes generalmente nombradas como su carpeta (ejemplo, si su carpeta de proyecto llamada Hola, encontrará el nombre de las imágenes Hello_blablabla). así que también considera eliminar todas estas imágenes

puede editar el script anterior para eliminarlos o eliminarlos manualmente con

docker rmi {image-name}

Mahmoud Zalt
fuente
23
Solo una nota: los comandos awk en una Mac deben estar entre comillas simples, no dobles, de lo contrario simplemente se ignora.
ndtreviv
2
¡Estoy en MAC y está funcionando para mí! Pero gracias por el consejo.
Mahmoud Zalt
2
¡Que extraño! A mi no me funciona. Simplemente imprime los mismos resultados que el grep. Ah bueno. Cosas más extrañas han sucedido.
ndtreviv
3
En este punto, puede usar el mismo filtro para imágenes. docker images -qf dangling=truey, por supuesto, eliminarlos con docker rmi $(docker images -qf dangling=true).
Tyler Jones
3
Aparece un error: "docker volume rm" requiere al menos 1 argumento (s).
IgorGanapolsky
331

ACTUALIZACIÓN
Los siguientes comandos se han convertido en hacks a medida que Docker se desarrolla más. La mejor práctica actual es

docker system prune

Esto eliminará:

- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all dangling images

Como a continuación, esto es nuclear.


Para limpiar su sistema, primero retire los contenedores

$ docker rm $(docker ps -aq)

luego elimine las imágenes

$ docker rmi $(docker images -q)

Por supuesto, esto es nuclear y eliminará todos los contenedores y todas las imágenes. Puede eliminarlos uno a la vez a través de docker rm #CONTAINER_ID#y docker rmi #IMAGE_ID.

Joshua Cook
fuente
2
como señaló Kevin Smyth, es probable que este error se deba a que te estás quedando sin inodos con los que puedes ver df -ih. Para diagnosticar más quirúrgicamente, ingrese ncduy presione c para contar archivos y C para ordenar por recuento de archivos para obtener una estimación aproximada de lo que está usando todos sus inodos. Si el problema es realmente docker, los directorios usarán la mayor cantidad de inodos de inmediato.
yosefrow
2
Realmente, esto debería ser votado y hecho una respuesta, ya que es el enfoque correcto. El ambiente para la construcción se contaminó y ahora piratear aquí y allá podría solucionarlo temporalmente, pero el enfoque adecuado debería serdocker system prune
zhrist
@zhrist Jaja Estoy de acuerdo
Joshua Cook
@ coler-j Quizás ... si estás pensando en términos de la pregunta original altamente específica. Pero seamos honestos el uno con el otro. La mayoría de las personas no encuentran esta pregunta debido al oscuro caso de uso de los OP, sino porque su caché de la ventana acoplable simplemente se quedó sin espacio.
Joshua Cook
@JoshuaCook en realidad es un problema muy común: github.com/docker/for-win/issues/1042 sin una solución real. Solo tratar de llegar a la raíz de la causa y es muy frustrante. :(
coler-j
70

Compruebe que tiene espacio libre en / var, ya que aquí es donde Docker almacena los archivos de imagen de forma predeterminada (en / var / lib / docker).

Primero limpie las cosas usando docker ps -apara enumerar todos los contenedores (incluidos los detenidos) y docker rmpara eliminarlos; luego use docker imagespara enumerar todas las imágenes que ha almacenado y docker rmipara eliminarlas.

Luego cambie la ubicación de almacenamiento con una opción -g en el docker daemon o editando /etc/default/dockery agregando la -gopción DOCKER_OPTS. -gespecifica la ubicación del "tiempo de ejecución de Docker", que es básicamente todo lo que Docker crea a medida que crea imágenes y ejecuta contenedores. Elija una ubicación con mucho espacio ya que el espacio en disco utilizado tenderá a crecer con el tiempo. Si edita /etc/default/docker, deberá reiniciar el demonio docker para que el cambio surta efecto.

Ahora debería poder crear una nueva imagen (o extraer una de Docker Hub) y debería ver un montón de archivos que se crean en el directorio que especificó con la opción -g.

Kal
fuente
Gracias Kal, no pude encontrar la documentación en DOCKER_OPTS. ¿Qué significa la opción -g y en qué se debe establecer? ¿También se pueden eliminar las cosas debajo de docker / aufs / mnt?
user_mda
Hola, Ruby, creo que nunca encontré un documento real sobre DOCKER_OPTS, pero hay lugares aquí y allá en la documentación que hablan de editarlo. Lo más cercano que puedo encontrar es al final de docs.docker.com/installation/ubuntulinux/… donde habla sobre la edición de la configuración de DNS en DOCKER_OPTS. Las opciones en DOCKER_OPTS se pasan al daemon, por lo que la referencia es docs.docker.com/reference/commandline/cli/#daemon . -g establece la ubicación base del "tiempo de ejecución Docker"
Kal
¿También se pueden eliminar las cosas debajo de docker / aufs / mnt?
user_mda
No elimines esas cosas manualmente. En su lugar, elimine los contenedores (incluidos los salidos) y las imágenes que no necesita. Debe hacer esto antes de cambiar la opción -g. Use docker ps -apara enumerar todos los contenedores (incluidos los salidos) y luego docker rmpara eliminarlos. Use docker imagespara enumerar todas las imágenes y luego docker rmipara eliminarlas. Con suerte, eso debería limpiar todo (o la mayoría de las cosas).
Kal
Gracias, por lo que borrar las imágenes y los contenedores despejó algo de espacio. Pero la imagen más nueva todavía necesita más. Sin embargo, ¿a qué debe apuntar el tiempo de ejecución de la ventana acoplable ?, ¿hay alguna manera de aumentar el espacio utilizado por la ventana acoplable para almacenar imágenes?
user_mda
38

Como ya fue mencionado,

docker system prune

ayuda, pero con Docker 17.06.1 y posterior sin recortar volúmenes no utilizados. Desde Docker 17.06.1, el siguiente comando también elimina los volúmenes:

docker system prune --volumes

De la documentación de Docker: https://docs.docker.com/config/pruning/

El comando de poda del sistema docker es un acceso directo que poda imágenes, contenedores y redes. En Docker 17.06.0 y versiones anteriores, los volúmenes también se podan. En Docker 17.06.1 y versiones posteriores, debe especificar el indicador --volumes para la poda del sistema de docker para podar volúmenes.

Si desea podar volúmenes y conservar imágenes y contenedores:

docker volume prune
RoBeaToZ
fuente
3
docker volume pruneme ayudó hoy cuando todas las otras soluciones aquí dejaron de funcionar.
AVProgrammer
1
Enorme ayuda: además de corregir el error, esto liberó muchos conciertos de espacio en mi disco duro.
Matt Browne
29

Si es solo una instalación de prueba de Docker (es decir, no producción) y no le importa hacer una limpieza nuclear, puede:

limpiar todos los contenedores: docker ps -a | sed '1 d' | awk '{print $1}' | xargs -L1 docker rm

limpiar todas las imágenes: docker images -a | sed '1 d' | awk '{print $3}' | xargs -L1 docker rmi -f

Una vez más, uso esto en mis instancias ec2 cuando desarrollo Docker, no en ninguna ruta de control de calidad o producción seria. Lo mejor es que si tiene su Dockerfile (s), es fácil de reconstruir y / o docker pull.

James
fuente
1
En mi instancia de boot2docker tuve que llamar docker images -a | sed '1 d' | awk '{print $3}' | xargs docker rmi -f. La versión OS X BSD de xargsadmite la -Lopción, a diferencia de la versión de boot2docker.
orluke
1
Puede usar docker ps -a -qetc. para evitar las manipulaciones de texto, es decir, docker rm $(docker ps -a -q); docker rmi -f $(docker images -a -q)debería hacer el truco
Niklas B.
21

para eliminar todos los contenedores, volúmenes, redes e imágenes no utilizados a la vez ( https://docs.docker.com/engine/reference/commandline/system_prune/#related-commands ):

docker system prune -a -f --volumes

Si no es suficiente, primero se pueden eliminar los contenedores en ejecución:

docker rm -f $(docker ps -a -q)
docker system prune -a -f --volumes

aumentar / var / lib / docker o usar otra ubicación con más espacio también es una buena alternativa para deshacerse de este error (consulte ¿Cómo cambiar el directorio de instalación de la imagen del acoplador? )

Guillaume
fuente
docker system pruneNo elimina los volúmenes.
Bonifacio2
1
docker system prune -a -f --volumeseliminará los volúmenes.
Jimson Kannanthara James
19

Docker para Mac

Entonces, docker system pruney docker system prune --volumessugerido en otras respuestas, liberé algo de espacio cada vez, pero eventualmente cada vez que ejecutaba algo recibía el error.

Lo que realmente solucionó el problema raíz fue eliminar el Docker.rawarchivo que Docker para Mac usa para el almacenamiento y reiniciarlo.

Para encontrar ese archivo, abra Docker para Mac y vaya a *

Preferences > Resources > Advanced > Disk Image Location

* esto es para la versión 2.2.0.5, pero en versiones anteriores debería ser similar

En las versiones más recientes de Docker para Mac **, muestra el tamaño real de ese archivo en el disco allí mismo en la interfaz de usuario, así como su tamaño máximo asignado. Probablemente verás que es masivo. ¡Por ejemplo, en mi máquina pesaba 41 GB !

** En versiones anteriores, no muestra el uso real del disco en la interfaz de usuario, y MacOS Finder siempre muestra el tamaño del archivo como el tamaño máximo asignado. Puede verificar el tamaño real en el disco abriendo el directorio en una terminal y ejecutandodu -h Docker.raw

Eliminé Docker.raw, reinicié Docker para Mac, y el archivo se creó automáticamente de nuevo y volvió a tener 0 GB .

Todo siguió funcionando como antes , aunque, por supuesto, había perdido mi caché de Docker. Como era de esperar, después de ejecutar algunos comandos de Docker, el archivo comenzó a llenarse nuevamente con unos pocos GB de cosas, pero ni siquiera cerca de 41 GB.


Actualizar

Unos meses más tarde, Docker.rawvolví a llenar a un tamaño similar. Así que este método funcionó, pero tiene que repetirse cada pocos meses. Para mí eso está bien.

Una nota sobre por qué funciona esto: tengo que asumir que es un error en Docker para Mac. Realmente parece que docker system prune/ docker system prune --volumesdebería borrar por completo el contenido de este archivo, pero parece que el archivo acumula otras cosas que estos comandos no pueden eliminar. De todos modos, ¡eliminarlo manualmente resuelve el problema!

davnicwil
fuente
15

Docker deja imágenes colgantes alrededor que pueden ocupar tu espacio. Para limpiar después de Docker, ejecute lo siguiente:

docker image prune [-af if you want to force remove all images]

o con versiones anteriores de Docker:

docker rm $(docker ps -q -f 'status=exited')
docker rmi $(docker images -q -f "dangling=true")

Esto eliminará las imágenes salidas y colgantes, lo que con suerte despejará el espacio del dispositivo.

punkrockpolly
fuente
14
  1. Limpiar imágenes colgadas docker rmi $(docker images -f "dangling=true" -q)
  2. Eliminar volúmenes no deseados
  3. Eliminar imágenes no utilizadas
  4. Retire los contenedores no utilizados
josepainumkal
fuente
Para mí, el problema era tener demasiadas imágenes. Después de limpiarlos, Docker funciona nuevamente.
Tran Triet
9

también puedes usar:

docker system prune

o solo para volúmenes:

docker volume prune
alexanoid
fuente
7

En mi caso, la instalación de ubuntu-server 18.04.1 [por alguna extraña razón] creó un volumen lógico LVM con solo 4 GB de tamaño en lugar de 750 GB. Por lo tanto, al extraer imágenes, me daría este error "no queda espacio en el dispositivo". La solución es simple:

lvextend -l 100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
Kostyantyn
fuente
.. vea mi descripción paso a paso para resize2fs en el siguiente hilo: stackoverflow.com/questions/32485723/…
Alex
7

También encontré este problema en la máquina RHEL. No encontré ninguna solución adecuada en ninguna parte de la comunidad de desbordamiento de pila y docker-hub. Si enfrenta este problema incluso después del siguiente comando:

podar sistema docker --todos

La solución que finalmente funcionó:

  1. información del acoplador
    • Para verificar el controlador de almacenamiento de la ventana acoplable actual
    • El mío fue: Controlador de almacenamiento: devicemapper; Si tiene un controlador de almacenamiento como overlay2, no debe preocuparse. La solución seguirá funcionando para usted.
  2. df -h
    • Esto es para verificar los sistemas de archivos disponibles en la máquina y la ruta donde están montados. Dos rutas montadas para tener una nota:
    • / dev / mapper / rootvg-var 7.6G 1.2G 6.1G 16% / var
    • / dev / mapper / rootvg-apps 60G 9.2G 48G 17% / apps
    • Nota - Por defecto, la ruta de almacenamiento de la ventana acoplable es / var / lib / docker. Tiene espacio disponible ~ 6 GB y, por lo tanto, todos los problemas relacionados con el espacio. Básicamente, tengo que mover el almacenamiento predeterminado a otro almacenamiento donde el espacio disponible es mayor. Para mí, la ruta del archivo sysyem '/ dev / mapper / rootvg-apps' que está montada en / apps. Ahora la tarea es mover / var / lib / docker a algo como / apps / newdocker / docker.
  3. mkdir / apps / newdocker / docker
  4. chmod -R 777 / apps / newdocker / docker
  5. Actualice el archivo docker.serive en Linux que se encuentra en: / usr / lib / systemd / system
    • vi /usr/lib/systemd/system/docker.service
  6. si el dispositivo de almacenamiento es devicemapper, comente la línea ExecStart existente y agregue a continuación en [Servicio]:
    • ExecStart =
    • ExecStart = / usr / bin / dockerd -s devicemapper --storage-opt dm.fs = xfs --storage-opt dm.basesize = 40GB -g / apps / newdocker / docker --exec-opt native.cgroupdriver = cgroupfs
  7. O si el dispositivo de almacenamiento está superpuesto2:
    • simplemente agregue -g / apps / newdocker / docker en la declaración ExexStart existente.
    • Algo así como ExecStart = / usr / bin / dockerd -g / apps / newdocker / docker -H fd: // --containerd = / run / containerd / containerd.sock
  8. rm -rf / var / lib / docker (eliminará todos los datos existentes de la ventana acoplable)
  9. systemctl stop docker
  10. ps aux | grep -i docker | grep -v grep
    • Si el comando anterior no ha producido ningún resultado, vuelva a cargar el demonio systemd mediante el siguiente comando.
  11. systemctl daemon-reload
  12. systemctl start docker
  13. información del acoplador
    • Consulte el espacio de datos disponible: 62.15 GB después de enrutar a la ventana acoplable al nuevo sistema de archivos.
  14. HECHO
Mayank Chaudhary
fuente
¡He estado buscando en todos los documentos cómo lograr esto! Gracias Señor. ¿Podemos marcar esto como una de las respuestas?
Vulegend
6

Limpie Docker utilizando el siguiente comando:

docker images --no-trunc | grep '<none>' | awk '{ print $3 }' \
| xargs docker rmi
Ashok Waghmare
fuente
4

Sus cgroups tienen el cpusetcontrolador habilitado. Este controlador es principalmente útil en un entorno NUMA donde permite especificar con precisión qué CPU / banco de memoria pueden ejecutar sus tareas.

Por defecto, los obligatorios cpuset.memsy cpuset.cpusno están configurados, lo que significa que "no queda espacio" para su tarea, de ahí el error.

La forma más fácil de solucionar esto es habilitar cgroup.clone_children1 en el cgroup raíz. En tu caso, debería ser

echo 1 > /sys/fs/cgroup/docker/cgroup.clone_children

Básicamente le indicará al sistema que inicialice automáticamente los contenedores cpuset.memsy cpuset.cpusdesde su cgroup primario.

yadutaf
fuente
1
Esta es la respuesta correcta. Realmente, simplemente actualizar Docker a cualquier cosa> = Docker 1.8 debería resolverlo. Esto está relacionado con github.com/opencontainers/runc/issues/133 Del problema, otra posible echo 0 > /sys/fs/cgroup/cpuset/system.slice/cpuset.mems
solución alternativa
2

Si está utilizando la imagen boot2docker a través de Docker Toolkit, el problema se debe al hecho de que la máquina virtual boot2docker se ha quedado sin espacio.

Cuando hace docker importo agrega una nueva imagen, la imagen se copia en la /mnt/sda1que podría haberse llenado.

Una forma de verificar qué espacio tiene disponible en la imagen, es ingresar en el vm y ejecutar df -hy verificar el espacio restante en / mnt / sda1

El comando ssh es docker-machine ssh default

Una vez que esté seguro de que se trata de un problema de espacio, puede limpiar de acuerdo con las instrucciones de algunas de las respuestas a esta pregunta, o puede elegir cambiar el tamaño de la imagen boot2docker, aumentando el espacio en /mnt/sda1

Puede seguir las instrucciones aquí para cambiar el tamaño de la imagen https://gist.github.com/joost/a7cfa7b741d9d39c1307

Nerrve
fuente
2

Si está utilizando Docker Desktop, puede aumentar el tamaño de la imagen del disco en Configuración avanzada yendo a las Preferencias de Docker .

Aquí está la captura de pantalla de macOS:

Docker Desktop en macOS, Recursos, Avanzado, Tamaño de imagen de disco

kenorb
fuente
1

Puede deberse al espacio de almacenamiento predeterminado establecido en 40 GB (ruta predeterminada, / var / lib / docker)

puede cambiar el volumen de almacenamiento para apuntar a una ruta diferente

  • editar archivo -> / etc / sysconfig / docker-storage
  • actualizar debajo de la línea (agregar si no existe)

DOCKER_STORAGE_OPTIONS = '- controlador de almacenamiento = superposición --graph = CUSTOM_PATH'

  • Reiniciar docker systemctl detener docker systemctl daemon-reload systemctl iniciar docker

si ejecuta la información de la ventana acoplable de comandos (debe mostrar el controlador de almacenamiento como superposición)

Ajit Ganiger
fuente
0

Parece que hay algunas maneras en que esto puede ocurrir. El problema que tuve fue que la imagen del disco acoplable había alcanzado su tamaño máximo (Docker Whale -> Preferencias -> Disco si desea ver qué tamaño tiene OSX).

Subí el límite y ya estaba listo. Estoy seguro de que limpiar las imágenes no utilizadas también funcionaría.

SnellyBigoda
fuente
0

Ejecuto los siguientes comandos.

No hay necesidad de reconstruir imágenes después.

docker rm $(docker ps -qf 'status=exited')
docker rmi $(docker images -qf "dangling=true")
docker volume rm $(docker volume ls -qf dangling=true)

Estos eliminan los contenedores salidos / colgantes y los volúmenes colgantes.

M3RS
fuente
0

Para mí docker system prunehizo el truco. Estoy ejecutando mac os.

Bildad N. Urandu
fuente
En realidad, esto también funcionó en el mío, cuando estaba tratando de limpiar el espacio utilizado en Mac OS. el uso del comando docker volume lsno devolvía nada, por lo que parecía que el almacenamiento era utilizado principalmente por cachés e imágenes colgantes.
Tuhin
-3
$ docker rm $(docker ps -aq)

Esto funciono para mi

docker system prune 

parece ser una mejor opción con la última versión

htnawsaj
fuente