Subdomain based rock-on routing

I would like to run some sites and rock-ons via different docker containers and have them accessible via subdomains both internally and externally (because remembering ports is hard :wink: ). For example would go to my gitlab rock-on, to my transmission, etc (probably some custom ones as well).

I could probably set up an nginx proxy to forward around to the specific ports and some sort of local dns system to resolve internally but I was wondering if there was any more elegant solutions? I would be willing to turn it into a rockon if so.

Normally I would do this on another box but this is already running 24 and my hardware is probably already more beefy than it needs to be, so why not.

Any thoughts?

Hi Devon,

very good idea. On another box me is using mkaag/haproxy-confd for this. Confd is used to be able to react to changes on docker containers, so that new containers are automatically mapped to a domain. I guess that this is not necessary as a first step, but would still be nice. So let’s say you register a new rock-on, then the new field SubDomain could be used to register the rock-on in the “load balancer” as well.

As long as you are using the same domain and multiple sub-domains, you could use a wildcard DNS record (eg. *, so that all subdomains are automatically resolved.

So, I guess that this is the most elegant solution, if you look at other Container Solutions (like eg. coreOs), it is handled in the same way (reverse-proxy/LoadBalancer kinda thing).

Another solution would be, to use different external IPs for different containers (eg. docker run -i -t --rm -p base), but me is unsure if this is a good solution, because it will need pretty much the same config then the other solution (DNS). Pretty much using IPs instead of ports.

1 Like

One thing to remind. Port 80 is already used by the Nginx on the Host (Rockstor). Therefore this needs to use a different Host. Or the Nginx configuration is adopted to act as the Reverse Proxy.

1 Like