Consider load balancer/reverse proxy

[gothub]

A reverse proxy (RP) could be used to route traffic to services running on the NCEAS k8s cluster, and
to other DataONE services, as required.

benefits of using a reverse proxy / load balancer

• DataONE services available from different servers could be available from one endpoint
  • if the api.dataone.org DNS entry resolves to the RP, traffic could be routed to services that are on different servers. For example, these services could all be access via the RP:
    • the quality engine is located at https://docker-ucsb-4.dataone.org:30443/quality
    • when deployed in production, bookkeeper will be located at https://docker-ucsb-4.dataone.org:30443/bookkeeper
    • the metrics services is currently located at https://logproc.dataone.org/metrics
• All services routed through the RP could use the standard TLS port, for example:
  • https://api.dataone.org/quality (implicitly access port 443)
  • https://api.dataone.org/bookkeeper
  • https://api.dataone.org/metrics
  • Note: it is not advised to use port 443 for the current configuration of the quality service at https://docker-uscb-4.dataone.org, for the 'k8s baremetal configuration', as detailed here, esp. under the section 'NodePort Is a Pain for You'.
  • Note Reverse proxy / load balancer options #2: access to k8s services would need to be reconfigured to use a 'loadBalancer' port config, instead of the current 'nodePort'

costs of using a reverse proxy

• the reverse proxy itself becomes a single point of failure, unless some mechanism such as a a DNS round robin is implemented, which switches between multiple RPs. See https://stackoverflow.com/questions/7943211/web-app-high-availability-how-to-prevent-a-single-point-of-failure
• cost of installation/config/maintenance of a load balancer

[gothub]

Superceded by https://github.com/DataONEorg/gnis-ld.org