hnskde/shinyproxy repository overview

⁠Proxy our shiny apps

⁠Introduction

Re-using the name of the underlying Spring boot web application⁠ shinyproxy is the deployer of shiny web applications developed and mentained by SKDE. Both shinyserver and the web applications it it a proxy for are deployed as docker containers⁠ and replicated at a given number of nodes to reduce potential downtime.

shinyproxy is part of the infrastructure at mongr.no⁠ and serves shiny applications such as qmongr⁠.

⁠Config

Configuration of shinyproxy is defined in the application.yml-file. Re-configuration will in most likely occur as a result of new shiny application being added (or old ones removed). For details please see the ShinyProxy docs⁠

⁠Install

All steps are performed from the command line at each server instance (node) that will be running shinyproxy.

⁠First time

Make sure that the current content of this repo is available by using git:

git clone https://github.com/SKDE-Felles/shinyproxy.git

If the server to be hosting shinyproxy is just created (vanilla state) make sure docker-ce and docker-compose are installed along with other relevant settings. Move into the newly created _shinyproxy_directory and run the following script:

sudo ./install.sh

If AWS LogWatch will be used credetials need to be defined and available to docker. Add the following to /etc/systemd/system/docker.service.d/override.conf:

Environment="AWS_ACCESS_KEY_ID=[some_key_id]" "AWS_SECRET_ACCESS_KEY=[some_seecret_access_key]"

Corresponding values are found using the AWS Identity and Access Management (IAM) service. Save the file and reload the daemon

sudo systemctl daemon-reload

and restart the docker service

sudo systemctl restart docker

Repeat the above instructions at all nodes.

⁠Update

Please note that an update of the shinyproxy will render all shiny applications behind it inaccessible. Therefore, make sure to perform all the following steps one node at a time. This will make sure that while one node is down for an update the other nodes will still serve users of the shiny applications.

First, make sure to download the latest updates from this repository. Move into the shinyproxy directory and run

git pull origin master

In fact, this step is only needed upon changes in the docker-compose.yml-file.

Then, take down shinyproxy docker container:

docker-compose down

and download the updated shinyproxy image:

docker pull hnskde/shinyproxy

Clean up old images and containers:

docker system prune

and bring up the updated shinyproxy container:

docker-compose up -d

Repeat the above steps on all nodes.

⁠Start and stop service

To enable shinyproxy use docker-compose to start the relevant services in detached mode. Move into the shinyproxy directory and run:

docker-compose up -d

To stop it do:

docker-compose down

To bring the services down an up again in one go do:

docker-compose restart

For other options please consult the docker compose docs⁠.

⁠Note on shiny applications

⁠Install

shinyproxy do not pull images from remote regisries. To make images available locally at each node these have to be pulled the first time they are used, e.g.

docker pull hnskde/qmongr

⁠Update

Updating the shiny applications is a somewhat different process and part of a continuous integration and delivery (ci/cd) scheme. At each node running shinyproxy a cron job is defined to trigger update routine every 5 minutes on weekdays:

*/5 * * * 1-5 $HOME/shinyproxy/update_images.sh >/dev/null 2>&1

If updates are found the corresponding images are downloaded. A new version of a shiny application will be available once shinyproxy restarts the corresonding container from the updated image.