9
submitted 5 months ago* (last edited 5 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
[-] archomrade@midwest.social 1 points 5 months ago

Can I ask what your compose file looks like? Or how you deployed?

[-] ExcessShiv@lemmy.dbzer0.com 3 points 5 months ago

Yeah i pretty much stole this from someone else, although it only used a single torrent client so i just added another that looked the same. i'm not very skilled in docker, so some things may not be best practice (or even correct)

qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    network_mode: service:gluetun
    environment:
      - PUID=${APPUSER_PUID}
      - PGID=${APPUSER_PGID}
      - TZ=${TIME_ZONE_VALUE}
      - WEBUI_PORT=8084
    volumes:
      - ${PATH_TO_DATA}/qbit/config:/config
      - ${PATH_TO_COMPLETE}:/downloads
    restart: unless-stopped
    depends_on:
      - gluetun

  qbittorrentTL:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrentTL
    network_mode: service:gluetun
    environment:
      - PUID=${APPUSER_PUID}
      - PGID=${APPUSER_PGID}
      - TZ=${TIME_ZONE_VALUE}
      - WEBUI_PORT=8085
    volumes:
      - ${PATH_TO_DATA}/qbitTL/config:/config
      - ${PATH_TO_COMPLETE}:/downloads
    restart: unless-stopped
    depends_on:
      - gluetun

  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    networks:
      pirate_net:
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - OPENVPN_USER=[USER]
      - OPENVPN_PASSWORD=[PASSWORD]
      - SERVER_COUNTRIES=[COUNTRIES]
      - VPN_PORT_FORWARDING=on
      - UPDATER_PERIOD=6h
    ports:
      - 8084:8084 # Qbit
      - 8085:8085 # QbitTL
      - 6881:6881
      - 6881:6881/udp
      - 8191:8191 # Flaresolverr
      - 9696:9696 # Prowlarr
      - 7878:7878 # Radarr
      - 8989:8989 # Sonarr
    volumes:
      - ${PATH_TO_DATA}/gluetun/config:/config

networks:
  pirate_net:
    driver: bridge
[-] archomrade@midwest.social 1 points 5 months ago

I might need to try this... I wonder if it makes a difference that the gluetun service is listed last. I noticed that trying to start the containers in the wrong order results in port collision errors, maybe this is why it works for you?

[-] ExcessShiv@lemmy.dbzer0.com 1 points 5 months ago

IDK, it's worth a try to rearrange the containers I would say.

[-] N0x0n@lemmy.ml 1 points 5 months ago* (last edited 5 months ago)

I think this has nothing to do with who is listed first/last !

As you can see in this docker-compose, they are on 2 different web-ui ports, avoiding conflicts !

[-] archomrade@midwest.social 1 points 5 months ago

Yup, I was only pointing out that i was having trouble doing the same thing in my docker compose (using the webui_port env variable did not avoid port collisions at deployment)

I haven't tried this particular compose outline though. It could also be the pirate_network they're initiating or the depends_on variables they're using, I just haven't played around with it yet.

[-] archomrade@midwest.social 1 points 5 months ago

Question: how are you deploying your arr apps? do you do that in a separate compose file?

[-] ExcessShiv@lemmy.dbzer0.com 2 points 5 months ago

No they're in the same compose file, I just left other parts out because it's fairly long for a post.

this post was submitted on 31 May 2024
9 points (76.5% liked)

Selfhosted

40152 readers
488 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