/var/lib/docker crece hasta convertirse en el problema de todo el disco. La solución es un solo comando, pero ejecutarlo a ciegas es como la gente termina borrando la imagen base sobre la que estaba a punto de construir. Primero mira, después limpia.
1. Ver a dónde fue el espacio
$ clai muestra cuánto espacio usa docker y cuánto se puede recuperar→ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 47 13 28.88GB 20GB (69%)Containers 16 9 126.8MB 513.8kB (0%)Local Volumes 38 7 6.311GB 4.084GB (64%)Build Cache 181 0 0B 0BLee la columna RECLAIMABLE antes que nada. Aquí las imágenes son el problema, los volúmenes van segundos, los contenedores son ruido.
2. La limpieza segura
$ clai elimina contenedores detenidos, imágenes huérfanas y redes no usadas→ docker system pruneEl prune normal se lleva los contenedores detenidos, las imágenes huérfanas (capas sin ninguna etiqueta), las redes no usadas y la caché de build. No toca las imágenes etiquetadas ni los volúmenes. Este puedes ejecutarlo sin pensarlo dos veces.
3. La limpieza agresiva
$ clai elimina todas las imágenes que ningún contenedor en ejecución está usando→ docker system prune -a⚠ CAUTION — elimina toda imagen no usada por un contenedor en ejecución-a amplía "no usada" de sin etiqueta a no usada ahora mismo por ningún contenedor en ejecución. Tu imagen base de 4 GB, descargada con cuidado, cuenta como no usada si ahora mismo no hay nada corriendo — la volverás a descargar en el próximo build.
4. Volúmenes: el espacio que nadie espera
$ clai lista los volúmenes de docker que ningún contenedor está usando→ docker volume ls -qf dangling=truePrune se salta los volúmenes por defecto, a propósito — ahí viven las bases de datos. Primero lista, reconoce los nombres, y solo entonces decide. docker volume prune borra datos que, por definición, no tienen copia de seguridad.
5. Solo la caché de build
$ clai limpia la caché de build de docker con más de una semana→ docker builder prune --filter 'until=168h'En una máquina de CI, esto suele ser la ganancia más grande y más segura. --filter until= te deja conservar las capas recientes, así el próximo build sigue siendo rápido.
6. Que no vuelva a pasar
$ clai limita los logs de los contenedores docker a 10 megabytes y 3 archivos→ sudo tee /etc/docker/daemon.json <<'EOF'{"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}}EOFLos logs de los contenedores no tienen rotación por defecto. Este es el único ajuste que evita el fallo más habitual. Se aplica a los contenedores creados después de reiniciar el demonio.
Trampas
prune -asin nada corriendo lo borra todo. La definición de "en uso" es un contenedor en ejecución, no una imagen que te gusta. Arranca tu stack primero, o usa--filter 'until=720h'en su lugar.- Prune no reduce un disco lleno en Docker Desktop. En macOS y Windows la imagen de disco de la VM no le devuelve espacio al host automáticamente.
- Un volumen borrado desaparece. No hay papelera. Haz copia de seguridad antes de limpiar volúmenes, siempre.
Preguntas relacionadas
¿Cuál es la diferencia entre docker system prune y docker image prune -a? system prune cubre contenedores, redes, imágenes y caché de build de una vez; image prune -a solo elimina imágenes, pero también las etiquetadas.
¿Por qué /var/lib/docker/overlay2 es tan grande? Son las capas de imágenes y contenedores. No borres nada ahí a mano — los metadatos viven en otro lugar y acabarás corrompiendo el almacén de imágenes. Usa prune.
¿Puedo ver qué imagen es la más grande? docker image ls --format '{{.Size}}\t{{.Repository}}:{{.Tag}}' | sort -rh las ordena.
Ver también
- Docker y Kubernetes: la memoria muscular, sustituida
- df dice que el disco está lleno, du dice que no
- Limpia logs y backups viejos con una frase
CliAI marca prune -a como CAUTION y pregunta antes de ejecutarlo — porque la diferencia entre los dos prune son 20 GB de descargas repetidas. Instálalo en una línea.