I installed seafile 12.0.7 running under docker. It is intended to replace the Version 9.0.9 running dockerless under raspian. Both are reachable from the internet via a port forwarding on the router.
I’ve noticed a slight difference in the behaviour of the two installations:
I can each the dockerless installation via the external (Dyndns this is) internet name, the internal name and even the internal ip address.
It seems the docker version only answers to whatever name is configured in the .env variable SEAFILE_SERVER_HOSTNAME. This of course will always be the name visible from the internet DNS
Not that it’s a big problem, but is this the expected behaviour of a docker installation?
I am not sure what exactly you mean here. Maybe you mean that you can get to the normal port (probably 443), but not the others that the internal services use (like 8000 or 8082). Or maybe you mean that your port 443 works from your public IP, but not from the internal IP? Here’s an explanation of why that first case is expected with docker. If you mean the second one, I am not sure why that would be, and would need more info about how your network is set up.
Docker adds a lot of complexity to the situation. Each docker container gets its own IP in a virtual network within the host OS (so not accessible to the real network). There’s a sort of virtual router to forward outgoing packets out of the containers on to the real network, so programs mostly still work as you would expect, except when they are listening for a connection instead.
If a program is listening for an incoming connection, it is listening in this virtual network. So a connection from another container works like usual, but connections from the real network don’t work without help. There’s a connection forwarder thing in docker (I don’t remember what it is called) that will listen on the real network on some specific port, and forward stuff coming in there to the container’s IP and port. So if you have a docker config file with:
ports:
- “90:80”
That is configuring the forwarder to listen on the host’s IP(s) on port 90, and forward anything coming in there to this container’s IP, port 80.
Normally the only port set up to be reachable from the real network like this is the port used by the reverse proxy (port 443 usually). It forwards connections on to the other containers within that internal docker network on ports it can talk to but the real network cannot.
I apologize for not being precise enough and thank you for looking into it.
TLDR; It seems it works as designed, all good.
To keep things simple, the tests were performed to port 80 without encryption (SEAFILE_SERVER_PROTOCOL=http). Caddy is used as the reverse proxy, which is the default in Version 12.
The hostname of the docker server (seafile.local) resolves to a local adress: 192.168.xxx.xxx
SEAFILE_SERVER_HOSTNAME points to a dynamic dns adresss to my internet address (91.xx.xx.xx) and is port forwarded 80:80 to the local addess mentioned above.
If I point a browser to ${SEAFILE_SERVER_HOSTNAME} everything works as expected.
If I use local hostname or the local ip address no connection is established.
But now, looking at the caddy logs this is probably what is to be expected: {“http”:{“servers”:{“srv0”:{“listen”:[“:80”],“routes”:[{“match”:[{“host”:[“theearlytimes.xxx.org”]}]
Thanks again.