[feature] /ui/nomad - Githubissues

jozef-slezak commented 5 years ago

Could you please support /ui/nomad (instead just /ui). This helps proxy-ing the web console. Both Consul and Vault already have this feature

/ui/consul https://github.com/hashicorp/consul/issues/1930
/ui/vault

Reopened https://github.com/hashicorp/nomad/issues/4479

Oloremo commented 3 years ago

have the same issue

jozef-slezak commented 3 years ago

Please, could Nomad 1.x have this simple feature? (Consul had the same feature long time ago)

schmichael commented 3 years ago

I'm curious what the benefit of this would be without a similar option to alter the base path of the REST API? How will a proxy know where to route REST API requests when they all target /v1/ prefixes?

I saw one mention of routing based on the Referer header, but I don't consider that a sufficient workaround since it would break for non-browser clients that also wish to query Consul/Nomad/Vault through a reverse proxy. Even ignoring non-browser clients, it seems fragile to rely on a Referer header like that, but I am not a webdev so I could be wrong.

Is using distinct subdomains for each HashiCorp product unworkable? eg {consul,nomad,vault}.internal.example.net? A wildcard certificate could provide TLS coverage for all subdomains on the frontend, and the Host: header is a well established method of routing requests to backends.

To be clear I'm not against this feature! I've very sympathetic to how awkward it is to access HashiCorp products through a proxy and appreciate the numerous benefits a proxy offers! I just want to make sure we arrive at the best possible solution and not just change the headache users have to put up with.

Oloremo commented 3 years ago

We're in a situation when we can't control domain names but can control the subdirectory.

We use it for Consul and Vault and only the Nomad is the issue.

schmichael commented 3 years ago

We use it for Consul and Vault and only the Nomad is the issue.

Using the Referer routing for the REST API? I just want to confirm that's sufficient as we ought to document it if it is. The issue with non-browser clients still frustrates me, but maybe Nomad can leapfrog the other two by also prefixing our REST API. :sweat_smile:

Oloremo commented 3 years ago

Re-checked... no we don't, in fact, use ui_content_path, it was put into the TODO list so it seems.

But the need is still there and I glad Consul has support for that. Seems like right now we can only access Consul UI on our envs there we can control domain names and with proper reverse proxy configuration we will be able to do it on all envs.

radriaanse commented 3 years ago

Another use case is that it can be handy when you want to reach the UI on a specific node within a cluster without having to resort to more DNS names.

Let's say you have nomad.internal.tld DNS round-robin'ed over 3 Nomad servers with a reverse proxy in front of them, then without any further DNS changes (like nomad.serverN.) it's easy to just expose serverN.internal.tld/<nomad/consul/vault> as well. I use this mostly for UI access in case of debugging/manual things, so less relevant for API routes in my opinion.

schmichael commented 3 years ago

I use this mostly for UI access in case of debugging/manual things, so less relevant for API routes in my opinion.

The Nomad UI lets you access information from any node in the cluster from any node in the cluster. If you can reach /ui/ on a client node, you can stream agent logs from any client or server node thanks to the agent/monitor API: https://www.nomadproject.io/api-docs/agent#stream-logs

Allocation logs on any client node are likewise available from any UI you access: whether client or server.

Is there a feature we've missed that requires direct access to a specific node? We've tried pretty hard to avoid the problem of having to access the /ui/ endpoint on any particular node. It should be indistinguishable unless you're running mixed Nomad versions. It should even work across federated regions: if you can access the UI on any node in a federated cluster (and it can reach it's /v1/ REST API), you should have equivalent-to-direct access to every node in your globally federated clusters.

radriaanse commented 3 years ago

That's a fair point indeed, and now that I think about it I don't see anything missing in that logic besides that it might help with a situation where a node has separated itself from their peers. But to be honest I don't think I've ever had that come in handy since that kind of issue usually indicated other problems as well and having access to an isolated node won't solve much in that regard.

It was already a fairly incidental use case and more of a habit of setting things up like that.

schmichael commented 3 years ago

Thanks all, chatting with folks on Consul and Vault internally it seems like the API path is an open issue for them as well. No timeline yet, but this is definitely something we'd like to fix across all of our products to ease reverse proxying to an entire HashiStack's UI and API.

awarner-greshamtech commented 3 years ago

If I could vote for this issue, I would. We are fleshing out our use of the HashiCorp stack and would really like to proxy all three UIs.

Fuco1 commented 2 years ago

We use it for Consul and Vault and only the Nomad is the issue.

Using the Referer routing for the REST API? I just want to confirm that's sufficient as we ought to document it if it is. The issue with non-browser clients still frustrates me, but maybe Nomad can leapfrog the other two by also prefixing our REST API. sweat_smile

With consul using ui_content_path => '/consul/', the following traefik 2.* configuration works. Notice that since the vault rule is under /ui which is nomad root, it has higher priority to go to vault instead of nomad. The setting for consul is necessary because as far as I remember it defaults to /ui as well and that would be impossible to differentiate.

Note that you can also use this from non-browser client by simply setting the header manually. It's awkward but works. Another option is to add X-HashiCorp-Service or whatever else and route based on that (for example curl -H "X-HashiCorp-Service: nomad).

[http.routers]
  [http.routers.nomad]
    rule = "PathPrefix(`/ui`) || PathPrefix(`/v1/client/fs/cat`) || HeadersRegexp(`referer`, `https://internal.in/ui/.*`)"
    priority = 1999
    service = "nomad"

  [http.routers.consul]
    rule = "PathPrefix(`/consul`) || HeadersRegexp(`referer`, `https://internal.in/consul/.*`)"
    priority = 1000
    service = "consul"

  [http.routers.vault]
    rule = "PathPrefix(`/ui/vault`) || HeadersRegexp(`referer`, `https://internal.in/ui/vault.*`)"
    priority = 2000
    service = "vault"

[http.services]
  [http.services.nomad.loadBalancer]
    [[http.services.nomad.loadBalancer.servers]]
      url = "http://nomad.service.consul:4646/"
  [http.services.consul.loadBalancer]
    [[http.services.consul.loadBalancer.servers]]
      url = "http://consul.service.consul:8500/"
  [http.services.vault.loadBalancer]
    [[http.services.vault.loadBalancer.servers]]
      url = "http://vault.service.consul:8200/"

courtland commented 1 year ago

I am also interested in this feature. I have /ui working reasonably well, albeit without a functional exec API (WebSockets).

Since Hashi and Traefik are collaborating more these days, it would be great to have some kind of official support/docs for reverse proxying the Nomad UI with an arbitrary path prefix. Similar to this: https://developer.hashicorp.com/nomad/tutorials/manage-clusters/reverse-proxy-ui