RStudio and Shiny in one dockerfile

I am looking into docker to distribute a shiny application that also requires RStudio. The primary goal is easy installation at hospitals under Windows. Everything that requires character input into black boxes will certainly fail during installation by non-IT people.

My previous attempts used vagrant, but installing vagrant alone proved to be a hurdle.

  • How to start docker container as server
  • SSH to docker bridged instance
  • Vagrant box and Docker provider: Titan and Kafka
  • docker build inside official jenkins container
  • Chronos framework connect and disconnect from Mesos
  • Base image for java
  • The rocker repository, has an RStudio and a Shiny , and for my own installation both work together. However, I would like to create a combined application for easier installation.

    What is the recommended workflow? Start with RStudio, and manually add Shiny?
    Or merge the dockerfiles code from both Rockers, starting with r-base? Or use compose tool?

  • Setting the Docker's container environnement (Env) via the docker remote api
  • Symlink to volume in Docker container
  • eclipse che snapshot does not work
  • GCR Builds fail
  • Unable to install features in servicemix docker image: ERROR
  • Bundling from Github in a Dockerfile
  • 4 Solutions collect form web for “RStudio and Shiny in one dockerfile”

    Interesting question, but I’m not sure I understand the advantage of having the shiny-server and the rstudio-server instances served from the same container.

    Is the purpose so that the two containers share the same R libraries (e.g. so a package doesn’t need to be installed separately on each) or merely to have one docker container instead of two? Just having to run two docker commands instead of one doesn’t seem that onerous, but maybe I’m underestimating.

    Sharing the underlying libraries seems like a valid objective though, and I don’t think there’s an ideal solution available yet.

    I feel the most docker-esque solution would be to do this via container orchestration/compose tool as you mention. This is the usual way to combine separate services (e.g. web server and database) without building one on top of the other.

    Unfortunately, the tooling for orchestration based on mapping volumes is not nearly as well developed as it is for mapping ports.

    Imagine running the rstudio as a volume container:

    docker run --name rstudio -v /usr/local/lib/R/site.library rocker/rstudio true

    (If you wanted RStudio access at the same time, one could instead run this as:)

    docker run --name rstudio -dP -v /usr/local/lib/R/site.library rocker/rstudio

    You can then use the the site.library from the rstudio container in place of that on the shiny container with a command like:

    docker run --volumes-from rstudio -dP rocker/shiny

    Unfortunately, this clobbers the site.library of the shiny container. To work around this, you’d want to mount the library of the rstudio container in a different place, but there’s no easy syntax for this like we already have with port links. It can be done though, see:

    How to map volume paths using Docker's –volumes-from?

    There’s an open thread on this issue in the rocker repo too.

    The point of Docker, in general, is isolation of services so that they can be updated/changed without effecting others. My recommendation would be to use docker-compose, instead. Below is an example docker-compose yaml file that serves both rstudio and shiny on the same server at different subdomains using the incredibly useful docker-gen by Jason Wilder. All R docker images used below are courtesy of Rocker or more directly Rocker Docker Hub. These are very very reliable because, well, Dirk Eddelbeutel and Carl Boettiger made them. In this example I’ve also included some options for RStudio such as setting a user/pass and whether or not the user has root access. There are more instructions on using the Rocker RStudio image available on this wiki page:

    Change the following:

    • your_user to your username on the server
    • SOME_USER to your desired RStudio username
    • SOME_PASS to your desired Rstudio password
    • *.DOMAIN.tld to your domain, don’t forget to add A records for your subdomains.

      image: nginx
      container_name: nginx
      - "80:80"
      - "443:443"
        - /etc/nginx/conf.d
        - /etc/nginx/vhost.d
        - /usr/share/nginx/html
        - /home/your_user/services/volumes/proxy/certs:/etc/nginx/certs:ro
        - "nginx1"
      image: jwilder/docker-gen
      container_name: nginx-gen
        - /var/run/docker.sock:/tmp/docker.sock:ro
        - /home/your_user/services/volumes/proxy/templates/nginx.tmpl:/etc/docker-gen/templates/nginx.tmpl:ro
        - nginx1
      entrypoint: /usr/local/bin/docker-gen -notify-sighup nginx -watch -only-exposed -wait 5s:30s /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf
        - "nginx1"
      image: rocker/hadleyverse
      container_name: rstudio
        - "8787:8787"
        - VIRTUAL_PORT=8787
        - ROOT=TRUE
        - VIRTUAL_HOST=rstudio.DOMAIN.tld
        - USER=SOME_USER
        - "nginx1"
      image: rocker/shiny
      container_name: shiny
        - VIRTUAL_HOST=shiny.DOMAIN.tld
        - /home/your_user/services/volumes/shiny/apps:/srv/shiny-server/
        - /home/your_user/services/volumes/shiny/logs:/var/log/
        - /home/your_user/services/volumes/shiny/packages:/home/shiny/

    It’s trivial to add more services like a blog, for example, just follow the pattern or search the internet for a docker-compose version of your service and add it.

    I have developed a working single docker for

    • R
    • RStudio (server)
    • Shiny Server (free edition)

    I built it exactly for the same reasons mentioned by @Dieter Menne. It may be not ideal for ops, but it great for dev (especially if the team members all use different envs. like mac, windows etc.).

    It is on Centos 6 as this is the env. I use at work.

    This is the dockerfile:

    FROM centos:centos6.7
    MAINTAINER enzo smartinsightsfromdata 
    RUN yum -y install epel-release
    RUN yum update -y && yum clean all
    # RUN yum reinstall -y glibc-common
    RUN yum install -y locales java-1.7.0-openjdk-devel tar
    # Misc packages
    RUN yum groupinstall -y "Development Tools" 
    # R devtools pre-requisites:
    RUN yum install -y wget git xml2 libxml2-devel curl curl-devel openssl-devel
    WORKDIR /home/root
    RUN yum install -y R
    RUN wget
    RUN R CMD INSTALL rJava_0.9-7.tar.gz
    RUN R CMD javareconf \
        && rm -rf rJava_0.9-7.tar.gz
    # Add RStudio binaries to PATH
    # export PATH="/usr/lib/rstudio-server/bin/:$PATH"
    ENV PATH /usr/lib/rstudio-server/bin/:$PATH 
    ENV LANG en_US.UTF-8
    RUN yum install -y openssl098e supervisor passwd pandoc
    # RUN wget
    # Go for the bleading edge:
    RUN wget
    RUN yum -y install --nogpgcheck rstudio-server-rhel-0.99.697-x86_64.rpm \
        && rm -rf rstudio-server-rhel-0.99.484-x86_64.rpm
    RUN groupadd rstudio \
        && useradd -g rstudio rstudio \
        && echo rstudio | passwd rstudio --stdin 
    RUN R -e "install.packages(c('shiny', 'rmarkdown'), repos='', INSTALL_opts='--no-html')"
    RUN wget
    RUN yum -y install --nogpgcheck shiny-server- \
        && rm -rf shiny-server-
    RUN mkdir -p /var/log/shiny-server \
        && chown shiny:shiny /var/log/shiny-server \
        && chown shiny:shiny -R /srv/shiny-server \
        && chmod 777 -R /srv/shiny-server \
        && chown shiny:shiny -R /opt/shiny-server/samples/sample-apps \
        && chmod 777 -R /opt/shiny-server/samples/sample-apps 
    COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf
    RUN mkdir -p /var/log/supervisor \
        && chmod 777 -R /var/log/supervisor
    EXPOSE 8787 3838
    CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"] 

    This is how the supervisord.conf file looks like:

    pidfile = /tmp/

    It is available at my github page: smartinsightsfromdata

    I have also developed a working docker for shiny server pro on centos (using shiny server pro temporary edition, valid 45 days only).

    Somewhat unfortunately, there is no definite answer, it all depends on how much reusability you would be looking for and whether an upstream base image is well maintained. The is also images size tradeoff, more layers there are, bigger the resulting image gets.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.