By: Peter Solymos
Lots of resources describe how you can host Shiny apps with Docker, Shiny Server, or via other means. But we also know Shiny apps can be launched locally. What makes your local setup different from these other options is that your local machine does not usually have a static internet protocol (IPv4) address. Without a static IPv4, it is really hard to share the app with other people because the address keeps changing unpredictably, and you might sometimes power off your machine.
Shiny uses the httpuv R package under the hood which is an HTTP and websocket server library. Could you just run Shiny directly on a remote server? This post explores this topic using systemd the system and service manager for most modern Linux distributions. All I am trying to do in this post is to make a point that the shiny R package is really self-sufficient and in the simplest case, it does not need any other layer for sharing an app.
Server setup
Spin up a virtual machine on the cloud provider of your choice. I use Ubuntu Linux 20.04 here if you are following along, your root user name might also be different (root
on DigitalOcean, ubuntu
on AWS, etc.). I also assume you have your ssh
keypair configured for passwordless login.
Create a file called setup.sh
in your current work directory on the local machine you are working on and copy-paste this into the file:
#!/bin/bash
# add CRAN to apt sources
apt-key adv --keyserver keyserver.ubuntu.com \
--recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9
printf '\ndeb https://cloud.r-project.org/bin/linux/ubuntu focal-cran40/\n' \
| tee -a /etc/apt/sources.list
add-apt-repository -y ppa:c2d4u.team/c2d4u4.0+
# install system requirements & R
export DEBIAN_FRONTEND=noninteractive
apt-get -y update
apt-get -y upgrade
apt-get -yq install \
software-properties-common \
libopenblas-dev \
libsodium-dev \
r-base \
r-base-dev \
r-cran-shiny \
r-cran-rmarkdown \
r-cran-plotly \
r-cran-ggplot2 \
r-cran-jsonlite \
r-cran-forecast
Once you know the IPv4 address, store it in the HOST
environment variable and run the setup script via ssh
:
export HOST="165.227.39.92"
ssh root@$HOST "bash -s" < setup.sh
After the installation, you should have R installed with some Shiny-related and commonly used packages ready to be used. Now log in with ssh root@$HOST
to continue.
Add an application
You will create a shiny
user group and a shiny
user that will own the home directory /home/shiny
. This is where you will use git
to pull the COVID-19 app that was introduced in this post:
# add group
addgroup --system shiny
# add new user and create home dir
adduser --system --ingroup shiny shiny
# change dir
cd /home/shiny
# change user to shiny
sudo -u shiny -s
# pull COVID app
git clone https://github.com/analythium/covidapp-shiny.git
You can now launch the app to listen on port 80 (standard HTTP port) as:
R -e "shiny::runApp('/home/shiny/covidapp-shiny/02-shiny-app/app', port = 80, host = '0.0.0.0')"
And immediately see an error: createTcpServer: permission denied
. The error message is telling you that the shiny
user won't be able to use low port numbers like 80 because ports below 1024 are privileged and only root
can open listening sockets on them. One option you have is to run the Shiny app on port 3838:
R -e "shiny::runApp('/home/shiny/covidapp-shiny/02-shiny-app/app', port = 3838, host = '0.0.0.0')"
This command now works fine and is able to execute the expression with runApp()
on port 3838 and host address 0.0.0.0
that is a meta-address referring to all IPv4 addresses on the local machine (somewhat different from the loopback address 127.0.0.1
which is the localhost).
Visit http://$HOST:3838
in your browser. You should see the COVID-19 app. But the R process is now running in the foreground. Ctr+C to quit, this kills the process and makes the app grey out in the browser. Can you run the process in the background?
Run Shiny in the background
The nohup
command is used to launch long-running scripts in the background, its name stands for "no hang up". nohup
makes the command following it to ignore the hang-up (HUP) signal so it can run after the current terminal is closed.
The general usage is nohup command > out.log 2>&1 &
. This will run the command in the background, redirect standard output and standard error into the log file (the 2>&1
part). nohup
does not send the program to the background, it is done by the &
which allows the user to continue using the current shell. Here is the full command to run the Shiny app:
nohup R -e "shiny::runApp('/home/shiny/covidapp-shiny/02-shiny-app/app', port = 3838, host = '0.0.0.0')" > /home/shiny/covidapp.log 2>&1 &
After running this command, you get back the prompt and a printout of the process identifier (PID). Use kill $PID
or kill -9 $PID
if you need to force kill. The following command finds the R process and kills it: kill $(ps aux | grep '[R] -e' | awk '{print $2}')
(this SO post explains how it is working).
Visit http://$HOST:3838
in your browser: the sight should be the familiar Shiny app. Open up the /home/shiny/covidapp.log
file to see the logs.
You might stop here, but the process can exit due to an error, or not restart after a reboot. The solution: systemd. exit
the current shell for the shiny
user and return to the root
shell (the prompt will change from $
to #
).
Configure and start a service
Create the shinyapp.service
file in the /etc/systemd/system
folder, shinyapp
is the name of the service after the file name:
touch /etc/systemd/system/shinyapp.service
Add this as content:
[Unit]
Description=COVID-19 Shiny App
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
User=shiny
ExecStart=R -e "shiny::runApp('/home/shiny/covidapp-shiny/02-shiny-app/app', port = 3838, host = '0.0.0.0')"
[Install]
WantedBy=multi-user.target
What do we have here? The After
directive means that the service must be started after the network is ready, Restart
instructs the service to always restart on exit irrespective of exit status, ExecStart
contains the command to run, User
is the owner of the app. See this post for an explanation of the other directives.
Reload the systemctl
daemon to update with your changes using systemctl daemon-reload
. Enable (to restart after reboot) then start the service:
systemctl enable shinyapp
systemctl start shinyapp
Visit the http://$HOST:3838
address to see the app running. Check the status with systemctl status shinyapp
to see something like this:
systemctl status shinyapp
● shinyapp.service - COVID-19 Shiny App
Loaded: loaded (/etc/systemd/system/shinyapp.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-06-02 06:09:13 UTC; 17s ago
Main PID: 710 (R)
Tasks: 2 (limit: 2344)
Memory: 167.1M
CGroup: /system.slice/shinyapp.service
└─710 /usr/lib/R/bin/exec/R -e shiny::runApp('/root/covidapp-shiny/02-shiny-app/app',~+~port~+~=~+~80,~+~>
Jun 02 06:09:22 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: method from
Jun 02 06:09:22 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: as.zoo.data.frame zoo
Jun 02 06:09:24 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: Attaching package: ‘plotly’
Jun 02 06:09:24 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: The following object is masked from ‘package:ggplot2’:
Jun 02 06:09:24 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: last_plot
Jun 02 06:09:24 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: The following object is masked from ‘package:stats’:
Jun 02 06:09:24 ubuntu-s-1vcpu-2gb-intel-tor1-01 nohup[710]: filter
Use systemctl restart shinyapp
to restart the service after you make changes to the Shiny app and pull a new version via git
. Because the service is enabled, it will restart after rebooting the server.
One last thing that you can do is to redirect port 80 to 3838 using iptables
:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3838
Now visit http://$HOST
to see the Shiny app. Disabling port 3838 can be done with the uncomplicated firewall (ufw
) tool. Don't forget to destroy your server if you don't need it any more.
Summary
The setup presented here is generally applicable to all kinds of web services. You can add multiple apps by creating multiple services for them. Managing R package versions is possible by adding multiple users and install R packages into their user libraries, just like you would do with Shiny Server. Serving systemd based apps on URL paths requires a reverse proxy like Nginx or Caddy, similarly to how we proxied ports using Docker.
The approach I presented here leaves a lot more to be desired. I am not suggesting this is a super useful setup. But I believe that it demonstrates the power of the standard Linux toolbox and that Shiny is a fully capable web server on its own and can directly be deployed and served to users.
Top comments (0)