30 contenedores en casa: ¿qué aprendí de Linux tras una falla de disco?
El autor ha ejecutado 30 contenedores con archivos compose copiados y descubrió una falla de disco que lo hizo querer entender Linux a fondo.
El usuario /u/philippe312 ha pasado dos años auto-hospedando servicios como Jellyfin, Immich y Paperless, todos iniciados con archivos compose que copió y ajustó hasta que funcionaban.
El fin de semana pasado, un disco se llenó inesperadamente. Pasó seis horas intentando localizar la causa porque no sabía dónde buscar. La frustración lo llevó a declarar que quiere aprender Linux “de verdad”, en lugar de seguir pegando correcciones.
Para quienes se encuentran en la misma situación, el problema suele originarse en los volúmenes montados en los contenedores. Si un servicio escribe en un volumen que está en un disco que no es el principal, la utilización del disco puede crecer sin que sea evidente. Revisar los docker-compose.yml y los volumes declarados, y usar du -sh en los puntos de montaje, suele dar la pista.
Además, revisar los logs de los contenedores con docker logs y comprobar la configuración de tmpfs o tmp puede evitar que se escriba en disco cuando no es necesario. En este caso, el autor no tenía claro la ruta de los volúmenes y el disco que se llenó resultó ser el de la raíz.
El aprendizaje que surge es que, antes de copiar un compose, es útil inspeccionar la configuración de volúmenes y los límites de disco con df -h y du -sh. Esto ayuda a detectar cuellos de botella y a comprender mejor cómo el sistema de archivos interactúa con Docker.
Si buscas evitar este tipo de problemas, empieza por mapear claramente cada volumen y usar --mount en lugar de volumes cuando necesites un control más fino. También puedes monitorear el uso de disco con herramientas como cadvisor o prometheus para detectar aumentos inesperados.