Cuando al servidor Docker le falta espacio
· 10min · docker
Introducción
Ya en una entrada del blog comentamos cómo realizar la actualización automática de los contenedores Docker que tenemos en el servidor en marcha mediante WhatchTower. Pero uno de los problemas que nos puede llegar a surgir es quedarnos sin espacio debido a este uso intensivo de la descarga de nuevas imágenes. En esta entrada comentaremos que nos ha pasado en el servidor NAS y cómo resolverlo.
Comportamiento Raro
Resulta que el servidor llevaba un día haciendo cosas raras. Al tenerlo en medio de casa y escucharlo cada vez que se ejecuta algo pesado, nos da pie a saber si algo le pasa. El caso es que debido es esto estábamos escuchando como el servidor sonaba más de lo normal y nos extrañamos de lo que estaba pasando. Otro de los detalles que no nos encajaba era que la luz de uno de los discos duros de la partición principal, estan un un raid 1, estaba permanentemente encendida, signo de un accedo a disco raro. Y por último el dato que nos hizo terminar de sospechar fue que el Home Assitant - HA pareció morir de un momento a otro. Con todo ello nos dimos cuenta que debíamos intervenir a ver qué estaba pasando.
Investigando
Lo primero que intentamos ver fue qué estaba pasando con el HA, era posible que no se estuviera arrancando bien el servidor, por lo que intentamos volver a arrancar el servicio ejecutando
docker compose up -dY nos dimos cuenta que no erámos capaces de parar los servicios con docker usando…
docker compose downEl servicio de zigbee2mqtt se negaba a pararse. Este comportamiento suele ser extraño así que entramos desde Portainer para tener una visión de primer nivel a la hora de ver qué estaba pasando. Intentamos entrar apagar los contenedores de HA pero se auto arrancaban automáticamente y efectivamente éramos incapaces de dar de baja el contenedor de zigbee2mqtt. Hay muchas cosas que pueden hacer que un contenedor no arranque, pero que no pare es muy extraño ya que es simplemente cargarse el proceso.
Identificamos el el error
Viendo a ver lo que podía pasarle ejecutamos el comando…
df -hY nos dimos cuenta de algo y es que el disco estaba completo al 100%
root@mordor:/DataPool/docker/home-assistant# df -h
S.ficheros Tamaño Usados Disp Uso% Montado en
udev 7,8G 0 7,8G 0% /dev
tmpfs 1,6G 4,8M 1,6G 1% /run
/dev/sde2 423G 421G 0 100% /
tmpfs 7,8G 4,0K 7,8G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup
tmpfs 7,8G 200K 7,8G 1% /tmp
/dev/sde1 511M 6,2M 505M 2% /boot/efi
DataPool 11T 5,5T 5,3T 52% /DataPoolIdentificada la posible causa del error teníamos que ponerle remedio. Recordamos que WatchTower cada vez que se ejecuta debe comprobar que los contenedores tienen una nueva versión, y si es así descarga la nueva imagen. Efectivamente, esto es genial porque nos permite de manera desatendida descargar y actualizar los contenedores y sus imágenes a las nuevas versiones, pero también ocupa espacio con cada imagen descargada. Lo cual tiene la parte negativa de que si no liberamos el espacio de las imágenes que va descargando se nos puede llenar el disco principal.
Aplicando la solución
Para liberar el espacio deberemos ejecutar…
docker image pruneAl ejecutarlos debería salirnos un mensaje similar al siguiente donde nos pregunta si queremos o no liberar el espacio de las imágenes que tenemos “dangling”, o colgadas, es decir, imágenes descargadas que no están asociadas a ningún contenedor que está en marcha en ese momento. Por lo que pulsaremos en Y pulsamos enter
root@mordor:/# docker image prune
WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] yEste proceso puede tardar tiempo dependiendo del número de imágenes descargadas, así como las que tenga que borrrar. En mi caso tardó más de 5 minutos borrando imágenes, hasta que presentó el mensaje.
untagged: ghcr.io/home-assistant/amd64-hassio-supervisor@sha256:91b0bc2717b92815ed0d6953edd31061300b7797649f7da0b9485f9de3f3efa1
deleted: sha256:75585cfc2f723625b28fbcc87f68aa3754de735d4c8cfb1fca1eb334462d1837
deleted: sha256:573165ee9301f279d357ee8c9900d3dc39cfcc284eeec5d8ac69c805d7c445c9
deleted: sha256:5f0953215d927c28f296a5f4bb4ad20e335c72b102f4dd4c932e2f6b66bd9ad0
deleted: sha256:c581c37ee75428a4f7a99e27c99c732833aef0711f914dbaa622b9a17f2e5e6a
deleted: sha256:998bff3eb7b4fb8bbd961a1ea4c67d7ab1eff43fcaddd9b2df26d24874df004f
deleted: sha256:1d6dbb3a0d8a76b39bb84d75189764b82e3500e33e0de3549fe8f24740d50403
deleted: sha256:98003976a24c10d7b9a1f27cf5da7e3c010fa87b93aab4f00a1abc240ba987be
Total reclaimed space: 104GBComo vemos llegó a borrar más de 104 GB de datos del disco de imágenes que no se estaban usando en ese momento. Lo que permitió que pudiéramos liberar suficiente espacio en disco para que el sistema volviera a ser estable.
root@mordor:/DataPool/docker/home-assistant# df -h
S.ficheros Tamaño Usados Disp Uso% Montado en
udev 7,8G 0 7,8G 0% /dev
tmpfs 1,6G 4,8M 1,6G 1% /run
/dev/sde2 423G 312G 90G 78% /
tmpfs 7,8G 4,0K 7,8G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 4,0M 0 4,0M 0% /sys/fs/cgroup
tmpfs 7,8G 200K 7,8G 1% /tmp
/dev/sde1 511M 6,2M 505M 2% /boot/efi
DataPool 11T 5,5T 5,3T 52% /DataPoolComo vemos pudimos liberar más unso 110 Gigas de espacio que le dan el margen suficiente al servidor para poder funcionar de manera normal. Incluso podríamos ser más agresivos usando el parámetro -a
docker image prune -aLo que en nuestro caso liberó …
Total reclaimed space: 2.262GBLiberando también el espacio de imágenes parciales que no estén en uso.
Lecciones aprendidas
Si hubiéramos tenido una alarma que nos permitiera saber que habíamos sobrepasado el 80-85% del disco ocupado nos habríamos dado cuenta de que la partición principal del servidor estaba llegando a su límite, esto podríamos hacerlo con cualquier entorno de monitorización. En nuestro caso sabéis que lo hacemos con Grafana y recopilamos los datos con Telegraf y los almacenamos en Influx DB v2. Si tienes ganas de saber cómo montar este sistema lo tienes disponible en una serie de vídeos en Youtube