Docker
Images, layers, cache, containers, volumes y políticas de retención.
Docker consume disco en varias categorías con ciclos de vida distintos. Limpiar correctamente significa identificar qué es recreable, qué es evidencia y qué contiene datos irremplazables.
images/layers → artefactos descargables o construibles
build cache → aceleración recreable
containers → instancias y writable layers
logs → evidencia operativa
volumes → estado potencialmente críticodocker system prune -a --volumes no es mantenimiento: es una operación destructiva de amplio alcance.
df -h
df -i
docker system df
docker system df -vdf -h detecta bytes agotados. df -i detecta inodes agotados: millones de archivos pequeños pueden impedir nuevas escrituras aunque queden gigabytes.
Comprueba también dónde está el data root:
docker info --format '{{.DockerRootDir}}'En instalaciones modernas el almacenamiento puede usar diferentes backends/image stores. No manipules archivos internos directamente; usa APIs y comandos soportados.
Incluyen:
El tamaño reportado por imagen puede contar contenido compartido de manera que no equivale a espacio liberable. Revisa SHARED SIZE y UNIQUE SIZE donde estén disponibles.
BuildKit conserva:
Puede crecer mucho en hosts de CI.
Un container detenido conserva:
Un proceso que escribe uploads o caches en writable layer puede producir gigabytes invisibles en la image.
Pueden contener:
“Unused” significa no adjunto en ese momento, no “sin valor”.
Un container activo puede llenar el host aunque no se construya ninguna image.
docker ps -a --size
docker container ls -aRevisa:
Eliminar stopped containers suele ser seguro solo después de preservar logs/evidencia y confirmar que no son la única referencia comprensible a un volume.
docker container pruneElimina containers detenidos que coincidan con los filtros.
Mejor:
docker container prune --filter 'until=168h'Usa retención. No borres inmediatamente containers de un deployment fallido si necesitas investigar.
docker image ls --digests
docker image ls --filter dangling=true
docker image inspect imageUna image dangling no tiene tag útil, pero puede estar referenciada por un container o ser necesaria para análisis.
Solo dangling:
docker image pruneTodas las no usadas por containers:
docker image prune -a-a puede eliminar el digest anterior necesario para rollback. Define retención explícita antes.
Conserva como mínimo:
El registry debe ser la fuente durable, pero depender de descargar durante un outage puede aumentar RTO. Decide si el host conserva una ventana local.
docker buildx du
docker builder prune
docker buildx pruneLas capacidades exactas dependen del builder/versión.
Ejemplos:
docker builder prune --filter 'until=168h'
docker builder prune --keep-storage 20GBObjetivo: conservar cache reciente/de valor y limitar crecimiento.
No elimines cache automáticamente en cada build: pierdes rendimiento, aumenta tráfico y puede ocultar que el Dockerfile tiene mal orden.
Política sugerida:
Una cache es recreable, pero su reconstrucción puede tardar horas. Limpia con presupuesto, no por reflejo.
docker volume ls
docker volume inspect volume-nameAntes de eliminar pregunta:
docker volume prunePuede borrar volumes no referenciados por containers. Un database container eliminado antes puede dejar su volume “unused”.
Nunca automatices volume prune global en producción sin inventario, exclusions, ownership y backups.
docker run --rm \
--mount type=volume,src=my-volume,dst=/data,readonly \
alpine sh -c 'du -sh /data; find /data -maxdepth 2 -type f | head'Usa image/herramientas apropiadas y evita alterar permisos o metadata. Para databases, inspección de archivos no reemplaza herramientas del motor.
Añade ownership:
volumes:
db-data:
labels:
com.nicoo.owner: platform
com.nicoo.environment: production
com.nicoo.retention: criticalTambién en containers/images cuando sea posible.
Labels no protegen por sí solos, pero permiten filtros y automatización segura.
Compose crea resources prefijados. Cambiar directorio o project name puede dejar:
oldproject_db-data
newproject_db-dataEl antiguo parece huérfano pero contiene datos reales.
Antes de limpiar:
docker compose ls
docker volume lsdocker compose downconserva named volumes normalmente.
docker compose down -vlos elimina. Usa -v solo en entornos efímeros o cuando la destrucción es intencional y confirmada.
Inspecciona logging driver:
docker inspect container --format '{{json .HostConfig.LogConfig}}'
docker info --format '{{.LoggingDriver}}'Configura rotación:
max-size
max-filesegún driver.
Centralización no elimina necesidad de límite local: un collector caído puede provocar buffer o crecimiento.
No trunques archivos internos del driver manualmente salvo procedimiento soportado. Puedes corromper metadata o perder evidencia.
docker ps -a --sizeSi crece:
Corrección:
Eliminar el container libera writable layer, pero también elimina esos datos.
Síntomas:
No space left on deviceaunque df -h muestra espacio.
df -iCausas:
node_modules repetidos;Investiga cantidad, no solo tamaño.
El almacenamiento vive en una disk image/VM. Borrar objetos puede liberar espacio dentro del filesystem, pero el archivo del host no siempre se reduce inmediatamente.
Usa herramientas de Docker Desktop para disk usage/reclaim. No edites la disk image manualmente.
Monitorea:
Umbrales deben dejar tiempo para actuar. Alertar al 99 % es tarde.
Ejemplo:
Necesitas espacio temporal para:
No operes habitualmente al 90 %.
Define por categoría:
containers fallidos: 7 días
images release: últimas 5 + 30 días
build cache: 20 GB o 7 días
logs locales: 3 × 50 MB por container
volumes production: nunca por prune automático
CI projects: borrar al finalizarAjusta al RTO y coste.
Un job seguro:
No uses un único comando global sin visibilidad.
Prioridad:
Candidatos de bajo riesgo, después de verificar:
No empieces por volumes.
A veces es más seguro expandir filesystem que ejecutar prune bajo presión.
Después:
Capacidad extra sin política solo aplaza el incidente.
Mover el almacenamiento requiere:
No hagas mv /var/lib/docker con daemon activo.
Una image o stopped container puede ser evidencia de compromiso. Antes de cleanup durante incidente consulta el plan de seguridad.
Preserva:
Registry inaccesible durante recovery.
Última copia de database tras borrar instancia.
Requiere rotación y limpieza controlada, no solo prune.
docker logs puede no mostrar todo, pero buffers locales consumen disco.
Un proceso mantiene file descriptor abierto. Reinicio controlado puede ser necesario; verifica con herramientas del host.
Tamaño aparente y real difieren.
Pérdida de datos/rollback.
Puede haber referencia operacional.
El problema permanece.
Builds lentos y registry saturado.
Incidente recurrente.
Cleanup o pérdida del host los elimina.
Corrupción del estado interno.
df -h y df -i.docker system df -v.Antipatrones de Docker, donde se reúnen decisiones que parecen resolver el problema inmediato pero degradan seguridad, reproducibilidad u operación.