edit: a working solution is proposed by @Lifebandit666@feddit.uk below:
So you’re trying to get 2 instances of qbt behind the same Gluetun vpn container?
I don’t use Qbt but I certainly have done in the past. Am I correct in remembering that in the gui you can change the port?
If so, maybe what you could do is set up your stack with 1 instance in, go into the GUI and change the port on the service to 8000 or 8081 or whatever.
Map that port in your Gluetun config and leave the default port open for QBT, and add a second instance to the stack with a different name and addresses for the config files.
Restart the stack and have 2 instances.
Has anyone run into issues with docker port collisions when trying to run images behind a bridge network (i think I got those terms right?)?
I’m trying to run the arr stack behind a VPN container (gluetun for those familiar), and I would really like to duplicate a container image within the stack (e.g. a separate download client for different types of downloads). As soon as I set the network_mode to ‘service’ or ‘container’, i lose the ability to set the public/internal port of the service, which means any image that doesn’t allow setting ports from an environment variable is stuck with whatever the default port is within the application.
Here’s an example .yml:
services:
gluetun:
image: qmcgaw/gluetun:latest
container_name: gluetun
cap_add:
- NET_ADMIN
environment:
- VPN_SERVICE_PROVIDER=mullvad
- VPN_TYPE=[redacted]
- WIREGUARD_PRIVATE_KEY=[redacted]
- WIREGUARD_ADDRESSES=[redacted]
- SERVER_COUNTRIES=[redacted]
ports:
- "8080:8080" #qbittorrent
- "6881:6881"
- "6881:6881/udp"
- "9696:9696" # Prowlarr
- "7878:7878" # Radar
- "8686:8686" # Lidarr
- "8989:8989" # Sonarr
restart: always
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: "qbittorrent"
network_mode: "service:gluetun"
environment:
- PUID=1000
- PGID=1000
- TZ=CST/CDT
- WEBUI_PORT=8080
volumes:
- /docker/appdata/qbittorrent:/config
- /media/nas_share/data:/data)
Declaring ports in the qbittorrent service raises an error saying you cannot set ports when using the service network mode. Linuxserver.io has a WEBUI_PORT environment variable, but using it without also setting the service ports breaks it (their documentation says this is due to CSRF issues and port mapping, but then why even include it as a variable?)
The only workaround i can think of is doing a local build of the image that needs duplication to allow ports to be configured from the e variables, OR run duplicate gluetun containers for each client which seems dumb and not at all worthwhile.
Has anyone dealt with this before?
This worked!!
Shame that it’s a little bit of a runaround, but not only did this work, it also persists after restarts and updates.
I’ll be editing my post and offering it as a solution to the other places I have seen this question asked, thank you a ton!
It’s not a workaround.
In the old days, if you had 2 services that were hard coded to use the same network port, you would need virtualization or a different server and make sure the networking for those is correct.
Network ports allow multiple services to use the same network adapter as a port is like a “sub” address.
Docker being able to remap host network ports to containers ports is a huge feature.
If a container doesn’t need to be accessed outside of the docker network, you don’t need to expose the port.
The only way to have multiple services on the same port is to use either a load balancer (for multiple instances of the same service) or an application-aware reverse proxy (like nginx, haproxy, caddy etc for web things, I’m sure there are other application-aware reverse proxies).
Holy shit I totally thought I was talking out of my arse lol
lmao. I’m starting to really wonder what the WEBGUI_PORT variable does if not exactly what you’re changing in the GUI… someone else mentioned they got multiple instances to deploy from the same compose file by placing the gluetun service at the end of the file. I wonder if the order in which the containers are deployed is the thing that makes this work. i’ll test more when I have the time
Actually I’m also not using the default port for any of my qbit instances
AFAIK the thing that complicates this is trying to run it behind gluetun
docker makes it really easy to specify a unique port on deployment, but when you’re using a network bridge (as in the case of gluetun) the networking settings are controlled there instead, so you can’t use the normal port declarations. It’s apparently not impossible to do it with gluetun but it seems it’s not as straightforward.