Sysadmin

Docker Espacio Disco: Prune, Logs y Imágenes

Docker Espacio Disco: Prune, Logs y Imágenes

Recuperar espacio en disco es una de las actividades de mantenimiento más comunes y críticas para quienes gestionan entornos Docker. Imágenes obsoletas, contenedores detenidos, volúmenes huérfanos y, sobre todo, logs no gestionados pueden saturar rápidamente el almacenamiento, llevando a ralentizaciones, errores en las builds y, en los peores casos, al bloqueo completo del servicio. He visto servidores colapsar por un disco lleno en un entorno empresarial con cientos de contenedores, con la consiguiente interrupción de servicios cruciales y horas de trabajo para restablecer la normalidad. La clave es la prevención y una limpieza proactiva, no reactiva, y en este artículo veremos cómo hacerlo de forma eficaz, utilizando los comandos adecuados y configurando Docker para una gestión óptima del espacio.

Tested on: Ubuntu 24.04 LTS · Docker Engine 26.1 · Octubre 2026

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás un sistema Linux con Docker instalado y funcionando. El acceso SSH con privilegios de sudo es necesario para algunas operaciones de configuración y reinicio del demonio Docker. Asegúrate de estar familiarizado con los conceptos básicos de Docker, como imágenes, contenedores y volúmenes.

Entender dónde se consume el espacio: docker system df

El primer paso para liberar espacio es entender dónde se está consumiendo. Docker ofrece un comando específico que proporciona una visión detallada del uso del disco por parte de sus componentes. Este es el punto de partida para cualquier estrategia de limpieza.

docker system df -v

La salida de este comando te mostrará el uso del disco para imágenes, contenedores, volúmenes y caché de build, distinguiendo entre elementos activos y aquellos que pueden ser recuperados. El flag -v (verbose) proporciona detalles adicionales, incluidos los datos sobre los volúmenes.

Componente Descripción
Images Imágenes Docker descargadas o creadas localmente
Containers Espacio ocupado por los contenedores (capas escribibles)
Local Volumes Datos persistentes montados por los contenedores
Build Cache Caché utilizada por el builder Docker para acelerar las builds posteriores

Lee también: Docker Producción: 10 Prácticas de Seguridad Ignoradas (2026)

Imágenes sin uso y dangling

Las imágenes Docker pueden ocupar una cantidad significativa de espacio. A menudo, después de actualizaciones o reconstrucciones, quedan en el sistema imágenes obsoletas o «dangling» (ya no asociadas a una etiqueta o a un contenedor). docker image prune es el comando para gestionarlas.

Para eliminar todas las imágenes no utilizadas (aquellas no asociadas a ningún contenedor):

docker image prune

Para eliminar todas las imágenes no utilizadas, incluidas aquellas no asociadas a contenedores o a etiquetas (las llamadas imágenes «dangling»), añade el flag -a:

docker image prune -a

Si quieres ser más selectivo y eliminar solo las imágenes más antiguas de un cierto período, puedes usar el filtro until:

docker image prune -a --filter "until=168h" # Elimina imágenes más antiguas de 7 días (168 horas)

Contenedores detenidos y volúmenes huérfanos

También los contenedores detenidos y los volúmenes que ya no se usan pueden acumularse. Un contenedor detenido mantiene su capa escribible en el disco, mientras que un volumen huérfano es un volumen persistente que ya no está conectado a ningún contenedor activo.

Para eliminar todos los contenedores detenidos:

docker container prune

Para identificar y eliminar los volúmenes huérfanos, que a menudo contienen datos que ya no son necesarios:

docker volume ls -f dangling=true

Después de verificar que estos volúmenes ya no son necesarios, puedes eliminarlos con:

docker volume prune

La caché de build

Durante el proceso de build de una imagen Docker, se crean capas intermedias que pueden permanecer como caché. Esta caché es útil para acelerar las builds posteriores, pero puede ocupar mucho espacio, especialmente en entornos de desarrollo o CI/CD con muchas builds.

Para limpiar la caché de build:

docker builder prune

Este comando elimina las capas intermedias que ya no son referenciadas por ninguna imagen. Lee también: Ansible vs Scripts: Gestión de 200 Servidores

Logs de contenedores que crecen sin límite

Un problema a menudo subestimado es el crecimiento incontrolado de los logs de los contenedores. Por defecto, Docker no impone límites al tamaño de los archivos de log, que pueden alcanzar dimensiones considerables y saturar el disco en entornos con contenedores muy «verbosos».

Para localizar los archivos de log más grandes, puedes usar este comando:

sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail

Esto te mostrará los 10 archivos de log Docker más grandes, permitiéndote identificar los contenedores que generan más salida.

Configurar la rotación de logs en daemon.json

La solución definitiva para los logs es configurar la rotación directamente en el demonio Docker. Esto impide que los logs crezcan indefinidamente, limitando su tamaño y el número de archivos mantenidos. Debes modificar el archivo /etc/docker/daemon.json.

Si el archivo no existe, créalo. Añade o modifica la sección log-driver y log-opts como sigue:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

En este ejemplo:

  • "max-size": "10m": cada archivo de log tendrá un tamaño máximo de 10 megabytes.
  • "max-file": "3": se mantendrán un máximo de 3 archivos de log por contenedor. Cuando el primer archivo alcanza los 10MB, se rota, y el más antiguo de los 3 se elimina.

Después de modificar el archivo daemon.json, es necesario reiniciar el servicio Docker para aplicar los cambios:

sudo systemctl restart docker

Lee también: Systemd Avanzado: Creación de Servicios y Reincio Automático

Qué NO borrar: volúmenes con datos

Es crucial prestar atención al eliminar volúmenes. Los volúmenes están diseñados para la persistencia de los datos. Si un volumen contiene datos importantes (por ejemplo, una base de datos, configuraciones de aplicaciones, archivos subidos por los usuarios), su eliminación implicará una pérdida irreversible de dichos datos. Utiliza siempre docker volume ls para listar los volúmenes y docker volume inspect para examinar su contenido o la asociación a contenedores antes de proceder con la eliminación. El comando docker volume ls -f dangling=true es seguro porque muestra solo los volúmenes que ya no están asociados a ningún contenedor activo, indicando que probablemente son huérfanos y ya no están en uso.

Limpieza automática programada

La mejor estrategia es automatizar la limpieza. Puedes crear un script y programarlo con cron o systemd timers para ejecutar regularmente los comandos docker system prune y docker builder prune. Por ejemplo, para ejecutar una limpieza cada domingo por la noche:

Crea un script shell, por ejemplo /usr/local/bin/docker-cleanup.sh:

#!/bin/bash

echo "$(date): Iniciando limpieza de Docker..."

docker system prune -af --filter "until=168h" # Elimina imágenes/contenedores/volúmenes no usados desde hace 7 días
docker builder prune -f # Limpia la caché de build

echo "$(date): Limpieza de Docker completada."

Haz el script ejecutable:

sudo chmod +x /usr/local/bin/docker-cleanup.sh

Luego, añade una entrada a crontab (por ejemplo, sudo crontab -e para el usuario root) para ejecutarlo semanalmente:

0 3 * * 0 /usr/local/bin/docker-cleanup.sh >> /var/log/docker-cleanup.log 2>&1

Esto ejecutará el script cada domingo a las 03:00 de la mañana, redirigiendo la salida a un archivo de log. El flag -f (force) en prune es crucial para la automatización, ya que suprime las solicitudes de confirmación interactivas. Lee también: Comando find Linux: 20 Ejemplos Prácticos

Errores Comunes y Resolución de Problemas

  • «Cannot connect to the Docker daemon»: Asegúrate de que el servicio Docker esté en ejecución (sudo systemctl status docker) y de que tu usuario tenga los permisos correctos (esté en el grupo docker).
  • Limpieza insuficiente: Si después de ejecutar los comandos el espacio no se libera significativamente, revisa la salida de docker system df -v. Podría haber un volumen de datos muy grande que no ha sido identificado o que no puede ser eliminado. Verifica también los logs no gestionados manualmente antes de configurar la rotación.
  • Pérdida de datos: La eliminación indiscriminada de volúmenes puede llevar a la pérdida de datos. Haz siempre una copia de seguridad o verifica cuidadosamente el uso de un volumen antes de eliminarlo. docker volume ls -f dangling=true es tu amigo.

FAQ — Preguntas Frecuentes

¿Con qué frecuencia debería limpiar Docker?

Depende de la intensidad de tu uso de Docker. Para entornos de desarrollo o CI/CD con builds frecuentes, una limpieza diaria o semanal puede ser apropiada. Para servidores de producción estables, una limpieza mensual o bimensual podría ser suficiente. Lo importante es monitorear regularmente el espacio en disco con docker system df y ajustar la frecuencia en consecuencia.

¿docker system prune también elimina los contenedores en ejecución?

No, docker system prune y sus subcomandos (image prune, container prune, volume prune, builder prune) están diseñados para eliminar solo los elementos no utilizados o detenidos. Los contenedores en ejecución, las imágenes usadas por contenedores en ejecución y los volúmenes montados por contenedores activos no serán afectados por estos comandos, a menos que se usen flags como -a o -f en contextos específicos y bien comprendidos.

¿Puedo deshacer una limpieza de Docker?

Generalmente no. Una vez que una imagen, un contenedor o un volumen se eliminan con los comandos prune, los datos asociados se eliminan de forma permanente. Es fundamental estar seguro de lo que se está eliminando antes de ejecutar estos comandos, especialmente en producción. Las copias de seguridad regulares son tu única verdadera garantía contra la pérdida de datos.

¿La rotación de logs en daemon.json se aplica también a los contenedores existentes?

Sí, la configuración de log-driver y log-opts en el archivo daemon.json se aplica a todos los nuevos contenedores iniciados después del reinicio del demonio Docker. Para los contenedores que ya estaban en ejecución antes de la modificación, las nuevas configuraciones no tendrán efecto hasta que sean reiniciados. Es una buena práctica reiniciar todos los contenedores después de modificar daemon.json para asegurar que las nuevas reglas de rotación de logs se apliquen universalmente.

Conclusiones con Puntos Clave Operativos

La gestión del espacio en disco en entornos Docker no es una opción, sino una necesidad. Ignorar la acumulación de imágenes, contenedores y logs puede llevar a problemas de rendimiento y estabilidad del sistema, con costos operativos significativos. Utilizar docker system df -v para un análisis profundo, combinar los comandos prune para una limpieza eficaz y configurar la rotación de logs a través de daemon.json son pasos fundamentales. Automatizar estas operaciones con cron o systemd timers es el paso final para un entorno Docker resiliente y de alto rendimiento. Recuerda siempre verificar cuidadosamente lo que estás eliminando, especialmente los volúmenes, para evitar pérdidas de datos irrecuperables.

Fuentes

Actualizado: Octubre 2026

Comparte este artículo:

Escrito por

Rosario Giordano

Rosario Giordano es administrador de sistemas y consultor de TI especializado en c iberseguridad y cloud, con más de 20 años de experiencia en la gestión de infraestructuras Linux empresariales. Sus áreas de especialización incluyen el hardening de SSH, plataformas Kubernetes , bases de datos PostgreSQL, virtualización con VMware/Proxmox y el cumplimiento de los marcos de seguridad NIS2 e ISO 27001.