ShinyProxy deletes services in namespace


#1

Hi.

I’ve being trying to run ShinyProxy inside an AWS Kubernetes cluster made with Kops. Shiny is behind and Ingress controller (Nginx) that passes the nodeport service to the ELB.

I can access shinyproxy and login. Running the hello demo or the tabsets demo takes a while (more than usual) but finally launches in grey mode (still don’t know why this is happening). After a few seconds shinyproxy starts to kill the created pods and also ALL the services in the namespace (default in this case).

Since the service is the one giving an “outside” call to the Ingress the service runs unavailable since there is no more service.

Is this the default configuration for shinyproxy?, kill the pods and all the services?

Thanks in advance.


#2

Hi,

I’ve struggled with the same problem, you can read more about it here: https://github.com/openanalytics/shinyproxy/issues/57

It’s possibly just a bug, I hope it will be fixed soon.


#3

Hello,

Yeap, thats exactly the same case. In the meantime I “fixed it” by creating a dedicated namespace for the pods that shinyproxy creates, everything else resides in the default namespace (or whatever) so the delete service procedure can’t reach my loadbalancer.

Now I’m struggling with another issue, do you know if it’s feasible to make shinyproxy work over layer 7 instead of layer 4? I’m trying to save some costs by having just one loadbalancer trough an ingress, everything works fine until the moment of accessing the app (it gets greyed out). If decleare the backend as tcp it works, but if I decleare it as http it goes gray.

Thanks for your help.


#4

Hi @jds,

Regarding the load balancer: shiny apps use websockets to provide the interactive experience. While websockets are compatible with http (both are layer 7 protocols and a websocket session always starts from an http upgrade request), they are technically different protocols.
If you debug your browser window, you’ll see that the grey screen is caused by a ws:// or wss:// request returning a 404 or similar error. I’m afraid there is no way around this; the same behaviour would be observed when connecting to a shiny app directly (without using shinyproxy).