

Uhh, I think you might be confused. Let me explain a bit more:
Services
andContainers
aren’t the same thing. The distinction usually doesn’t matter in typical self-hosting scenarios, but in this case it does.
In short: Services
are what you define in a compose
file; Containers
are what you spin up based on those service definitions.
network_mode
is a service attribute and it can be defined for each service separately.network_mode: "service:{name}"
requires the service being referenced to be part of the same stack. This is probably what you were thinking of when you wrote this reply.network_mode: "container:{name}"
can freely reference any preexisting container. This helps you achieve what you want. You can define yourgluetun
container independently, along with any services you might want to be part of the same stack, and give it a unique identifier usingcontainer_name: myIndependentGluetun
. After spinning it up, run yourQbittorrent
container or whatever service you want to route through thegluetun
container after addingnetwork_mode: "container:myIndependentGluetun".
You could also route it manually. That’s a more advanced solution, but it’s more convenient than the network_mode
approach. More on this here: https://discuss.tchncs.de/post/19039498
This is an annoying quirk in the way docker handles networking between containers and I couldn’t find a good solution for this issue when I was trying out
network_mode
. I just couldn’t find a way to set docker up to automatically restart the dependent container. You can achieve this with services defined in the same stack (usingdepends_on
), but I don’t know if it’s possible with your current setup.That’s why I mentioned manual routing in my other reply. It’s annoying to set up, but more convenient because you avoid having to manage restarts (or figuring out how to get docker to do it, which may not be possible in this case).