Difficulty: Intermediate
Estimated Time: 20-40 minutes

TLS-enabled Nomad clusters configured to perform client validation require that any client, even Web UI users, present a valid Nomad client certificate. Most users are more familiar with anonymous TLS, and providing and installing the client certificates for every UI user could be rather time-consuming.

A reverse proxy is an application that sits in front of one or more web servers, intercepting requests from clients. This location in the request flow allows for several benefits:

  • load balancing - As connections come in to the proxy, it can route them to one or more servers. Typically there are several load balancing methodologies, including session affinity or "sticky" sessions. This enables operators to distribute application traffic over many instances of the application, thus increasing its availability.

  • TLS termination/uplift - Since the proxy server creates a new connection on behalf of the user, it can use a different TLS configuration for the client-side connection and the server connection. This fact allows operators to use a reverse proxy to terminate SSL at the proxy so that application traffic is received unencrypted. It also allows a connection to be "uplifted" to TLS as it goes from client to proxy to server.

  • application aggregation - Many proxies provide the ability to route inbound requests to more than one backend application based on the hostname that the request was sent to or components of the URL's path. This can simplify the end user experience when trying to reach applications.

To ensure every feature in the Nomad UI remains fully functional, you must properly configure your reverse proxy to meet Nomad's specific networking requirements. In this hands-on lab, you will configure NGINX as a TLS-uplifting reverse proxy.

This guide will explore common configuration changes necessary when reverse proxying Nomad's Web UI. Issues common to default proxy configurations will be discussed and demonstrated. As you learn about each issue, you will deploy NGINX configuration changes that will address it.

Next steps

In this hands-on lab, you set up a reverse NIGNX proxy configured for the Nomad UI. You also explored common configuration settings necessary to allow the Nomad UI to work properly through proxy—connection timeouts, proxy buffering, WebSocket connections, and Origin header rewriting.

You can use these examples to configure your preferred proxy server software to work with the Nomad UI. For further information about the NGINX specific configuration highlighted in this hands-on lab, consult:

Don't forget to visit learn.hashicorp.com/nomad for more Nomad guides.

Deploying Nomad UI with a Reverse Proxy

Step 1 of 8

Provisioning Extra Course Components

There are a few components that need to be added to the environment. We are adding them now. Please wait for the complete message and then move to the next step.

Example Output

- Fixing Journal
- Installing pyhcl

and concluding with

- Complete! Move on to the next step.

Once you see this message, you are ready to continue.

Terminal
Nomad UI (non-proxy)
Nomad UI (proxy)
This tab will not be visible to users and provides only information to help authors when creating content.

Creating Katacoda Scenarios

Thanks for creating Katacoda scenarios. This tab is designed to help you as an author have quick access the information you need when creating scenarios.

Here are some useful links to get you started.

Running Katacoda Workshops

If you are planning to use Katacoda for workshops, please contact [email protected] to arrange capacity.

Debugging Scenarios

Below is the response from any background scripts run or files uploaded. This stream can aid debugging scenarios.

If you still need assistance, please contact [email protected]