Consul: UI: Provide a path prefix

[kvz]

Hi,

I'm trying to get the UI served from behind HAProxy, similar to https://github.com/prometheus/promdash#deploy-behind-a-reverse-proxy:

To deploy PromDash behind a reverse proxy you can set a global path prefix using the environment variable PROMDASH_PATH_PREFIX. Once set all URLs will start with the given prefix.

In the end, I'd like to be able to access many services on the same domain & port, but separated by url like so:

• <domain>/consul
• <domain>/prometheus
• <domain>/promdash

These will be routed to the correct backend servers/ports (8500, 9090, 3000) in this case.

The problem is of course that the UI will promote links without knowledge of the /consul prefix. I've searched documentation and issue tracker but could not find anything relevant.

Is there a way I could tell the Consul UI to prefix all its links similar to how prometheus / promdash do it?

[highlyunavailable]

This would be really nice to have, and also the ability to prefix the HTTP API.

I used nginx proxy_pass for this. Provide a URI and it will rewrite the location. I'm not saying that it wouldn't be nice to have a prefix - it certainly would - but this is a workaround that will let you add /consul before the url. It should be something like:

location /consul/ {
    proxy_pass http://127.0.0.1:8500/ui/;
}

One other problem I had is that the UI doesn't have any knowledge of a prefix for the /v1/ path (the actual HTTP API) so I had to add another proxy_pass for that so that the UI could actually load data, because all the UI does is load a static page which then does JSON requests against the HTTP API via the /v1/ endpoint.

[kvz]

Thanks @highlyunavailable ! That was very helpful.

In case it helps anybody, I applied your workaround in HAProxy like so:

frontend http-in
    mode http
    acl is_consul path_beg /consul/
    acl is_consul path_beg /v1/

    use_backend consul     if is_consul
    use_backend promdash   if is_promdash
    use_backend prometheus if is_prometheus

backend consul
    mode http
    reqrep ^([^\ ]*\ )/consul(.*)     \1/ui\2
    server 127.0.0.1:8500

[brunomacf]

+1

[relaxdiego]

From https://github.com/joyent/containerpilot/issues/158:

Alternately, depending on how much hacking you feel like doing, it looks like all
the URLs that the Consul client uses are hard-coded but every one of them passes
thru the newRequest function. If you injected a prefix into the path at that point (by
forking your own Consul client and building your own ContainerPilot with it) you could
override Consul's behavior. Given that hashicorp/consul#1382 is open it's feasible that
you could get this sort of behavior accepted upstream too.

What does HashiCorp think about this solution? I'd be happy to work on it if nobody else is/has.

[cyrilgdn]

Hi,

We have also a dirty proxy to mask /ui behind a /consul path but now that Nomad has an ui on /ui and /v1 too, we can't use both ui on the same domain name :(

[oninoshiko]

I'm working on doing exactly what everyone else here seems to be doing. While nginx's proxy_pass works for the basic /ui, as @highlyunavailable notes something else is definitely required to proxy /v1/ which does seem desireable.

[vzabawski]

Same here.
I was trying to hide Consul and Vault behind Nginx proxy and it seems like the page is being loaded without its resources. Here's the output from Chrome debug console:

GET https://creds.example.com/ui/assets/vendor-c3a9380433ef2f2efb4ed437d3b54b31.css 404 (Not Found)
creds.example.com/:16 GET https://creds.example.com/ui/assets/consul-ui-fd032aa6d4c81cb6714bde7019fca516.css 404 (Not Found)
creds.example.com/:29 GET https://creds.example.com/ui/assets/vendor-314559974db7480f89eff5585c15bd34.js 404 (Not Found)
creds.example.com/:30 GET https://creds.example.com/ui/assets/consul-ui-5b92b4b084738a6c8d4662cd5dd81e58.js 404 (Not Found)

Config:

location /vault/ {
    expires off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://vault.server:8200/ui/;
  }

  location /consul/ {
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://bootstrap.consul:8500/ui/;
  }

Vault UI returns the same errors.

[wxiaoguang]

It's strange that the /ui/ can be customized now, but the /v1/ is still hard-coded and can not be changed .... the customized web ui path won't work for most cases if the /v1/ can not be changed.

[zopar]

Hi
I found a solution also for traefik on docker
suppose you have consul with consul ui on /consul and also an nginx container that need to be on /
so:

http://host/consul -> consul ui
http://hosts/v1/ -> v1 note the final /
http://host/ -> nginx

on consul you need these rules on traefik (port 8500)

• traefik.v1.frontend.rule=PathPrefix:/v1/
• traefik.consul.frontend.rule=PathPrefix:/consul

On nginx (port 80)

• traefik.frontend.rule=PathPrefix:/

Note that on /v1 reply nginx with 404, and on /v1/* reply consul
if you use /v1 in the traefik rule always reply consul
in any case it is not a problem because consul needs an url with more than only /v1 but like for example /v1/catalogue/datacenters

Hope this help other people :)

[Fuco1]

But remember this isn't really a solution because for example nomad and vault also expose /v1/ api endpoint so you can't use those then.

[zopar]

Uhm probably for this particular case you could use multiple rules for every subpath of /v1/
but it is tricky and not easy
The real solution is to offer the possibility of change v1 path. For consul is possible without too much work: https://github.com/hashicorp/consul/issues/1930#issuecomment-521942913

[pvandervelde]

@s-christoff Is there any movement on potentially fixing the /v1 issue which means that lots of rewrite rules are necessary to make the Consul UI work behind a reverse proxy?

[s-christoff]

Hey @pvandervelde, we have been discussing it internally a bit. It is a hefty undertaking and it's not currently on our timeline right now to tackle. There is the option of putting a http proxy in front of Consul if this is absolutely necessary for now, though.
Thank you for bringing this up!

[pvandervelde]

Fair enough. At the moment we just redirect the /v1 path to consul but that means we can't redirect it for nomad or vault (or any other tool that uses /v1)

[i0rek]

This is now possible with ui_content_path.

[samrocketman]

What's the usage?

[samrocketman]

Looking at https://github.com/hashicorp/consul/pull/6601/files ... I'll have to test. I'm not sure this change is the intent of this issue.

At a high level it looks like a rename of s/ui/consul/ but the intent of the base path (at least for me) would be to serve the entire service under a base path. Meaning I would access the API at /consul and the UI at /consul/ui/.

I would be serving all of the hashi services within the same proxy host as a frontend if I could do this.