Question about using gluetun for other containers

Submitted ⁨⁨1⁩ ⁨hour⁩ ago⁩ by ⁨chagall@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

I use gluetun, my arr stack and bittorrent client in a single docker-compose. I use the syntax

    depends_on:
      gluetun:
        condition: service_healthy

in the stack to make sure that the bittorrent client doesn’t try to connect too early. All that works great.

I also use that same VPN connection for other containers too (not in the same docker-compose stack). I do that by simply using network_mode: “container:gluetun” in the second yaml file. But I’d like to use the same depends_on. But it errors out because gluetun is undefined in the second stack.

So my question is, how do I make sure the containers in docker compose stack 2 start after docker compose stack 1 (the one with gluetun) is healthy?

source

Comments

Sort:hotnew top

sarahreid@lemmy.world ⁨32⁩ ⁨minutes⁩ ago
Yeah, depends_on only works inside a single compose file/project, so it can’t see gluetun from stack 2 — that’s why you’re getting the undefined error. There’s no built-in cross-stack depends_on, unfortunately.

The cleanest fix IMO is to merge them into one compose file if you can, then depends_on with service_healthy works for everything. If you really want to keep them seperate, a couple of options:

Start stack 1 first, then have a small wait script before stack 2, something like looping on docker inspect until gluetun’s health status is healthy, then docker compose -f stack2.yml up -d. A bit clunky, but it works and it’s explicit.

Or use a systemd unit or a wrapper script that runs the two up commands in order, with the wait in between.

What I wouldn’t do is just add a fixed sleep — gluetun can take a while to bring the tunnel up, and a sleep that works today will bite you on a slow day.

One caveat too: service_healthy only means the container is healthy, not neccessarily that the VPN tunnel itself is fully up, so it’s still worth checking the torrent client actually has the VPN IP before you trust it. FYI, you can test that from inside the client container with curl to an IP checker.
source
- IronKrill@lemmy.ca ⁨23⁩ ⁨minutes⁩ ago
  Darn. I had the same question as OP but have been working around it by combining everything into the same stack. It’s just a bit of a pain to edit the stack every time I want to test something or retire a service.
  
  Good work-arounds though! Maybe I should move to a script-based startup… Only trouble is all my containers are tagged with restart: unless-stopped so Docker restarts all of it at once on reboot which would mess up the order. Hmm.
  
  source