[This article was first published on Open Analytics, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.ShinyProxy 3.1.0Last year we released a major update of ShinyProxy, bringing High Availability,Scaling, App parameters, improved integration with Kubernetes and much more.Today’s release goes even further, brining Pre-Initialization, Container sharingand even a new container backend. Along with these major features, the releaseis packed with numerous small improvements. ShinyProxy is a novel, open sourceplatform to deploy Shiny apps for the enterprise or larger organizations.Nevertheless, ShinyProxy is also an excellent choice for deploying a handful ofapps in smaller organizations. While ShinyProxy is generally used to host Shinyapplications, it has always been designed with the idea to host any applicationthat can be packaged into a Docker container. For example, ShinyProxy is usedmore and more to host complete development environments. This blog post coverssome major improvements of this release. All changes in this version can befound in the release notes.
Pre-initialization and Container SharingFor as long as ShinyProxy exists, ShinyProxy starts a new container every time auser starts an application. This container is dedicated to this user and isnever used by other users. This has worked great for many years and gives thepossibility of using ShinyProxy for hosting IDE’s and development tools, sinceeach container can be customized for this specific user and session.Furthermore, as every container is started on-demand, it allows to host a bigset of applications, without the need for all these applications to run all thetime. While this approach has many advantages, it also has the consequence thata user has to wait for both the container and application to start up and thatit requires more (CPU and memory) resources when more users are usingShinyProxy. ShinyProxy 3.1.0 introduces the concept of containerpre-initialization and container sharing. For every app, you can specify anumber of seats ShinyProxy has to pre-initialize (e.g. X seats). WhenShinyProxy starts up, it will start X containers. As soon as a user wants touse an application, ShinyProxy assigns a container (seat) to the user.Therefore, the user has almost no waiting time for the container to start up. Assoon as a seat gets claimed, ShinyProxy will scale up the number ofcontainers, such that there are again X seats ready to be used by new users.Similarly, when a user stops using an app, the seat is released and ShinyProxywill scale-down the pool of available seats (and thus the number of containers).In addition, you can specify how many seats can be run on a single container,therefore allowing to share a single container among multiple users.
Enabling pre-initialization for an app is very easy, just add theproperty minimum-seats-available: X to your app specification. With thisoption, ShinyProxy will ensure there are always X pre-initialized containers.New users will be immediately assigned to a pre-initialized container. Addingthe property seats-per-container: Y, allows a single container to be usedby Y people at the same time. ShinyProxy takes both numbers into account, inorder to determine the number of underlying containers. It is possible to usethese new features with every container backend.
In many cases, an app hosted on ShinyProxy needs to know the username (andgroups) of the current user. Therefore, ShinyProxy adds the username (andgroups) as environment variables to the container. However, this would not workwhen the container is created up-front or used by multiple users (environmentvariables cannot be updated after the container has started). Instead,ShinyProxy can now send the username and groupsas HTTP headersto the app. It is even possible tosend custom headers!
The monitoring stackcontains a new set of dashboards, providing the same level of monitoring forpre-initialized and shared containers as for regular apps.
We believe this feature is a big improvement for ShinyProxy. Together with thevarious performance improvements made in this release, this makes it easier touse ShinyProxy for public apps, which are used by a large amount of users. Checkoutthe full documentationto start using it.
AWS ECS BackendUp to now ShinyProxy supported three container backends: Docker, Docker Swarmand Kubernetes. The Docker backend is very easy to set up, but does not providethe same scalability and flexibility as the Kubernetes backend. ShinyProxy 3.1.0now supports AWS ECS as a new backend, allowing to deploy ShinyProxy withoutmanaging servers or complex setups, but with greater scalability. The backenduses AWS Fargate and supports most of the ECS features: integration withCloudWatch, Task role support (e.g. to access S3) and EFS volumes. We provide aready to use and fullydocumented Terraform deployment example.A downside of AWS ECS is that in most cases it takes more time to start thecontainer compared to the other backends. But of course it can be used togetherwith the pre-initialized container feature, reducing the startup time to lessthan a second. The architecture of ShinyProxy, allows to easily add newcontainer backends.
Custom container namesThis release streamlines the names of the containers created by ShinyProxy.Every backend now uses the id of the app as part of the name, making it easierto find which container corresponds to which app. For example, when usingDocker, the name of the container is sp-container-#{proxy.id}-0,where #{proxy.id} is replaced by the id of the app. It’s even possible tochangethe name by providing a SpEL expression.
Up to date Docker libraryAs with every release, all dependencies (including Spring Boot) have beenupdated. Furthermore, ShinyProxy now uses a better maintained Docker clientlibrary. This new library no longer relies on old dependencies and fixes thecompatibility of ShinyProxy with recent Docker releases.
Limitation on the number of usersWhen making applications available to a broad audience, you sometimes want tolimit the total number of apps running on your server or cloud infrastructure.It’s now possible to specify such a limit, both on a global and per-app level.The container sharing feature is aware of this limit and uses it to determinethe maximum number of containers it can create.
Documentation and DemosIn addition to all the improvements to the ShinyProxy code, a lot of time wasinvested to improve the ShinyProxy documentation. First of all, we now have anoverview of how to write ShinyProxy configuration (e.g. how touse listsor environment variablesin the config). The configuration of apps has been divided into smallersections, making it more clear which properties belong together. All sections inthe documentation are now numbered, and together with improvements to the ToC, thismakes it easier to browse through the always growing number of configurationproperties. The OpenID documentation has been rewritten, to better explain theprocess of configuring it, while we also extendedthe provider specific examples.Finally, we regularly addnew demos, showinghow to deploy many kinds of apps in ShinyProxy.
Full release notes can be found on the downloads page and updated documentationcan be found on https://shinyproxy.io. As always community support on this newrelease is available at
https://support.openanalytics.eu
Don’t hesitate to send in questions or suggestions and have fun with ShinyProxy!
To leave a comment for the author, please follow the link and comment on their blog: Open Analytics.
R-bloggers.com offers daily e-mail updates about R news and tutorials about learning R and many other topics. Click here if you're looking to post or find an R/data-science job.
Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.Continue reading: ShinyProxy 3.1.0