Deploying rocker/geospatial app to rocker/shiny?

[galenwilkerson]

Hi, I'm a bit new to docker, trying to understand the most elegant workflow, once I develop an app using rocker/geospatial, to deploy it inside a rocker/shiny container so it can be run on a server.

I needed rocker/geospatial because of the difficulties installing rgdal etc.

Thanks

[cboettig]

@galenwilkerson Thanks, this a common request; so far we haven't had a good way to do this (see #200). Composing containers is the usual 'docker way' but doesn't work well for shared libraries, so our advice has been to 'build your own' container starting on either the shiny or rstudio stack and then adding the other. Needless to say that's not particularly elegant...

So... I've just added a little add_shiny.sh script to the RStudio image to automate this a bit. With this, you can do something like

docker run -d -p 3838:3838 -p 8787:8787 -e ADD=shiny rocker/rstudio

with any of the rstudio-derived images (e.g. also rocker/geospatial, though sit tight because it will take a while for hub to finish these builds) and get shiny running on 3838 as usual.

Note that it will slow your container start-up since it runs the install then. To avoid this delay, just make a custom dockerfile building FROM, say, rocker/rstudio or rocker/geospatial and add the line:

RUN export ADD=shiny && bash /etc/cont-init.d/add

which will simply run the install script on build. Then you can run that container without the -e ADD nonsense and not have to wait for install.

The motivation for this somewhat convoluted apporach is that it still gives the user an opt-in ability to add shiny without baking shiny into every rstudio-derived container from the start. Feedback / critique welcome.

[galenwilkerson]

Carl, that is really really great. Thank you. I think you've made many people happy!

Perhaps useful for various people like you to take step back and think strategically how to make docker easier to use for common tasks, since it's such a useful tool.

very best

On Wed, May 3, 2017 at 11:11 PM, Carl Boettiger notifications@github.com wrote:

@galenwilkerson https://github.com/galenwilkerson Thanks, this a common request; so far we haven't had a good way to do this (see #200 https://github.com/rocker-org/rocker/issues/200). Composing containers is the usual 'docker way' but doesn't work well for shared libraries, so our advice has been to 'build your own' container starting on either the shiny or rstudio stack and then adding the other. Needless to say that's not particularly elegant...

So... I've just added a little add_shiny.sh script to the RStudio image to automate this a bit. With this, you can do something like

docker run -d -p 3838:3838 -p 8787:8787 -e ADD=shiny rocker/rstudio

with any of the rstudio-derived images (e.g. also rocker/geospatial, though sit tight because it will take a while for hub to finish these builds) and get shiny running on 3838 as usual.

Note that it will slow your container start-up since it runs the install then. To avoid this delay, just make a custom dockerfile building FROM, say, rocker/rstudio or rocker/geospatial and add the line:

RUN export ADD=shiny && bash /etc/cont-init.d/add

which will simply run the install script on build. Then you can run that container without the -e ADD nonsense and not have to wait for install.

The motivation for this somewhat convoluted apporach is that it still gives the user an opt-in ability to add shiny without baking shiny into every rstudio-derived container from the start. Feedback / critique welcome.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rocker-org/rocker/issues/235#issuecomment-299036810, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMumGhWEbNmSJDgfzLlZxZJ5K9449F2ks5r2O2WgaJpZM4NPYp4 .

[galenwilkerson]

As a caveat to users, as Carl has said, it takes quite some time (~5 min depending on connection) to run the first way (docker run ... -e ADD=shiny ... ) since docker is installing shiny server each time. If you expect the two servers to be up and running instantly, it will seem broken. (see docker logs )

Much better to make a very simple dockerfile to create a new image, as Carl mentions, including the command:

RUN export ADD=shiny && bash /etc/cont-init.d/add

Then starting up this new image as a container with mounted volumes etc. is relatively fast, and your final docker command will look like the one from rocker/rstudio:

docker run -d -p 3838:3838 -p 8787:8787 -v /srv/shinyapps/:/srv/shiny-server/ -v /srv/shinylog/:/var/log/shiny-server/

Galen

On Wed, May 3, 2017 at 11:30 PM, Galen gjwilkerson@gmail.com wrote:

Carl, that is really really great. Thank you. I think you've made many people happy!

Perhaps useful for various people like you to take step back and think strategically how to make docker easier to use for common tasks, since it's such a useful tool.

very best

On Wed, May 3, 2017 at 11:11 PM, Carl Boettiger notifications@github.com wrote:

@galenwilkerson https://github.com/galenwilkerson Thanks, this a common request; so far we haven't had a good way to do this (see #200 https://github.com/rocker-org/rocker/issues/200). Composing containers is the usual 'docker way' but doesn't work well for shared libraries, so our advice has been to 'build your own' container starting on either the shiny or rstudio stack and then adding the other. Needless to say that's not particularly elegant...

So... I've just added a little add_shiny.sh script to the RStudio image to automate this a bit. With this, you can do something like

docker run -d -p 3838:3838 -p 8787:8787 -e ADD=shiny rocker/rstudio

with any of the rstudio-derived images (e.g. also rocker/geospatial, though sit tight because it will take a while for hub to finish these builds) and get shiny running on 3838 as usual.

Note that it will slow your container start-up since it runs the install then. To avoid this delay, just make a custom dockerfile building FROM, say, rocker/rstudio or rocker/geospatial and add the line:

RUN export ADD=shiny && bash /etc/cont-init.d/add

which will simply run the install script on build. Then you can run that container without the -e ADD nonsense and not have to wait for install.

The motivation for this somewhat convoluted apporach is that it still gives the user an opt-in ability to add shiny without baking shiny into every rstudio-derived container from the start. Feedback / critique welcome.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rocker-org/rocker/issues/235#issuecomment-299036810, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMumGhWEbNmSJDgfzLlZxZJ5K9449F2ks5r2O2WgaJpZM4NPYp4 .

[cboettig]

Looks like this is resolved, so closing.