Nginx container

Our reverse proxy runs on storage1 in a docker container. It is useful because:

• We have a single domain that is used to access multiple websites/nodes by memorable URLs instead of IPs.
• It provides a TLS security layer, so any http traffic becomes secure https.

Updating the configuration

Warning: Configuration may be non-trivial depending on the proxy scenario.

To update the nginx config, re-run a new reverseproxy image: edit the config file /home/jurgen/dc/nginxproxy/nginx.conf and rebuild the dockerfile tagged as reverseproxy. Then docker-compose up -d will restart the proxy with the latest reverseproxy image.

Upstream targets

• hpc.radiology.hku.hk/wiki maps to localhost mediawiki: containername/wiki for port 80, 443
• hpc.radiology.hku.hk/git maps to localhost gitlab: containername/git for port 22, 80, 443

• hpc.radiology.hku.hk/cpu1 maps to remote node cpu1 for port 22
• hpc.radiology.hku.hk/gpu1 maps to remote node gpu1 for port 22
• hpc.radiology.hku.hk/gpu2 maps to remote node gpu2 for port 22
• hpc.radiology.hku.hk/gpu3 maps to remote node gpu3 for port 22

Opted not to implement urls for the 4 compute nodes to prevent all traffic being funneled through a single server.

Path based proxy resolving vs domain based

Note that symmetric pathing means mediawiki and gitlab may not host on their default container path /; asymmetric proxying creates issues (e.g. link breakage) that are hard to solve. Even better would be to use tier-4 domain-based proxying (e.g. wiki.radiology.hku.hk), but that would require domain delegation from ITS and running our own DNS server.