Closed MeghanaSrinath closed 3 years ago
@starpit , Would you be able to provide any directions on this.
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?
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
@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.
Cc @starpit
howdy, sorry for the delay. i was mostly off last week on family matters. back now!
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?
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?
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
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
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
@fejta-bot: Closing this issue.
We have a nginx pod running as a
LoadBalancer
service in our cluster. We have deployed kui as aClusterIP
service in the same cluster and trying to access kui behind the nginxLoadBalancer
at a pathhttps://<nginx_ip>/kui/
. Below entries are added in the/etc/nginx/sites-enabled/nginx.conf
file of nginx pod.On hitting
https://<nginx_ip>/kui/
, we are able to get the Kui page in the browser, but it is stuck atPlease 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.