Watchtower does not restart linked containers

[rbuffat]

According to the documentation, watchtower should restart container with the com.centurylinklabs.watchtower.depends-on label, but it does not.

Background: We try to use watchtower in a CI/CD setup for a django/nginx application. We have a test server that runs a private registry. Watchtower is used to restart services once a new container is pushed to the local registry. Unfortunately, nginx seems to cache domain names, thus we need to restart the nginx service after a django service is restarted, as the internal ip adress of the django container in the docker network might change.

To Reproduce

I created a test setup to reproduce this issue here: https://github.com/rbuffat/watchtower_debug

1. Start local registry:

cd registry
docker-compose up -d

2. Build initial container

cd django
./rebuild.sh

3. Start application

cd testserver
docker-compose up

4. Recreate djano container

cd django
./rebuild.sh

Watchtower restarts django, but not nginx:

django        | Mon Apr 12 11:03:53 UTC 2021
django        | Mon Apr 12 11:03:53 UTC 2021
django        | Mon Apr 12 11:03:53 UTC 2021
watchtower    | time="2021-04-12T11:06:11Z" level=info msg="Found new localhost:5000/testapp/django:latest image (sha256:c2b3965b6165122089783843c6ffc176c4d5b6d876a2f836829da37fbbbe4169)"
watchtower    | time="2021-04-12T11:06:11Z" level=info msg="Stopping /django (f2b8aed8bb3ee82f1c4fa189937fef8ba9b435a01a445047d19f9aeaa20022aa) with SIGTERM"
django        | Mon Apr 12 11:03:53 UTC 2021
django        | Mon Apr 12 11:03:53 UTC 2021
django exited with code 137
watchtower    | time="2021-04-12T11:06:21Z" level=info msg="Creating /django"
watchtower    | time="2021-04-12T11:06:21Z" level=info msg="Removing image sha256:37d9055dc7de6afe321b7634bf356063903876ca34d2754f499a0608cd541253"
django        | Mon Apr 12 11:05:59 UTC 2021
django        | Mon Apr 12 11:05:59 UTC 2021
django        | Mon Apr 12 11:05:59 UTC 2021

docker ps
CONTAINER ID   IMAGE                                  COMMAND                  CREATED             STATUS         PORTS                                      NAMES
373b87ced78c   localhost:5000/testapp/django:latest   "/entrypoint.sh"         7 seconds ago       Up 6 seconds   0.0.0.0:9000->9000/tcp                     django
039650a8ab47   nginx:1.19-alpine                      "/docker-entrypoint.…"   4 minutes ago       Up 4 minutes   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   nginx
7631e527b87f   registry:2                             "/entrypoint.sh /etc…"   6 minutes ago       Up 6 minutes   0.0.0.0:5000->5000/tcp                     registry
88649fbaa9e4   containrrr/watchtower                  "/watchtower --inter…"   About an hour ago   Up 4 minutes   8080/tcp                                   watchtower
a11baabfcaba   postgis/postgis:12-3.0-alpine          "docker-entrypoint.s…"   3 hours ago         Up 4 minutes   0.0.0.0:5432->5432/tcp                     db
95d057da8da2   redis:6.2-alpine                       "docker-entrypoint.s…"   3 hours ago         Up 4 minutes   0.0.0.0:6379->6379/tcp                     redis

Possible related issues:
#595

[github-actions]

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! 🙏

[piksel]

It looks like you are using different contexts for django and nginx, is that inentional?

[rbuffat]

@piksel yes. The check interval --interval 60 we intend to use would hit the docker hub rate limit quite fast. The different context is to differentiate between images that are in the private repository and the ones from the docker hub.

[piksel]

I think that might be why it doesn't work, since the target container is not included in the context it has no reference to it and cannot include it in the update/restart list. I don't know enough about how the links are handled internally, though, and looking at the source it's not obvious to me how it works.

[simskij]

Linked containers that are not in scope won't be included as it's currently implemented. Should it be changed? I don't know. @victorcmoura might have some thoughts on this?