Does watchtower support restarting containers sharing the same network stack?

[michael-robbins]

Hey!

I have two containers, one a 'vpn' container and another a 'downloader' container.

The 'downloader' container has its network set as --network container:vpn which means its a separate container, but sharing the same networking stack as the 'downloader' container.

Does watchtower understand this linkage so when there's an update on the 'vpn' container, watchtower will also recreate the linked 'downloader' container correctly?

[michael-robbins]

I guess the tricky bit here is that we need to 'recreate' not just simply 'restart' the linked container in this case?

[piksel]

I think so, but wait until v1.3.0 is released, since the linking logic is currently broken.

[simskij]

We usually refer to it as restarts, but what happens, in reality, is that the old container gets deleted and a new one gets spun up. It should however keep the same configuration as the previous one, so this should definitely work as soon as v1.3.0 is out.

[ldekamps]

Is this working again as it should by now? I have the exact same configuration as TS (docker-compose stack with a vpn container, other containers with --network container:vpn). When Watchtower however updates the vpn container all other containers are dead.

[simskij]

It should!

[YanisKyr]

I was able to solve the network_mode: "container:vpn" issue by combining the VPN container as well as all containers that depend on it in the same Stack.

The VPN container uses network_mode: bridge and for the dependent ones use network_mode: "service:gluetun" which remains valid after updates.

[ThaDaVos]

Sadly above doesn't function that way for me - I have some containers, for example OneDev running and using a justsml/ssl-proxy:latest for setting up SSL to it - after Watchtower updates my OneDev container - the SSL will be down, I can't restart/recreate (through Portainer) the SSL container, i have to down and up the whole stack to get it to function again

[ThaDaVos]

This is how they are defined:

services:
    onedev:
        image: 1dev/server
        container_name: onedev
        restart: always
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - onedev_data:/opt/onedev
        ports:
            - 6610:6610
            - 6611:6611
            - 6443:6443
        healthcheck:
            test: ["CMD", "curl", "--fail", "http://localhost:6610"]
            interval: 10s
            timeout: 5s
            retries: 100
        environment:
            - hibernate_connection_password=${POSTGRES_PASSWORD}
            - hibernate_dialect=io.onedev.server.persistence.PostgreSQLDialect
            - hibernate_connection_driver_class=org.postgresql.Driver
            - hibernate_connection_url=jdbc:postgresql://postgres:5432/${POSTGRES_DB}
            - hibernate_connection_username=${POSTGRES_USER}
        tty: true
        depends_on:
            postgres:
                condition: service_healthy
    onedev_ssl:
        image: justsml/ssl-proxy:latest
        restart: always
        volumes:
            - certification:/certs:ro
        environment:
            - SERVER_NAME=${DOMAIN}
            - UPSTREAM_TARGET=localhost:6610
            - HTTPS_PORT=6443
            - CERT_PUBLIC_PATH=/certs/live/${DOMAIN}/fullchain.pem
            - CERT_PRIVATE_PATH=/certs/live/${DOMAIN}/privkey.pem
        network_mode: service:onedev
        depends_on:
            onedev:
                condition: service_healthy

[ThaDaVos]

Apparently the issue is still open: #1656

[shengjiex98]

Should be fixed by #1429

[piksel]

Yes this should "just work" in v1.6.0+