Difference between revisions of "Nginx container"

From radwiki
Jump to navigation Jump to search
rad>Jurgen
 
m (1 revision imported)
(No difference)

Revision as of 23:25, 10 April 2020

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

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.