I encountered a small problem that I believe will be quickly resolved. When installing Gladys on a system already set up with an active Watchtower but which, by default, only updates containers by filtering labels (Container selection - Watchtower), the containers created by Gladys are therefore not updated in such a system.
This is the case, among others, with the Mosquitto and Zigbee2Mqtt containers.
I have not been able to find how to add a label via Dockerode, but it would be interesting to set the label « com.centurylinklabs.watchtower.enable=true » by default.
Why not use exclusion filters if you have « sensitive » containers that you don’t want to update, but keep a « default » where you update containers without tags?
Why not do the filtering by name in the Watchtower launch command?
I’m asking all this because it’s a specific case, I don’t know if we want to put in Gladys variables so specific to your case.
Regarding installation, I installed Gladys on a small custom NAS (OMV mainly used for Docker).
Given that I use Watchtower for the entire NAS (around 50 different containers with a few databases), my choice was to update only selected containers, so Watchtower is in « Fully exclude » mode, and when I want a container like Gladys to update, I use the label “com.centurylinklabs.watchtower.enable=true”.
This, among other things, allows me to avoid updates on critical containers and only authorize selected containers.
Indeed, as @VonOx says, the label will not change the classic behavior of Watchtower in normal mode (without distinction), but on more custom configurations, it will allow applying updates to containers created by Gladys (mainly Zigbee2Mqtt in my case).
After testing, if a user tries Gladys on a host that already has a running Watchtower in Fully exclude mode, the only way to update is to disable Z2M in Gladys, delete the container, pull the new version, and then reactivate Z2M in Gladys to let it recreate the container. Quite a heavy task.
The benefit/risk of my proposal is positive; it will allow better integration of Gladys in more complex environments and will not change anything for regular users.
Watchtower, I launched it over a year ago, I haven’t had to touch it since, it runs in daemon mode and starts every 24 hours, the only configuration that changes is directly on the containers on which I want to activate or not the auto-update via this famous label.
It’s certainly a workaround solution that you propose to me, to launch a new Watchtower with a list of containers, but that means bypassing a system already in place.
What I propose with my solution of a label in the configuration of creation from Gladys is to allow in the standard configuration or in the restrictive configuration to have the automatic update.
Just as I was wondering if it makes sense to modify the applications you use, rather than modifying your Watchtower configuration, given that what you’re doing is quite specific to your installation.
If someone comes to us with the exact opposite request (not updating Zigbee2mqtt to avoid instability), we’ll be a bit stuck…
That’s a good point. I just thought that since Watchtower is enabled by default in the Gladys RPI image, all containers should update in the same way as Gladys, so we should look a bit beyond the basic Watchtower configuration.
So indeed, I will switch to manual updates when needed.
The solution could be (as I think I’ve read elsewhere) that from the System tab, one could have control over the different containers that have been installed.
For example:
Zigbee2mqtt | Status ON | Restart | Update
Something like that, so each person can update when they wish.
@guim31 That’s another topic, updates are already automatic by default anyway, nobody does the updates otherwise
For a container management feature to be launched, why not, I’d be happy if you created a feature request on the forum if it’s something you’d like to see in Gladys?
