I'm currently running with docker (compose) with caddy routing and terminating https for several apps on the server. For the Joplin database container, I just have the 5432 port exposed on the host but I can't seem to connect clients to it over the lan.
I have access to the admin panel working with Caddy as a reverse proxy. But what about the database connection? I'm having trouble with clients connecting. Is there supposed to be a TLS connection (with certificates) for this? Should I serve this over 443 (with a different subdomain) and then caddy it to port 5432 like I'm doing with the 22300 admin interface?
Joplin clients connect to the Joplin Server "app" container not directly to the Postges "db" container. Your Joplin clients connect to the server using whatever your APP_BASE_URL= is set to. The server alone connects to the database.
When you log in to the server it tells you how to connect to it.
So if your APP_BASE_URL is https://joplin.example.com your admin interface URL is https://joplin.example.com/login and your sync URL is https://joplin.example.com
Yup, just before your reply I realized that the exposed port 5432 in the docker compose file is just a red herring. The "app" must connect to the database over the docker network.
I think I've got my head mostly around this now.
The one question still lingering is about why that port is exposed. Is it for a backup strategy?
I think that it just allows the app container to talk to the db container. They do not have a dedicated network like some configs I have seen.
In fact in my docker-compose file my ports are tied to localhost so that they cannot be accessed from outside the server.
ports:
- "127.0.0.1:5432:5432"
and
ports:
- "127.0.0.1:22300:22300"
It seems that even though my firewall (UFW) does not allow external access to 22300 and 5432 there is something about docker that circumvents this and makes the ports accessible unless tied to 127.0.0.1.
Containers together in a docker compose usually share a default network that is automatically created.
If I'm not mistaken, unless you specify the loopback device (127.0.0.1) when publishing the port, it's the same as 0.0.0.0 which ties it to all the interfaces on the host.
Hmm. I just reread your post and realized that I missed part of what you were saying. I did not realize that docker published ports are bridged ahead of the firewall on the host. Definitely something to watch out for.
