Reverse proxy entries for enabling Kui behind nginx

[MeghanaSrinath]

We have a nginx pod running as a LoadBalancerservice in our cluster. We have deployed kui as a ClusterIPservice in the same cluster and trying to access kui behind the nginx LoadBalancer at a pathhttps://<nginx_ip>/kui/. Below entries are added in the/etc/nginx/sites-enabled/nginx.conffile of nginx pod.

set $upstream_kui http://kui.namespace.svc.cluster.local:80;
location ~* (/kui/|/static/(.*)$|/static/media/(.*)$|/kui/exec|/css|/js|/json|/html|/main/(.*)$|/bash/(.*)$|/exec) {
rewrite /kui/(.*)$ /$1 break;
proxy_pass $upstream_kui;

On hitting https://<nginx_ip>/kui/, we are able to get the Kui page in the browser, but it is stuck at Please wait while we connect to your cluster state and the in the network trace, we are getting504 Gateway Time-out when kui is trying to hit /exec endpoint. Can you please let us know if we are missing anything here and if Kui supports the rewrite block as we have provided.

Our requirement is to run multiple kui behind nginx at a different path so that users can access it at a specific path, then just running it as a LoadBalancer.

[MeghanaSrinath]

@starpit , Would you be able to provide any directions on this.

[starpit]

Howdy. If you are running Kui behind a contextRoot, you may need to specify this when you build your webpack bundles. One way to do this is to add a contextRoot field to your client's config.d/client.json. Here is where the default client stores it; note that the default value is empty, i.e. the webpack bundles will be built as if Kui is served from /.

https://github.com/IBM/kui/blob/master/plugins/plugin-client-default/config.d/client.json

Does that sound like I'm barking up the right tree?

[MeghanaSrinath]

We are actually running multiple kui pods behind our application nginx in our setup. So we are looking at accessing each of these kui instances at different path, say at https://<NginxIP>/kui1 and https://<NginxIP>/kui2 and so on. For this to work , we add the reverse proxy entries in our application nginx where we are doing a rewrite from/kui1 or /kui2 to the path /. Since the application is serving at / path, on doing a rewrite from any path to /, it should work is what we are assuming. We are able to get the UI also loaded in this case, but not able to get the bash opened as stated above. Does this scenario make it more clear?

And as per your suggestion, we modified the client.json and added the below entry so that the application serves at /kui path rather than / path.

{
  "contextRoot": "/kui"
}

But on building the dockerfile and running it, we were not able to access the UI at all. Below is the error that we got

[29/Oct/2020:11:38:46 +0000] "GET /main.636edc3e36ce44444734.bundle.js HTTP/1.1" 404 564 "http://<IP>:9080/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36" "-"
2020/10/29 11:38:46 [error] 8#8: *7 open() "/usr/share/nginx/html/main.636edc3e36ce44444734.bundle.js" failed (2: No such file or directory), client: <IP>, server: , request: "GET /main.636edc3e36ce44444734.bundle.js HTTP/1.1", host: "<IP>:9080", referrer: "http://<IP>:9080/"

Are we missing anything here? Can keep kui serving at / path (i.e, not modify the client.json) and find a way to bring up kui at a different path in the browser by using the rewrite rules?

Appreciate the suggestions @starpit

[MeghanaSrinath]

@starpit , would you be able to check this out. Since modifying the contextRoot in client.json didnt help, we tried to modify this directly in the config.js file as below, by serving kui at /kui:

if (contextRoot && !/\/$/.test(contextRoot)) {
      contextRoot = contextRoot + '/kui'

But on trying to access this behind our application nginx, we are getting a 404. So we are kind of stuck here. Can you give us any pointers please :) We are trying to access multiple kui instances in the browser behind the same nginx proxy server by modifying the reverse proxy entries in the nginx conf file.

[MeghanaSrinath]

Cc @starpit

[starpit]

howdy, sorry for the delay. i was mostly off last week on family matters. back now!

[starpit]

If I understand correctly, it sounds like you have multiple context roots. Kui currently uses a static context root, and webpack only allows one such static context root. Webpack does support dynamic context roots, as explained in this section: https://webpack.js.org/configuration/output/#outputpublicpath

If you'd like to PR support for dynamic context roots, you probably will need to add a free variable here: https://github.com/IBM/kui/blob/master/packages/core/templates/index.ejs#L34-L36

i.e. just like we do for the nonce, you may be able to do for the dynamic context root? Then, you can have nginx insert the proper value, just as it does for the nonce, via an nginx rewrite rule?

[MeghanaSrinath]

Thanks for getting back @starpit

For simplicity, lets keep a single context root which is the default value of /as per the original design. Now, we are trying to get kui loaded at a random path (say /kui1) and then using nginx rewite rules, we will rewrite from this random path(/kui1) to /, which is there in the context root. So to keep it simple, on hitting <IP>/kui1, nginx will use the below rewrite block and rewrites the /kui1 path to / path where the application context root is set.

set $upstream_kui http://kui.namespace.svc.cluster.local:80;
location ~* (/kui/|/static/(.*)$|/static/media/(.*)$|/kui/exec|/css|/js|/json|/html|/main/(.*)$|/bash/(.*)$|/exec) {
rewrite /kui/(.*)$ /$1 break;
proxy_pass $upstream_kui;

So eventhough we hit <IP>/kui1 in the browser, kui should work as though it is serving from the / path as per the design. This method works and kui is able to get loaded during our testing. But while trying to connect to the cluster, we are getting 504 gateway timeout on the /exec endpoint. Once this is recified, kui should work seemlessly with this routing configuration, without having to modify anything at the kui end. All routing and rewrite should take place at the application nginx end. Does this give a better idea?

[fejta-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes-sigs/kui/issues/6061#issuecomment-846557419): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.