dgongut/docker-controller-bot v5.0.0_RC8

on GitHub

v5.0.0_RC8

✨ Novedades

• Las actualizaciones dicen de qué versión a qué versión van. El aviso de actualización disponible, la lista de /updateall, la comparativa antes de confirmar y el resultado final muestran ahora 1.43.3 → 1.43.4 en lugar de solo fechas y digests. La versión se lee de la propia imagen (la etiqueta estándar OCI o, en las imágenes oficiales, su variable NGINX_VERSION, PG_VERSION…), sin peticiones extra. El propio bot también anuncia así su actualización.

• Aviso de versión mayor. Si la actualización sube el primer número de versión (1.x → 2.0), la comparativa avisa de que puede traer cambios incompatibles.

• Enlace a las novedades. Cuando la imagen indica su repositorio de GitHub, la comparativa enlaza la página de esa versión, o la lista de versiones si no la encuentra.

• El bot dice por qué se ha parado un contenedor. En vez de un «se ha detenido» genérico distingue tres casos:

  • ha terminado (salida correcta, código 0);
  • ha fallado, con su código de salida, el nombre de la señal (137 SIGKILL, 139 SIGSEGV…) y sus últimas líneas de log;
  • se ha quedado sin memoria.

  Las paradas pedidas por ti, por el bot o por una programación siguen saliendo como siempre.

• Avisos de salud. Si el healthcheck de un contenedor empieza a fallar, el bot avisa una sola vez, con lo último que dijo la comprobación, y vuelve a avisar cuando se recupera.

• Actualizar un solo contenedor se resume en un mensaje, igual que /updateall: un mensaje de progreso y un resumen final, sin la ristra de «detenido / iniciado / actualizado».

• /changetag funciona con cualquier registro. Además de Docker Hub admite ghcr.io, quay.io y registros privados (nas:5000/app). Antes, en ghcr.io ofrecía versiones de hace años (Home Assistant de 2021, Plex de 2020). Ahora las ordena de la más nueva a la más antigua, filtra por la arquitectura del host del contenedor y entiende las imágenes escritas como docker.io/….

• La imagen declara sus datos con etiquetas OCI estándar: versión, fecha de build, commit, descripción, licencia e imagen base. Herramientas como Portainer o Diun pueden leerlos.

🐛 Correcciones

Todas encontradas probando actualizaciones contra un Docker real, con todo tipo de configuraciones y compose:

• Ya no se pierden datos al actualizar. Los volúmenes que declara la imagen y nadie mapea, típicos de postgres, mariadb o mongo, y los volúmenes anónimos (-v /data) volvían vacíos. Ahora el contenedor nuevo reutiliza el mismo volumen.
• Se conserva toda la configuración. Antes se perdían varias cosas al actualizar:
  • los mounts de solo lectura, que volvían escribibles;
  • stop_grace_period, -P, expose, el subpath de volúmenes y el modo de los tmpfs;
  • create_host_path, las annotations y las GPU (deploy.resources.reservations.devices);
  • gw_priority entre redes, la MAC fija de una red secundaria y systempaths=unconfined.
• Contenedores que no se podían actualizar:
  • los que usan links: fallaban siempre;
  • los que usan volumes_from fallaban si antes se había actualizado el contenedor del que toman los volúmenes;
  • /changetag fallaba con registros que llevan puerto.
• La arquitectura se respeta. Un contenedor forzado a linux/amd64 en un Mac o en una Raspberry Pi pasaba a ARM sin avisar.
• Contenedores que se rompían o desaparecían:
  • uno lanzado con --rm se perdía al actualizarlo; ahora la actualización se rechaza y el bot explica por qué;
  • lo que comparte la red de otro contenedor fuera de Compose (--network container:vpn, al estilo gluetun) se quedaba sin red al actualizar el contenedor principal.
• La verificación es más estricta. Un contenedor nuevo que moría al poco de arrancar se daba por bueno y se borraba el original. Ahora tiene que aguantar en marcha, sin reiniciarse, antes de dar la actualización por buena. Si no, se vuelve al original.
• Compose y dependencias:
  • al actualizar un servicio de migración o de inicio (service_completed_successfully), los dependientes quedaban caídos 3 minutos y la migración no se ejecutaba con la imagen nueva;
  • el bot ya no se reinicia a sí mismo cuando depende de lo que se actualiza, como el socket-proxy;
  • un dependiente que habías parado a propósito ya no se arranca;
  • en /updateall, un contenedor recreado durante el propio lote ya no aparece como fallido.
• Contenedores pausados o recién creados: uno pausado vuelve pausado, y uno creado pero nunca arrancado ya no se arranca al actualizarlo.
• /compose escribe correctamente GPU, anotaciones, stop_grace_period, expose, external_links y volumes_from, y no declara como propios los volúmenes que llegan de otro contenedor.
• Programaciones:
  • un nombre o un contenedor con < ya no corta el asistente ni deja /schedule sin poder abrirse;
  • una expresión cron que nunca se cumple (como el 30 de febrero) se rechaza en vez de guardarse en silencio.

⚠️ A tener en cuenta al actualizar

• Las actualizaciones tardan unos 2 segundos más: es el tiempo que el contenedor nuevo tiene que aguantar en marcha antes de borrar el original.

• No se pueden actualizar desde el bot:

  • los contenedores lanzados con --rm;
  • un contenedor cuya red usa el propio bot (el bot detrás de una VPN), porque actualizarlo dejaría al bot sin conexión.

  En los dos casos el bot lo explica.

• Si al actualizar la VPN de un contenedor con network_mode: service:… ese contenedor estaba parado, se reapunta a la VPN nueva pero sigue parado.

• Con configs: de contenido en línea (content:) de Compose, ese fichero no sobrevive a una actualización desde el bot: Compose lo copia dentro del contenedor y no deja constancia de que lo hizo.

🧪 Probado con

• Docker 29.8.1 (Docker Desktop, almacén de imágenes containerd) y Docker Compose v5.5.1.
• 358 tests automáticos, más 29 contra un Docker real. Estos últimos son nuevos: python3 tests/run_all.py --docker.

Full Changelog: v5.0.0_RC7...v5.0.0_RC8