Allow running on a different port (for a reason that hasn't been covered on a different thread)

[airbreather]

Feature description

I want to be able to choose which port the server runs on, using something that's at least as flexible as, like, a --build-arg when building the image (though an environment variable would be even better).

Motivation

I'm aware of the multiple times that this has been requested, cataloged quite nicely in #728 (comment). It does look like each of the linked cases had a better solution.

I'm setting up a server that use rootless Podman containers (see also #621). These containers all go into a single pod, since that makes it trivial for me to run a reverse-proxy in one container that forwards to services running in different containers without needing to publish the ports to make those services visible to anything else running on the same machine (docs).

So far, I've been setting everything up so that there's a single pod that publishes only port 443, while the other services it exposes are in the same pod and running on their own individual ports. This is a migration from a more "traditional" server setup, and I've gotten through most of the services, until I got here. I happen to host two instances with my two licenses, so if I'm going to have both of them run in the same pod, then I must be able to change one of the ports.

There are many ways I could work around this, of course, but everything I can come up with is orders of magnitude more annoying than what #728 tried to do.

Example

Quadlet files could look something like the following.

web.pod

[Unit]
Description=TLS reverse-proxy and its targets

[Pod]
UserNS=auto
PublishPort=443:443

foundryvtt1.container

[Unit]
Description=Foundry VTT (first instance)

[Container]
Image=felddy/foundryvtt:12
AutoUpdate=registry
Pod=web.pod
Secret=foundryvtt_timedurl,type=env,target=FOUNDRY_RELEASE_URL
Secret=foundryvtt1_adminpassword,type=env,target=FOUNDRY_ADMIN_KEY
Environment=FOUNDRY_PROXY_SSL=true
Environment=FOUNDRY_IP_DISCOVERY=false
Environment=FOUNDRY_HOSTNAME=my.domain
Environment=FOUNDRY_ROUTE_PREFIX=myRoutePrefix
# the new thing I'd like to see:
Environment=FOUNDRY_PORT=30000
Environment=TZ=America/Detroit
Volume=foundryvtt1-data.volume:/data:Z
Volume=/nas/shared/foundry-assets:/data/Data/assets:ro,Z

[Service]
Restart=on-failure
RestartSec=5s

foundryvtt2.container

[Unit]
Description=Foundry VTT (second instance)

[Container]
Image=felddy/foundryvtt:12
AutoUpdate=registry
Pod=web.pod
Secret=foundryvtt_timedurl,type=env,target=FOUNDRY_RELEASE_URL
Secret=foundryvtt2_adminpassword,type=env,target=FOUNDRY_ADMIN_KEY
Environment=FOUNDRY_PROXY_SSL=true
Environment=FOUNDRY_IP_DISCOVERY=false
Environment=FOUNDRY_HOSTNAME=my.domain
Environment=FOUNDRY_ROUTE_PREFIX=myRoutePrefix
# the new thing I'd like to see:
Environment=FOUNDRY_PORT=30001
Environment=TZ=America/Detroit
Volume=foundryvtt2-data.volume:/data:Z
Volume=/nas/shared/foundry-assets:/data/Data/assets:ro,Z

[Service]
Restart=on-failure
RestartSec=5s

This is my first attempt at getting serious with containerizing a large number of services, so I'm sure there's something I could be doing better. I also haven't tested any of it at the time of writing: I just stumbled upon this gap while setting up my Quadlet files, and I stopped everything to write up an issue before I just go work around it and then forget to circle back around. I may or may not come back around to tweak the above files if I discover anything too egregious.

Pitch

This project seems to go the extra mile to streamline as much of the process as possible for running Foundry VTT in a container. It would be a bit disappointing to me if I had to skip using it just because of a single configuration option where I can find no particularly strong reasons* to force it to be a hardcoded value.

• *EXPOSE in the Dockerfile is just a suggestion, but in case that's the sticking point, I'm like 90% sure that it could still be a --build-arg so that the EXPOSE stays consistent with what actually gets used.

Code of Conduct

• I agree to follow this project's Code of Conduct

[airbreather]

FWIW my workaround for now is to throw this into my CONTAINER_PATCHES:

#!/bin/sh

# Needed because of:
# https://github.com/felddy/foundryvtt-docker/issues/1131
#
# based on code from:
# https://github.com/felddy/foundryvtt-docker/blob/9d1ebf8764e6dd0ee6934da3c4a3d76c31c4cee9/src/launcher.sh

CONFIG_DIR="/data/Config"
CONFIG_FILE="${CONFIG_DIR}/options.json"

mkdir -p "${CONFIG_DIR}"

if [[ "${CONTAINER_PRESERVE_CONFIG:-}" == "true" && -f "${CONFIG_FILE}" ]]; then
  :
elif [[ "${FOUNDRY_PORT:-unset}" != "unset" ]]; then
  ./set_options.js | sed s/30000/$FOUNDRY_PORT/g > "${CONFIG_FILE}"
  export CONTAINER_PRESERVE_CONFIG="true"
fi

Edit: and, of course, in the quadlets:

[Container]
# ... other stuff from above ...
Exec=resources/app/main.mjs --port=30001 --headless --noupdate --dataPath=/data

[tymanthius]

I'm running 2 instances of this docker on one unraid server. To get it to work outside my network all I had to do was set the port on docker of the second one, then set the port in foundry too. Would be nice if the port passed thru to the config file tho.

[kayhos]

I also used the same solution as @tymanthius

In my docker-compose, I added:

    ports:
      - target: 30000
        published: 31000
        protocol: tcp

[dcpc007]

For my config, i use docker-compose with 2 instances (one for V12 and one for V13), both with same port, but i use a traefik reverse proxy in front to map urls to the right container.
=> nothing to change except the specific labels for traefik to match dns entries.

Second config for example :
`version: "3"

services:
foundry13:
image: felddy/foundryvtt:13
container_name: foundryvtt-13
hostname: foundry_13
restart: "unless-stopped"
volumes:
- '/srv/foundryTT13:/data'
environment:
FOUNDRY_PASSWORD: xxx
FOUNDRY_USERNAME: toto
FOUNDRY_ADMIN_KEY: yyy
CONTAINER_CACHE: /data/containerCache
labels:
- "traefik.enable=true"
- "traefik.http.routers.foundry13.rule=Host(foundry13.host.fr)"
- "traefik.http.routers.foundry13.entrypoints=websecure"
- "traefik.http.routers.foundry13.tls.certresolver=myresolver"
- "traefik.http.services.foundry13.loadbalancer.server.port=30000"
networks:
- traefik-network

networks:
traefik-network:
external: true
`

[Mr-Dufus]

another user here asking for the ability to change the foundry port. there is one use-case that has not been brought up at this point :
network_mode: host

the performance difference on my synology under host vs bridge is astronomical, a difference of 400ms vs 2000 to serve up large core files, however i have multiple foundries, which means I can't use host mode because I've been locked into bridge because changing the port is disallowed by the image