Some containers fail to bind the specified port #18
Comments
|
Maybe the answer is to add another configuration variable that could set a non-standard listener port? For example, adding
# configure serve or funnel
if [ -v TAILSCALE_SERVE_PORT ] && [ -v TAILSCALE_SERVE_MODE ]; then
if [ -v TAILSCALE_FUNNEL ]; then
tailscale funnel --bg \
--"${TAILSCALE_SERVE_MODE}"=${TAILSCALE_HOST_PORT:-443} http://localhost:"${TAILSCALE_SERVE_PORT}"
else
tailscale serve --bg \
--"${TAILSCALE_SERVE_MODE}"=${TAILSCALE_HOST_PORT:-443} http://localhost:"${TAILSCALE_SERVE_PORT}"
fi
fi |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've seen this issue with at least two lsio containers: heimdall & nextcloud.
I use the same compose file with all of my lsio containers, which works with most of them (around 15 with the tailscale mod), with only ports & names changed, generally.
My understanding of what's happening is that Tailscale is creating its own server on 443 (or maybe 80 if you select http) and then forwarding requests to the internal container's port (ex. radarr, it's going from 443 -> 7878). But any containers that internally already use 80 or 443 cause a port conflict because they are also creating listeners on the ports that tailscale has already registered (since tailscale creates during the S6 bootup).
In a perfect world, there would be a way to allow both to exist simultaneously - I'm not sure if that would mean allowing Tailscale to create the listener on non-standard ports, or somehow creating a reverse proxy and then remapping the container's ports with an internal port mapping option similar to the standard compose port map, or what.
Docker Compose
Heimdall Log
The text was updated successfully, but these errors were encountered: