No support for Jaeger behind a reverse proxy

[delaman]

Jaeger does not run behind a reverse proxy due to how the css and js is being loaded.

<link href="/static/css/main.123456789.css" rel="stylesheet">

This can be corrected with something like

<link href="./static/css/main.123456789.css" rel="stylesheet">

Similarly with the js file.

Thanks

[yurishkuro]

@delaman This blog post shows running Jaeger UI behind a proxy without the changes you suggested. How is your setup different?

@jpkrohling did your blog post get published too?

My concern with adding ./ prefix is that I am not sure how well it would work when the URL contains other segments, like the trace view https://jaeger.domain.com/trace/4380652658ee - the browser will try to load static files from /trace/static/css/ because ./ would be relative to /trace/

[jpkrohling]

Yes, it's published here: http://www.hawkular.org/blog/2017/07/jaeger-with-security-proxy.html , but not sure my approach would solve this.

[delaman]

My reverse proxy setup has a baseurl that is not "/" it is something like "/xyz". This is why jaeger does not work with my setup. Again the only two issues is the loading of two static files namely the .js file and the .css file.

@yurishkuro is the "/trace" routing handled by angular?

[yurishkuro]

Routing is handled by React.

cc @tiffon

[tiffon]

@delaman, the UI is built on top of Facebook's Create React App. One of the implications is static assets are added to the HTML file dynamically (docs) — note the <script> tag is not in the HTML file.

Initial reading suggests modifying the script tag to use relative imports would entail breaking with Create React App. (Turns out this is not accurate.) Also, I believe @yurishkuro is right in that the static assets for any non-root page would refer to the wrong path.

Have you confirmed the issue is limited to the static assets? For instance, what response do you get from the following (assuming /xyz is the prefix on the URL):

• /xyz/api/traces (should be 400 with empty JSON object)
• /xyz/search (should be 200 with index.html served)

Also, depending on the reverse proxy you're using, can you configure rewrite rules to strip the /xyz before passing the request downstream?

[delaman]

/xyz/api/traces traces does give a 400
/xyz/search does give a 200

My reverse proxy is striping out the xyz This is how the main index page is being loaded. If I don't remove the /xyz with the reverse proxy than I do not even get the failed main.css and the failed main.js errors.

[tiffon]

@delaman, got it, thanks.

Further searching revealed a homepage setting in Create React App. If set to /xyz it will adjust the static asset URLs.

But, with that change, the front-end routing will likely always show a not found page, and the ajax requests to load data are based on / so would return 404s if the app got that far.

Side note: The homepage config option is a build-time configuration value; it's baked into the HTML when the static assets are bundled. The main way to leverage it would be to generate a custom build based on your URL prefix and refer the query service to your generated build via the --query.static-files cli option of the jaeger-query command.

One approach to address the issue you've raised is to base front-end routing and ajax requests on the package.json#homepage setting. That would have the downside of still requiring a custom build based on the homepage setting.

On the other hand, we can look into changing the URL patterns to something along the lines of /trace?id=some-id. While not elegant, it would circumvent the need for custom UI builds to handle URL prefixes.

Something that came to mind as a short-term solution is a rewrite rule based on the referer header, but the front-end routing issue would still crop up.

[tiffon]

@delaman Wanted to share an update.

After discussing the issue with the team, we're thinking the approach of changing the URL patterns is not going to be feasible for the long-term.

On the other hand, an open PR (#53) adjusts front-end routing and AJAX calls so they are compatible with the homepage setting in package.json. Once it's merged, you should be able to create a custom build with homepage set to /xyz (or whatever your prefix is) and you should be good to go.

I have confirmed it works, but I was using a sort of haphazard nginx.conf to test it out.

[yurishkuro]

@tiffon do we have instructions somewhere on what people need to do to make use of the change from #53?

[tiffon]

@yurishkuro No we do not; thanks for brining that up. I'll add something to the readme. On Aug 23, 2017 3:36 PM, "Yuri Shkuro" <[email protected]> wrote: @tiffon <https://github.com/tiffon> do we have instructions somewhere on what people need to do to make use of the change from #53 <https://github.com/uber/jaeger-ui/pull/53>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/uber/jaeger-ui/issues/42#issuecomment-324439930>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACMpUeeatIlu17EQhOKEVwnprpx3TEGJks5sbH81gaJpZM4Oki-L> .

[Ziyang2go]

@tiffon do we have a documentation for the solution of this issue ? thanks

[tiffon]

@black-adder Presently, no. I need to add something to the readme or deployment docs.

[radekg]

I'd be interestd in knowing what the progress is as I'm facing a similar deployment to what the top issue is. We're looking at deploying the ui with mesos / similar and giving the app the / on nginx feels a bit limiting.

[tiffon]

@Ziyang2go, @radekg

One should be able to use a URL prefix with the Jaeger UI.

The steps necessary:

• Checkout the Jaeger UI repo
• Modify package.json#homepage value to be whatever your prefix is (I tested with "/xyz")
• Build the UI
  • yarn && yarn build
• Configure the query-service to serve the generated statis assets (--query.static-files)

I was able to get this to work, but it's more of an approximation than a genuine test context as we use a sub-domain instead of a path prefix.

Any details about your experience in giving this a try would be appreciated. I'll add this to the deployment docs once we have some confirmation that it's good-to-go.

[yurishkuro]

@tiffon ideally we want to avoid asking people to rebuild the UI. Could the same be achieved at runtime by giving the prefix to jaeger-query?

[radekg]

@tiffon @yurishkuro the no rebuild approach would be preferred, I could try coming up with a pr for that, if that helps. The preferred way would be to have this configurable with a switch / command line argument.

I understand the point with regards to a subdomain but sometimes we might want to use a shared nginx instance with a proxy_pass instead of a dedicated nginx for the ui.

[yurishkuro]

@radekg doesn't nginx support multiple domains in a single instance?

[tiffon]

@yurishkuro Possibly. The main sticking point will be linking to the static assets from index.html. If we are comfortable re-writing the URL in the HTML file, then, yes, we should be able to establish the URL prefix at runtime.

We will also need to get the value to JS. I recommend an approach that is similar to the UI config but for values originating from the server, i.e. distinct from the UI config. This will support #113.

@radekg Thanks for weighing in.

[yurishkuro]

Rewriting static assets in index.html doesn't sound too hard.

For the API calls, why can't the prefix come from UI config? Just curious. We can do it as a static variable similar to the UI config itself.

[radekg]

@tiffon @yurishkuro nginx does support multiple subdomains, the main point is, from past experience (unless something has changed in nginx over the last year or so), a server which proxy rewrites /, rewrites that for all server names. It is essentially the same request as what has been requested

• here: Ability to modify context path of the UI hashicorp/consul#1930
• and here: Zeppelin 337 configurable context path (2) apache/zeppelin#429

I think, in terms of react, it's similar to this: remix-run/react-router#353.
Preferably, the setting should be applicable at runtime, there should be no compilation required.

[tiffon]

Definitely applicable at runtime is preferable over rebuilding the UI. This is possible if we rewrite the URL for the static assets in the index.html.

@yurishkuro If we serve the value from the UI config, it means the query-service will need to be able to extract that value from the UI config, which restricts the UI config, moving forward, and makes it impractical for the UI config to be JavaScript (#123).

Defining a CLI parameter for the path-prefix sounds great, IMO. Then, if we're dumping non-UI-config data into the UI, we might as well plan for the future and give it the full treatment we gave the UI config (as a static variable, returned from a function). This will lay the groundwork for #113, which is to expose the version of the UI and query-service to the user (in a footer or something).

[yurishkuro]

If we serve the value from the UI config, it means the query-service will need to be able to extract that value from the UI config

query-service will read the path from CLI/ENV. It can either inject it into the UI config, or if we want to keep it separate (because UI config is coming from an external file) we can have another static section in index.html that query-service will populate, including #113.

[tiffon]

@yurishkuro I'm a proponent of the latter, another static section in index.html.

[yurishkuro]

ok, let's make the necessary changes to index.html and the ui, and then we can add configuration to the query service.

[tiffon]

Marking as blocked because PR #151 is ready but the necessary work in the query-service is not ready.

[yurishkuro]

@tiffon there seems to be an alternative way via using the base HTML tag, so that we don't need to rewrite all other assets (added in Zipkin here)

[tiffon]

@yurishkuro Great find! I'm generally averse to base (I may have blocked it from my consciousness), but in this case it's looking much better than the two alternatives. I need to do a bit more testing, but I think it's going to work out.

[danwild]

I trawled a few threads before I found the answer, hot tip for anyone else - just use QUERY_BASE_PATH

[jpkrohling]

@danwild where was the first place you looked for information when you tried to accomplish that? Perhaps there's an opportunity here to improve our docs...