¿Qué hace que un contenedor llene el disco del sistema cuando sus datos están en otro lugar?
Un contenedor puede llenar el disco del sistema cuando los registros, las cachés, los archivos temporales o las escrituras accidentales permanecen dentro del almacenamiento local de Docker.
Mover una biblioteca multimedia o un volumen de base de datos a otro grupo de almacenamiento no mueve la imagen del contenedor, la capa escribible, el registro JSON, la caché de BuildKit, los metadatos ni ninguna ruta que se haya omitido de la lista de montajes. Un montaje externo fallido también puede dejar vacío el directorio de host esperado, lo que hace que la aplicación escriba datos nuevos en el disco del sistema sin mostrar un error evidente.
Mide la raíz de Docker antes de inspeccionar los datos de la aplicación
Comprueba el sistema de archivos que contiene la raíz de datos de Docker y compara los tamaños de los directorios del host con el uso registrado por Docker para imágenes, contenedores, volúmenes y la caché de compilación. Registra el uso antes de eliminar nada.
Un usuario de Cloudron descubrió que /var/lib/docker/overlay2 consumía más espacio que todos los datos visibles de las aplicaciones, lo que demuestra por qué la raíz de almacenamiento de Docker debe medirse por separado de las bibliotecas externas.
Si el disco del sistema está lleno pero el grupo de almacenamiento externo tiene espacio, identifica si el crecimiento se encuentra en los contenedores, las capas overlay, los volúmenes, las imágenes o la caché de compilación. No ejecutes una limpieza general hasta clasificar los datos activos y recuperables.
Comprueba si los registros JSON de los contenedores crecen sin límite
Inspecciona el controlador de registros y el tamaño del archivo de registro de cada contenedor. Un servicio puede almacenar sus datos principales en otro lugar mientras stdout y stderr crecen indefinidamente dentro del directorio local de contenedores de Docker.
Code Maven documenta un caso en el que docker system df no reveló el problema principal porque el archivo de registro predeterminado seguía creciendo fuera de ese resumen. El consumidor oculto era un registro de contenedor que crecía continuamente.
Encuentra y corrige el error ruidoso de la aplicación antes de rotar o truncar los registros. Configura una rotación de registros con límites para los contenedores futuros y verifica que los archivos nuevos dejen de crecer al alcanzar el límite esperado.
Encuentra los datos escritos en la capa escribible del contenedor
Compara las rutas persistentes previstas con las rutas reales de caché, transcodificación, descargas, bases de datos, miniaturas, copias de seguridad y archivos temporales de la aplicación. Cualquier escritura sin montar permanece en la capa escribible del contenedor, ubicada en el disco del sistema.
Una explicación en un foro de Docker señala que las escrituras y los archivos de imagen modificados se almacenan en la capa escribible, mientras que los registros grandes sin rotación viven en los metadatos del contenedor. Ambos pueden hacer que un contenedor consuma casi todo el espacio local a pesar de tener un volumen de datos externo.
Usa los informes de tamaño por contenedor e inspecciona las rutas modificadas más grandes dentro del contenedor. Añade montajes bind explícitos o volúmenes con nombre solo para los datos que deban persistir y, después de hacer una copia de seguridad de todo lo valioso, recrea el contenedor para descartar el contenido obsoleto de la capa escribible.
Verifica que el montaje externo estuviera presente cuando se inició el contenedor
Comprueba que la SSD, el recurso compartido NAS o el grupo de almacenamiento estuviera montado en la ruta de host esperada antes de que Docker iniciara el contenedor. Compara la identidad del dispositivo y la información de montaje con el directorio que ve el contenedor.
Cuando falta un montaje externo, el directorio vacío subyacente del sistema de archivos del sistema puede seguir existiendo. El contenedor puede escribir normalmente en ese directorio alternativo, lo que hace que el disco del sistema crezca mientras el grupo de almacenamiento externo parece no modificarse.
Detén el contenedor antes de volver a montar el almacenamiento sobre datos alternativos ya existentes. Mueve o reconcilia los archivos ocultos de forma segura, añade dependencias del montaje o comprobaciones de inicio y evita que la aplicación se inicie cuando falte el dispositivo esperado.
Inspecciona las capas de imagen, la caché de compilación y los objetos abandonados
Revisa las imágenes sin usar, los contenedores detenidos, los volúmenes anónimos y la caché de BuildKit. Las actualizaciones frecuentes o las compilaciones locales pueden acumular muchas capas incluso cuando los datos persistentes de la aplicación están montados correctamente en otro lugar.
Una explicación en un foro del proyecto Moby aclara que los montajes overlay pueden hacer confusas las cifras de disco y que el uso del sistema de archivos subyacente debe interpretarse con cuidado. Otro caso de Home Assistant también mostró el crecimiento de overlay2 debido a registros y capas con el paso del tiempo.
Elimina únicamente los objetos que se hayan confirmado como no utilizados por los proyectos actuales de Compose y las copias de seguridad. Nunca elimines manualmente directorios individuales de overlay2, porque las referencias de los metadatos de Docker podrían quedar incoherentes.
Valida la solución con una línea base de crecimiento
Después de corregir la ruta responsable, registra el uso de la raíz de Docker, los tamaños de los registros, los tamaños escribibles de los contenedores y el uso del grupo de almacenamiento externo a intervalos regulares durante la carga de trabajo que anteriormente provocaba el crecimiento.
El flujo de trabajo de ZimaSpace para preparar una transferencia NAS de gran tamaño proporciona una carga repetible para confirmar que los datos llegan al grupo de almacenamiento previsto.
El problema solo está solucionado cuando el crecimiento del disco del sistema coincide con el comportamiento esperado de las imágenes y los registros, los datos persistentes de la aplicación crecen en el grupo de almacenamiento externo y la ausencia de un montaje externo provoca un fallo de inicio seguro en lugar de escrituras silenciosas en el sistema de archivos raíz.
Productos recomendados
Soporte y Consejos
Más para leer
¿Puede Plex compartir una GPU con otro contenedor de Docker?
Plex y otro contenedor suelen poder acceder a la misma GPU, pero debes probar la compatibilidad de los controladores, la asignación de dispositivos, la...
Cómo saber si un error de Plex proviene del cliente o del servidor
Reproduce el mismo elemento en otro cliente, compara la ruta de la sesión y recopila pruebas del servidor solo después de que el alcance...
Cómo configurar la caché de Plex y el almacenamiento temporal para la transcodificación
Protege el estado persistente de Plex mientras colocas los archivos temporales de transcodificación en un almacenamiento local adecuado; después, verifica la limpieza, el espacio...
