v5.0.0

v5.0.0

La versión más grande del bot hasta ahora: varios hosts Docker desde un solo bot, los ajustes se cambian desde Telegram con /settings, y las actualizaciones de contenedores se han rehecho de arriba abajo para que no pierdan nada por el camino.

🔄 Si vienes de la 4.x

No tienes que cambiar nada para actualizar. Tu docker-compose de la 4.x sigue funcionando tal cual: el bot importa tus variables, conserva tus programaciones y sigue usando tu volumen. El mensaje de arranque te dice qué conviene cambiar, y puedes hacerlo cuando quieras:

• Volumen: la ruta pasa de /app/schedule a /app/config. Cambia solo la parte derecha de esa línea; no hace falta mover ningún fichero.
• Variables: LANGUAGE, BUTTON_COLUMNS, EXTENDED_MESSAGES, MULTI_SELECTION, TELEGRAM_NOTIFICATION_CHANNEL, CHECK_UPDATES, CHECK_UPDATE_EVERY_HOURS y CHECK_UPDATE_STOPPED_CONTAINERS se importan a /settings en el primer arranque y desde entonces se cambian ahí. Puedes borrarlas del compose: solo hacen falta las de Telegram y TZ.
• CONTAINER_NAME ya no hace falta: el bot averigua solo cuál es su contenedor.
• tty: true ya no hace falta: los logs salen al momento sin él.

✨ Novedades

🖥️ Varios hosts Docker

• Un solo bot para todas tus máquinas. Además del Docker local, puedes añadir hosts remotos por ssh:// (recomendado) o por tcp:// con un socket proxy, y TLS para quien lo necesite. Se añaden, se renombran y se quitan desde /settings, sin tocar el compose. El README lo explica paso a paso, incluidos Synology, UnRAID y otros NAS.
• Todo el bot es multi-host: /list, los menús de contenedores, las actualizaciones, /compose, /info, /ports, las programaciones y los avisos dicen de qué máquina es cada cosa. Con varios hosts, primero eliges host (con un botón para volver atrás si te equivocas).
• Un host caído no frena a los demás. Si una máquina no responde se marca en 🔴 y el resto sigue funcionando. El monitor de eventos se reconecta solo cuando vuelve y recupera los avisos de lo que pasó mientras tanto.
• /list mucho más rápido, sobre todo con hosts ssh://: una sola petición por host en vez de una por contenedor, y la conexión ssh se reutiliza en vez de abrir una nueva cada vez. Antes, con catorce contenedores en un host ssh, podía tardar nueve segundos.
• Pausar un host: se queda configurado pero fuera de las comprobaciones y los avisos, para cuando sabes que va a estar apagado.
• Las credenciales de los hosts nunca se guardan en los ajustes: viven en tus claves ssh o tus certificados.

⚙️ /settings y /start

• /settings: idioma, columnas de botones, mensajes extendidos, selección múltiple, canal de notificaciones, comprobación de actualizaciones (activada, cada cuántas horas, incluir parados), hosts y estadísticas, todo con botones. El canal de notificaciones se comprueba contra Telegram antes de guardarse.
• /start con botones agrupados por categorías, en lugar de la lista de 21 comandos.
• El mensaje de arranque resume tus contenedores y tus hosts, y te dice qué tienes que cambiar en el docker-compose: si los ajustes no están en un volumen y se van a perder, si usas la ruta antigua o si una variable del compose ya no se aplica, con enlace al README.

🔄 Actualizaciones

• De qué versión a qué versión: el aviso, la lista, la comparativa antes de confirmar y el resultado muestran 1.43.3 → 1.43.4 en vez de solo fechas y digests. Si sube el primer número, avisa de que puede traer cambios incompatibles, y enlaza a las novedades de esa versión cuando la imagen dice su repositorio.
• Actualizar varios a la vez no inunda el chat: un mensaje de progreso con el host y el contenedor en curso, y un resumen final con los actualizados, los fallidos y los que ya estaban al día. Una actualización suelta también se resume así.
• Listas agrupadas por host, con la versión de cada contenedor debajo de su nombre. Con muchas actualizaciones pendientes, la lista va por páginas.
• El propio bot se actualiza siempre el último, también con la etiqueta de actualización automática, para no cortar a medias la actualización de los demás.
• /changetag con cualquier registro: Docker Hub, ghcr.io, quay.io y registros privados (nas:5000/app), con las versiones ordenadas de la más nueva a la más antigua y filtradas por la arquitectura del host.

🔔 Avisos de contenedores

• Por qué se ha parado un contenedor: si ha terminado, si ha fallado (con su código de salida, la señal y sus últimas líneas de log) o si se ha quedado sin memoria.
• Avisos de salud: si el healthcheck empieza a fallar, un aviso con lo último que dijo, y otro cuando se recupera.
• Bucles de reinicio en un solo aviso: si un contenedor se cae 3 veces en 5 minutos, llega un aviso de «bucle de reinicios» en vez de un detenido/iniciado cada pocos segundos, y otro cuando se estabiliza. Los reinicios que pides tú o una programación no cuentan.

ℹ️ /info renovado

Todo lo que el bot sabe de un contenedor, por secciones: estado y salud, imagen y versión con enlace a sus novedades, actualización pendiente, si se actualiza solo y qué programaciones lo tocan, CPU y RAM con sus límites, redes y puertos, volúmenes y su lugar en Compose. Si está parado, tiene un botón para iniciarlo.

📊 Estadísticas anónimas: ayúdame a decidir qué viene después

Hasta ahora no tenía ni idea de cuánta gente usa el bot ni de qué funciones le sirven. Cada mejora era una apuesta: ¿merece la pena pulir /schedule o nadie lo usa? ¿Cuántos tenéis más de un servidor? ¿Merece la pena compilar la imagen para cinco arquitecturas, o hay alguna que no usa nadie?

Desde esta versión, el bot me lo cuenta con unas pocas cifras anónimas una vez al día. Con ellas sé a qué funciones dedicar mi tiempo libre, cuáles pulir y cuáles se pueden simplificar. Dejarlas activadas es la forma más sencilla de ayudar al proyecto sin hacer nada.

• Qué se envía: cuántos hosts y contenedores tienes (los contenedores por tramos, como «11-25»), qué ajustes están activados y en qué idioma, cuántas veces se usa cada comando, la arquitectura (amd64, arm64…) y las versiones del bot y de Docker.
• Qué no se envía nunca: nombres de contenedores, imágenes, hosts o proyectos, direcciones, IDs de Telegram ni nada de lo que escribes. Tu IP no se guarda.
• No hay nada escondido: las cifras son públicas, así que ves lo mismo que yo en stats.dgongut.com. Ahí está también la lista de lo que se envía, campo a campo, y el código del servidor está en GitHub.
• Sin terceros: van a un servidor mío, sin Google Analytics ni servicios externos, y los envíos se borran a los 90 días.

Si aun así prefieres no enviarlas, se desactivan en un toque desde /settings → Estadísticas anónimas (o con TELEMETRY=false en el compose), y se borra también el identificador de tu instalación. Pero si te gusta el bot y quieres que siga mejorando en lo que tú usas, déjalas activadas 🙏

🐛 Correcciones

Actualizaciones de contenedores

Probadas contra un Docker real con todo tipo de configuraciones y compose:

• Ya no se pierden datos: los volúmenes que declara la imagen y nadie mapea (postgres, mariadb, mongo…) y los anónimos volvían vacíos. Ahora se reutilizan.
• Se conserva toda la configuración: mounts de solo lectura, stop_grace_period, GPU, expose, annotations, la MAC de redes secundarias y otros ajustes que se perdían al actualizar.
• Ya se pueden actualizar los contenedores con links: o volumes_from, y /changetag con registros que llevan puerto.
• La arquitectura se respeta: un contenedor forzado a linux/amd64 en un Mac o una Raspberry Pi ya no pasa a ARM sin avisar.
• La verificación es más estricta: el contenedor nuevo tiene que aguantar en marcha antes de borrar el original. Si no, se vuelve al original.
• Un contenedor <nombre>_old sobrante ya no hace que se borre el contenedor real: la actualización no toca nada y avisa.
• Compose: los servicios de migración (service_completed_successfully) se vuelven a ejecutar con la imagen nueva, un dependiente que habías parado a propósito no se arranca, y lo que comparte la red de otro contenedor (network_mode: container:, al estilo gluetun) no se queda sin red.
• Los contenedores se paran respetando su stop_grace_period; antes, uno que necesitaba más de 30 s hacía fallar la actualización.
• Un contenedor que ya tiene la imagen más nueva no se vuelve a actualizar, y uno recreado por fuera del bot se encuentra por su nombre.
• Cada imagen se descarga una sola vez por comprobación, aunque la usen varios contenedores, y un fallo de descarga (como el límite de Docker Hub) no vuelve a anunciar lo ya avisado.
• Las etiquetas de metadatos que la 4.x dejaba pegadas a los contenedores ya no se arrastran: la versión se lee siempre de la imagen.
• DCB-Auto-Update=false y DCB-Ignore-Check-Updates=false ya significan «no». Antes bastaba con que la etiqueta existiera, así que DCB-Auto-Update=false activaba la actualización automática.
• La caché de actualizaciones vive en el volumen: recrear el bot o cambiar de idioma ya no vuelve a anunciar las mismas actualizaciones.

Programaciones

• Ya no se salta ninguna tarea por ir acumulando retraso, y las @reboot no retrasan el arranque.
• Si su host no responde, la tarea se salta esa vez en lugar de desactivarse, y el bot avisa una vez.
• Un comando con < o > (como mysql < dump.sql) ya no rompe /schedule, y una expresión cron imposible (30 de febrero) se rechaza.

Mensajes y bot

• El bot se para al momento en vez de esperar los 10 segundos que Docker tarda en forzarlo: cada reinicio, recreación y autoactualización va 10 s más rápida, y lo último que iba a decir llega a Telegram.
• Los logs ya no se pierden sin tty: true.
• Un aviso ya no llega dos veces cuando Telegram tarda en responder.
• /list y las confirmaciones muy largas se reparten en varios mensajes en vez de fallar por el límite de Telegram.
• /mute siempre confirma, un número absurdo ya no deja al bot mudo para siempre, y un silencio activo ya no impide que el contenedor se apague.
• Un comando dirigido a otro bot del grupo (/stop@OtroBot) se ignora.
• Un settings.json que no se puede leer ya no se sobrescribe, y un schedules.json dañado se aparta como copia en vez de perderse.

⚠️ A tener en cuenta

• Las actualizaciones tardan unos 2 segundos más: 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 ni el que da red al propio bot (el bot detrás de una VPN). En los dos casos el bot explica por qué.
• No actualices desde el bot el socket proxy por el que llega a un host remoto: se quedaría sin conexión a mitad. El README explica cómo marcarlo para que no lo intente.

🧪 Probado con

• Docker 29.8 (Docker Desktop) y Docker Compose v5.5.
• 380 tests automáticos, más los que van contra un Docker real (python3 tests/run_all.py --docker).
• La actualización desde la 4.2.0, con el compose de la 4.x tal cual.

Full Changelog: v4.2.0...v5.0.0