Trampas del homelab con Docker: espacio en disco, registros y deriva de configuración

Una publicación técnica reciente detalla varios peligros operativos encontrados al gestionar un entorno Docker autoalojado en Proxmox y almacenamiento conectado a red (NAS). El autor describe cómo los comandos de diagnóstico estándar pueden inducir a error a los administradores, llevándolos a eliminar servicios activos o pasar por alto una deriva crítica de la configuración. Estos incidentes ponen de manifiesto la brecha entre el estado de salud del contenedor y la funcionalidad real del servicio en configuraciones complejas de homelab.

Qué ocurrió

La investigación comenzó cuando un host Docker alcanzó el 82 % de capacidad de disco. Los diagnósticos iniciales usando docker system df sugerían 6,67 GB de espacio recuperable, pero una inspección más cercana reveló que las vistas resumidas eran engañosas. El comando docker ps mostraba identificadores SHA sin nombre para varios contenedores, haciendo que una imagen activa llamada unclecode/crawl4ai pareciera huérfana. El contenedor estaba sano, llevaba dos semanas en ejecución y servía tráfico. El administrador evitó eliminarlo solo cruzando referencias entre los puertos en escucha y las inspecciones de contenedores.

El análisis posterior mostró que la presión sobre el disco provenía de las imágenes y las cachés de compilación, no de los datos de usuario. Un invitado mantenía 16 GB de imágenes, mientras que otro tenía 11,4 GB de imágenes y 11,3 GB de caché de compilación. Eliminar dieciséis etiquetas obsoletas de una aplicación personalizada liberó solo 60 MB, a pesar de que cada etiqueta figuraba como 240 MB, debido a las capas compartidas. Un incidente separado involucró a un host diferente que alcanzó el 100 % de uso de disco porque el demonio de Docker carecía de un archivo de configuración para limitar el tamaño de los registros. Un único archivo de registro de Home Assistant había crecido hasta 1,9 GB, provocando el fallo de cinco unidades systemd sin alertar a nadie.

La deriva de configuración también causó interrupciones prolongadas. Un contenedor de explorador de archivos permaneció caído durante seis días porque su política de reinicio había revertido a no, a pesar de que el archivo compose especificaba unless-stopped. Esto ocurrió porque el contenedor se creó antes del cambio de política y nunca se recreó. Además, los problemas de interpolación de variables de entorno corrompieron una cadena de contraseña Argon2, causando fallos de autenticación, mientras que los valores predeterminados codificados en una pila de trazabilidad llevaron a errores de conexión a la base de datos. Se encontraron brechas de seguridad de red donde los puertos publicados permitían el acceso directo a instancias privadas, saltándose los proxies inversos.

Detalles clave

• Las herramientas de limpieza de disco como docker system df pueden representar incorrectamente el uso de espacio debido a las capas de imágenes compartidas y las cachés de compilación.
• El registro predeterminado de Docker no tiene límite de tamaño, lo que permite que archivos de registro individuales llenen sistemas de archivos completos si daemon.json no está configurado.
• Cambiar archivos .env o configuraciones de compose requiere docker compose up -d --force-recreate para surtir efecto, no solo un reinicio.
• Los contenedores creados antes de una actualización de la política de reinicio conservan su política original hasta que se recrean o actualizan explícitamente.
• Las comprobaciones de salud indican el estado del proceso, pero no verifican la conectividad funcional, como conexiones de túnel o disponibilidad de GPU.
• Las reglas de firewall para puertos publicados deben coincidir con las direcciones de destino originales usando --ctorigdst debido al comportamiento de DNAT.

Antecedentes

Los contenedores Docker son entornos virtualizados ligeros que comparten el kernel del sistema operativo anfitrión. Cuando se crea un contenedor, Docker captura la configuración, incluidas las variables de entorno, las políticas de reinicio y los controladores de registro, en un estado de ejecución específico. Los cambios posteriores en los archivos fuente, como los archivos YAML de compose o las definiciones de variables de entorno, no actualizan automáticamente los contenedores en ejecución. Los administradores deben recrear explícitamente los contenedores para aplicar estos cambios. Este comportamiento suele llevar a la "deriva de configuración", donde el sistema activo diverge del código de infraestructura declarado.

El registro en Docker utiliza típicamente un controlador de archivo JSON por defecto, que escribe todos los flujos de salida estándar y de error en el disco sin rotación a menos que se configure lo contrario. En producción o en homelabs de larga duración, esto puede conducir a un rápido consumo de disco. De manera similar, la gestión de imágenes implica capas que se comparten entre múltiples etiquetas y versiones. Eliminar una etiqueta específica no elimina necesariamente los bloques de datos subyacentes si otras imágenes los referencian, haciendo que la recuperación de espacio en disco sea menos predecible que la simple eliminación de archivos.

Por qué importa

Para los equipos que ejecutan software autoalojado, estas trampas representan riesgos significativos de fiabilidad. Confiar en comprobaciones de salud superficiales puede ocultar fallos de servicio, como un agente de túnel que está en ejecución pero no conectado, o un contenedor de aprendizaje automático que recurre a la CPU debido a incompatibilidad de hardware. Sin un monitoreo robusto de la funcionalidad real del servicio, las interrupciones pueden persistir durante días sin ser notadas. El incidente donde un explorador de archivos permaneció caído durante seis días ilustra cómo los fallos silenciosos pueden interrumpir los flujos de trabajo sin desencadenar alertas inmediatas.

El agotamiento del espacio en disco es otra amenaza crítica para la disponibilidad. El crecimiento ilimitado de los registros puede bloquear hosts enteros, derribando simultáneamente todos los servicios co-localizados. La falta de rotación de registros predeterminada significa que cada nuevo despliegue hereda este riesgo a menos que se mitigue explícitamente. Además, la deriva de configuración socava los beneficios de reproducibilidad de las prácticas de infraestructura como código. Si las variables de entorno o las políticas de reinicio no están sincronizadas entre el repositorio de código y los contenedores en ejecución, la depuración se vuelve difícil y los despliegues impredecibles.

La seguridad de red también se ve comprometida cuando los comportamientos de publicación predeterminados no se gestionan cuidadosamente. Exponer servicios privados en todas las interfaces permite el movimiento lateral no autorizado dentro de la red. Una configuración adecuada del firewall requiere comprender la mecánica de traducción de direcciones de red de Docker, que difiere del enrutamiento estándar basado en host. Las reglas mal configuradas pueden dejar servicios internos sensibles accesibles a segmentos menos confiables, violando los principios de menor privilegio.

Qué puedes hacer

• Verifica el uso de imágenes con docker inspect y revisa los puertos en escucha antes de eliminar cualquier imagen o contenedor.
• Configura daemon.json con límites max-size y max-file para los registros, luego recrea los contenedores existentes para aplicar los ajustes.
• Usa docker compose up -d --force-recreate después de cambiar los archivos de entorno para asegurar que se carguen los nuevos valores.
• Audita regularmente las políticas de reinicio usando docker inspect para confirmar que coinciden con la configuración de compose pretendida.
• Implementa reglas de firewall en la cadena DOCKER-USER usando --ctorigdst para restringir el acceso a los puertos publicados.
• Prueba la funcionalidad del servicio más allá de las comprobaciones de salud verificando periódicamente la conectividad externa y las dependencias internas.