Pre-initialise application container


#1

So we currently have Shinyproxy set up with a few applications in production, big thanks to the Open Analytics team, a point users complain to me about is waiting for the application to start up after they click on the link, which takes about
I’m wondering is there a way have a container that is already created and waiting so that when a user clicks on the link they get directed to that standby container?


Configuration option for spare docker containers
#2

Hi @akenny,

Container startup can indeed take multiple seconds, depending on a number of factors.
This is an area where we are also considering alternatives to the current ‘on-demand’ launching approach.
However, keep in mind that shiny containers are launched for one specific shiny app, which is specified in the container’s startup cmd.

The API introduced in version 2.0 offers some options in this regard:

If you are running shinyproxy in the context of a larger application, you can use the API to spawn a container at any time, for example when a user logs in in your application’s portal.

If you are running shinyproxy ‘standalone’, you could achieve the same with a custom template: in the index page (which is where the user lands after login), an ajax call could be made to the API endpoint:

/app_direct/<appname>

This will ensure that a container is spawned for the specified app. If the user then clicks on the app link, they will immediately get routed to the running container, instead of spawning a new one.

Note: if heartbeat is enabled (by default, it is), this container will automatically close unless the user interacts with it before the heartbeat-timeout expires.


#3

Hi @fmichielssen-
My docker image is about 2.5GB, when using

/app/{appname}

and clicking the link, it takes about 20 seconds to spin up the container and load the application.

I found it a bit too long - is it expected or are we doing something wrong with our setup?
Thanks for your opinion, Dylan


#4

Hi @Dylan_Cissou,

I believe docker image size is not directly related to startup time, though there may be a link in some cases.
You can check which components of your image take up the most space, using this command:

 docker history <image-name>

E.g.

docker history openanalytics/shinyproxy-demo

Usually you’ll see some large chunks taken by apt-get install or yum install commands.

Regarding startup time, here are some of my thoughts:

  • Linux-based images can start up very fast; often the bottleneck is the container’s startup command, given by either the CMD line in the Dockerfile, or the container-cmd setting in ShinyProxy’s application.yml file.

  • In the case of ShinyProxy, the startup command is nearly always R which in turn launches an embedded HTTP server to serve the Shiny app.

  • ShinyProxy will consider the container to be ‘ready’ as soon as its R process becomes responsive to HTTP requests.

  • In Kubernetes, there may be an additional overhead to create a Service object that publishes the ports outside the Kube cluster (see this example for more details).

If you run the Shiny app in a regular R process (not dockerized), do you get similar startup times?


#5

Hi @fmichielssen-
When using a local version of the app, it s opening up in in less than 2 sec.
We are indeed using kubernetes with shinyproxy so this could be the reason for the long startup indeed.

Thanks for your help, Dylan


#6

Hi @Dylan_Cissou,

While some overhead (pod creation, service creation) is to be expected, going from 2sec to 20sec seems a bit harsh. We will check here to see if optimizations can be made.


#7

Does one have access to USER or GROUP information in the template? This would be useful for a multi-app situation.

Thanks
Ralf


#8

Hi @rstub,

Yes, templates have full access to the Thymeleaf engine, which means they can use expressions like:

<div>
Logged user: <span sec:authentication="name"></span>
Roles: <span sec:authentication="principal.authorities"></span>
</div>