FR: Multiple Hosts Support

[spyhuntergenral]

Is your feature request related to a problem? Please describe.

Related to #1218 seems like that one ended in hurt feelings.

In any case opening this FR again, as its not an edge case,

Currently when setting the "DOCKER_HOST" variable to a remote sock endpoint i.e "tcp://1.1.1.1:2375" watchtower shifts from watching the localhost to the specified remote host correctly.

Describe the solution you'd like

Would i be terribly difficult to implement passing this variable as a comma separated array? i.e DOCKER_HOST: "tcp://1.1.1.1:2375,tcp://2.2.2.2:2375"

In a similar manner to how Dozzle works see: https://dozzle.dev/guide/remote-hosts

Ideally additionally when setting this variable it would still monitoring the localhost in addition to all the remote hosts passed.

The goal would be to remove the need to have a watchtower instance running on every single container host and have 1 watchtower instance updating containers across X many hosts (both local and/or remote)

Describe alternatives you've considered

Moving away from watchtower :(

Additional context

No response

[github-actions[bot]]

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

[cameronaw13]

+1 on this. Just to clear the air from the previous discussion; from what I've gathered, I think that both piksel and simskij severely misinterpreted what neo-neo1 was trying to say. He was not asking for a way to implement redundancy for watchtower but was instead commenting on how redundant it is to add a new instance of watchtower for each and every machine he runs docker on. Instead, as spyhuntergenral suggests, we could allow a single instance of watchtower to update multiple remote Docker endpoints (including the local daemon if possible) eliminating the need to start up and maintain multiple instances of watchtower.

[cameronaw13]

After briefly reviewing the internal/pkg code and docker sdk api, it seems that we'd need to rework quite a bit regarding the client setup process. There isn't any way to add multiple hosts directly through the "DOCKER_HOST" env var as its used directly in the sdk api (it can only work with one host at a time). We'd likely need to add a separate environment variable allowing us to parse and iterate through a list of docker hosts (though this may add unneeded complexity). For each iteration we would need to run the update stack changing the docker_host env var each time but I am unsure of how much would need to be updated in order to accommodate this. For example, we'd also need to rework notifications/logs allowing you to differentiate between docker hosts.

And there's likely much more that I missed as I only looked through the code briefly with my limited golang knowledge. Its a bit more complicated than I first thought but I still feel that implementing such a feature would benefit many people's setups including mine in the long run.

[NetRat88]

Good to see, that this FR comes up again. I also was searching for the possibility to add multi host on my existing and running watchtower instance and also was wandering about the discussion in the past. 😅

In my use case I would like to add my QNAP NAS docker host with paperless, another Raspberry Pi4 with some network docker containers and my Pi5 with home automation containers to my existing watchtower instance in my third management Pi (with Portainer and some other containers).

Just to let you guys know that there are more supporters for this feature request. Thanks for the great work which saves me a lot of admin time! But understand that you have iterate some more code to add this. I also use pushover notifications and could imagine, that it's not just extending the remote host list.

[ThrustVector]

Ended up here after searching for exactly this feature. Seems I have to resort to one instance of Watchtower per Docker host for now :disappointed_relieved:

[ollioddi]

+1 for this.

I run a couple of proxmox nodes, with vms/lxc for docker for contained services.

Each vm/lxc usually runs 2-6 containers each. I don't really care about the resource usage, it's more about centralizing an overview.

Instead of doing the docker socket remotely, an "agent" based approach could perhaps be considered?

Like portainer, or crowdsec, a lightweight container could be deployed on whatever node, which then communicates with a main instance.