My instance runs the WebUI on port 7070 and I have no variables that specify that. All I have is this port statement.
ports:
- 7070:8080/tcpSo, again I ask what does QBT_WEBUI_PORT do that isn't already happening by not using it?
QBT_WEBUI_PORT is the internal port used by the Docker network, _NOT_ the host machine, which is 7070 in your example. 7070 is irrelevant here, the focus is 8080. You don't want 2 containers listening on the same port.
QBT_WEBUI_PORT is the internal port used by the Docker network, _NOT_ the host machine, which is 7070 in your example. 7070 is irrelevant here, the focus is 8080. You don't want 2 containers listening on the same port.
If the container is on a docker network, the internal port is irrelevant. It’s the mapped host port that matters, as that is where the containers and/or host can overlap.
I have several containers that have the same internal port, and they are even on the same docker network, but the mapped host port is different or else the containers will not even start, let alone try to listen on the same port.
I don't use compose but I know it has some great convenience features, but I'm not sure if it's magic runs deep enough to fix this. Remember, both web UI ports are on 8080.
#!/bin/bash
docker run -d \
--name="qbittorrent" \
`# set up volumes and other stuff` \
`# now bind ports for qbittorrent's webui'` \
`# or will this be Sabnzbd's webui?'` \
-p 7070:8080 \
--restart unless-stopped \
qbittorrentvpn
docker run -d \
--name=sabnzbd \
`# Again, set up volumes and other stuff` \
`# now use qbittorrent as a proxy'` \
--network=container:qbittorrent\
--restart unless-stopped \
lscr.io/linuxserver/sabnzbd:latestI don't use compose but I know it has some great convenience features, but I'm not sure if it's magic runs deep enough to fix this. Remember, both web UI ports are on 8080.
That may be, but the container internals are isolated from each other. It doesn't matter if they are started by compose or run, the internal isolation is the same. Having the port definition in the containers keeps them from overlapping on the host "listening" ports.
You can convert between the two with something composerize and decomposerize, or just rewrite them yourself.
The only time that it would matter is if you are rebuilding a container from scratch to hold more than the one application. Then the applications are not isolated from each other.
QBT_WEBUI_PORT is the internal port used by the Docker network, _NOT_ the host machine, which is 7070 in your example. 7070 is irrelevant here, the focus is 8080. You don't want 2 containers listening on the same port.
I think you may be wrong here. The QBT_WEBUI_PORT is the port used by the web server used in the container and is exposed to the docker network. It is not used by the docker network. That is a very important distinction.
Each container on the docker network gets a docker network ip address as if it was a computer on a normal network, and just like a normal network you can have the same port in use by multiple containers (or computers on a network).
The ip address or host name determines where the traffic gets sent to (or docker container name with docker).
The port mapping and network bridge mode in compose and/or run, act sort of like like a router, allowing you to bridge networks (docker network to host in this case). Just like a router there is a single ip address that the traffic has to funnel through (the host) and just like a router (without a reverse proxy in line which would change the route based hostname allowing the ports to be kept in the private side of the route), the ports have to be exposed on the "public side" (the host) so ports need to be remapped so that they don't overlap.
I've created 1 final image before qBittorent v5.0 (final).
Pull with docker pull ... coldsilk/docker-qbittorrent:latest
Very, VERY notably is the ability to use qBittorrent's API to issue a shutdown via ip:port/api/v2/app/shutdown I learned a bit about private trackers as well because without that shutdown command, there's seemingly no way to shutdown qbittorrent-nox cleanly. It's _SUPPOSED_ to shutdown cleanly on SIGABRT, but it most certainly doesn't. Without a clean shutdown, apparently private trackers can't collect usage, which is seemingly a big deal in the private tracker world. Also without it you loose a little download data :-/
I've posted some of the changes before, but here is all of them in totality (I think).
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!