10
submitted 2 months ago* (last edited 2 months ago) by archomrade@midwest.social to c/selfhosted@lemmy.world

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?

you are viewing a single comment's thread
view the rest of the comments
[-] UberMentch@lemmy.world 3 points 2 months ago* (last edited 2 months ago)

I am also currently dealing with this same exact issue, I'm wanting to run multiple instances of Lidarr for MP3 / FLAC libraries with Gluetun. I don't have an answer (I haven't put in the time to try and solve it yet), so apologies if I got your hopes up. I'm just here to confirm that others have this issue too!

Edit: Regarding that documentation, it seems like it's not saying that changing the port breaks it, it's just that you have to set both sides of the mapping to be the same. The default is 8080, so instead of 8080:8080, change the mapping to 8081:8081. That's how I'm reading it, anyways.

I should also mention that the closest that I got to fixing this was to boot up my 2nd Lidarr container separately, setting the port in the Lidarr WebUI console to something different (8687, for example), and then attach it to my Gluetun docker compose file. I did a docker compose pull to update my stack, then docker compose up -d for it. You might try this approach, and tinker around with it. I just haven't had time to really play with this "solution"

Edit 2: Played more with the solution I mentioned, and that LifeBandit666 found. We both gave the same solution, and the solution seems to work. Just don't be a dumbass, and remember to do application configuration to your container (unlike me, who, after putting the container into my Gluetun docker compose file, forgot that I didn't do application configuration and just saw a bunch of errors with Lidarr).

[-] archomrade@midwest.social 2 points 2 months ago* (last edited 2 months ago)

nah, it seems like it's a known problem, no worries. There's an unresolved issue open on the gluetun github about it. I just figured someone would have had a workaround at this point since I see people recommend separate client instances to keep things organized all the time.

I think the people who do that just don't use a VPN, but I have strong feelings against exposing my IP

edit: that's interesting. I've tried a few variations, but maybe I didn't try that one

[-] UberMentch@lemmy.world 3 points 2 months ago

Yeah, you and I have very similar use cases with this. Gluetun, VPN, download clients + *arr stack, I get it. I'll be sure to update with a solution, if I spot one (when I get around to looking)!

[-] archomrade@midwest.social 0 points 2 months ago

yea, i just tried a couple things to no avail:

publish a new port in gluetun, e.g. - 8082:8082 then set webui port in the new instance:

- environment:
  - WEBUI_PORT: 8082

error on deployment

Then I tried spinning up the new container separately, declaring the pots eg:

- ports:
  - 8082:8082

and then manually switching the network to gluetun and turning off the port declaration, and it still ends up on the default port. Bummer.

[-] couch1potato@lemmy.dbzer0.com 1 points 2 months ago

I just set up vpns in my router and use macvlan network for my dockers so I can route their individual ip addresses to whichever interface I want...

this post was submitted on 31 May 2024
10 points (81.2% liked)

Selfhosted

38652 readers
416 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS