[feature] /ui/nomad

[jozef-slezak]

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]

have the same issue

[jozef-slezak]

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

[schmichael]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[krishnaprateek6]

@schmichael Can we expect this feature to be added in nomad please, as its been couple of years since it was requested. Though we can access nomad using /ui but because we have other site conflicting it would be great if we had an option to customize the nomad ui path through nginx to something like /ui/nomad. Consul does support this feature with ui_config path.

[krishnaprateek6]

@lgfa29 can we expect this feature any time soon please?

[mikenomitch]

Hey @krishnaprateek6, this is a surprisingly tricky feature to implement, but it is on our radar. Let me run it by the UI engineers tomorrow and get a sense if we can get it into the 1.6.X or 1.7 roadmap (but no promises! 😄). I am hoping we'll have some time for medium-sized features like this in the near future, but I don't want to speak for the UI engineers (I am but a PM).

Will get back to you soon.

[krishnaprateek6]

Hey @krishnaprateek6, this is a surprisingly tricky feature to implement, but it is on our radar. Let me run it by the UI engineers tomorrow and get a sense if we can get it into the 1.6.X or 1.7 roadmap (but no promises! 😄). I am hoping we'll have some time for medium-sized features like this in the near future, but I don't want to speak for the UI engineers (I am but a PM).

Will get back to you soon.

Thank! You

[krishnaprateek6]

@philrenaud Just checking if there is any kind of update on this feature please??

[philrenaud]

I was able to do some digging around and was able to get the happy path working, but there are lots of edge cases that popped up. It's still on our radar!

[krishnaprateek6]

@philrenaud just checking on this request please is there any tentative timeline for this feature?

[philrenaud]

Hi again @krishnaprateek6 — I ran into some (soft) blockers for this that made me change course and onto other issues for the moment. We will revisit this soon, but the initial issues I had around blocking queries/alloc exec over proxy will take some time to sort out. Thank you for your patience with us on this!

[krishnaprateek6]

@philrenaud Thanks! for the update, Just checking if we have some traction on this?

[philrenaud]

Hi @krishnaprateek6, unfortunately no traction on this yet. It's still on the list, but we've been wrapped up with a few other features lately.

[ebarriosjr]

Hi @philrenaud, do you have any update on this? Thanks!

[philrenaud]

Hi @ebarriosjr, no updates yet, and I promise to post here when I have some. I am going to try a few underlying upgrades to see if this becomes a little less murky to do at some point, but that development is not yet scheduled (thank you for your patience on this!)

[jurgenweber]

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 Ability to modify context path of the UI consul#1930
• /ui/vault

Reopened #4479

I realise this is a little off topic, but you say vault works on /ui/vault but I keep getting rewritten to /ui with vault. Is there a setting here I can not find?

nomad support would be helpful also.

Thanks

[krishnaprateek6]

Do we have any tentative timelines on when this will be available please

[tgross]

@krishnaprateek6 unfortunately we can't commit to timelines on features outside of our Enterprise Support contracts. We'll update this issue as it's being worked on.