Dockerode label pour mise a jour des containers

Bonjour,

Je me suis confronté à un petit problème qui sera à mon avis vite résolu. Lorsqu’on installe un Gladys sur un système déjà établi avec un Watchtower déjà actif mais qui, de base, n’update les containers que par le filtrage des labels (Container selection - Watchtower), les containers créés par Gladys ne s’updatent donc pas dans un tel système.

C’est la cas entre autre sur les containers Mosquitto et Zigbee2Mqtt.

Je n’ai pas réussi a trouver comment ajouter un label via Dockerode, mais il serait intéressant de positionner le label “com.centurylinklabs.watchtower.enable=true” par défaut.

Hello @Albenss ! :slight_smile:

Tu peux nous en dire un peu plus sur ton installation ?

  • Comment lance tu Gladys ?
  • Pourquoi utilise tu ces filtres de labels ?
  • Pourquoi ne pas utiliser des filtres d’exclusions si jamais tu as des containers “sensibles” que tu ne veux pas mettre à jour, mais garder un “default” où tu mets à jour les containers sans tags ?
  • Pourquoi ne pas faire le filtering par nom dans la commande de lancement de Watchtower ?

Je demande tout ça car c’est un cas spécifique, je ne sais pas si on veut mettre dans Gladys des variables si spécifique à ton cas.

Yes par défaut watchtower n’exploite pas les labels. C’est du custom, mais je te rejoins la dessus, ça coûte rien qu’on le rajoute.

Côté installation, j’ai installé Gladys sous un petit NAS custom (OMV utilisé principalement pour Docker).

Etant donné que j’utilise Watchtower pour tout ce NAS (une 50aine de conteneurs différents avec quelques BDD), mon choix s’est porté sur la mise à jour des containers uniquement sélectionnés, donc Watchtower est en mode “Fully exclude” et quand je veux qu’un conteneur comme Gladys se mette à jour alors j’utilise le label “com.centurylinklabs.watchtower.enable=true ”.

Cela me permet entre autre d’éviter les mises à jours sur les conteneurs critiques, et de n’autoriser que les conteneurs sélectionnés.

En effet comme le dit @VonOx, le label ne changera pas le comportement classique de Watchtower en mode normal (sans distinction), mais sur les configuration un peu plus custom cela permettra d’appliquer les mises à jours de conteneurs créés par Gladys (Zigbee2Mqtt principalement chez moi).

Pour avoir tester, si un utilisateur essaye Gladys sur un hôte ayant déjà un Watchtower qui tourne en mode Fully exclude, le seul moyen de mettre à jour, c’est de désactiver Z2M dans Gladys, de supprimer le conteneur, de faire un pull de la nouvelle version puis de réactiver Z2M sous Gladys pour le laisser recréer le conteneur. Charge un peu lourde.

Le bénéfice / risque de ma proposition est dans le positif, ça permettra une meilleur intégration de Gladys dans des environnement plus complexe, et ne changera strictement rien pour les utilisateurs classiques.

Ok je comprend mieux, mais du coup on est d’accord c’est toi qui lance Watchtower ?

Watchtower peut prendre des arguments, et en argument tu peux lui passer la liste des containers que tu veux mettre à jour :slight_smile:

Example :

Pourquoi ne pas lancer watchtower et lui mettre la liste des containers que tu veux mettre à jour ?

Watchtower je l’ai lancé il y a plus d’un an je n’ai pas eu besoin d’y toucher depuis, il tourne en mode démon et se lance toutes les 24h, la seule configuration qui change c’est directement sur les conteneurs sur lesquels je veux activer ou non la mise à jour auto via ce fameux label.

C’est certes une solution de contournement que tu me proposes, de lancer un nouveau Watchtower avec une liste de conteneurs, mais ça veut dire bypasser un système déjà en place.

Ce que je propose avec ma solution d’un label dans la configuration de création depuis Gladys c’est de permettre dans la configuration standard ou dans la configuration restrictive d’avoir la mise à jour automatiquement.

1 Like

Justement, je me pose la question si ça fait sens de modifier les applications que tu utilise, plutôt que de modifier ta configuration Watchtower, vu que ce que tu fais est quand même assez spécifique à ton installation.

Si quelqu’un vient nous voir avec la demande exactement inverse ( ne pas mettre à jour Zigbee2mqtt pour éviter les instabilités ), on sera un peu bloqué…

Pourquoi ne pas juste faire un :

docker stop watchtower && docker rm watchtower

Puis relance watchtower avec ta configuration :

docker run -d \
  --name watchtower \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  containrrr/watchtower \
  --cleanup --include-restarting gladys gladys-z2m-mqtt gladys-z2m-zigbee2mqtt

C’est une bonne remarque, j’estimais juste qu’étant donné que Watchtower est activé par défaut dans l’image RPI de Gladys, tous les conteneurs devaient se mettre à jour de la même façon que Gladys et qu’il fallait donc voir un peu plus large que la configuration de base de Watchtower.

Du coup effectivement je passerai en mise à jour manuelle quand il le faudra.

1 Like

La solution pourrait être (comme déjà lu ailleurs il me semble) que depuis l’onglet Système, on puisse avoir le contrôle sur les différents containers que l’on a installé.
Par exemple :

Zigbee2mqtt | Etat ON | Redémarrer | Mettre à jour

Un truc du genre, comme ça libre à chacun de faire sa mise à jour quand il le souhaite

@guim31 C’est un autre sujet, les mises à jour sont déjà automatique par défaut de toute façon, personne ne fait les mises à jour sinon :slight_smile:

Pour une fonctionnalité de gestion des containers lancée, pourquoi pas, je veux bien que tu créé une feature request sur le forum si c’est quelque chose que tu souhaite voir dans Gladys ?