sharing libraries via orchestration

[cboettig]

@wch @eddelbuettel Thought you both would have a better idea on how to do this than I do.

Winston: quick background: wondering how a user can best mix & match containers without having to stack one on top of the other by writing a new Dockerfile with FROM. For example, imagine wanting to access R libraries installed on rocker/hadleyverse from the rocker/shiny container.

I just took a quick look at what it would take to do the orchestration approach suggested earlier (e.g. linking containers together). This is kinda a task for --volumes-from, e.g. if we do:

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

docker run --volumes-from hadleyverse -ti rocker/shiny R

we can now load R libraries that are installed on the rocker/hadleyverse container from inside the shiny container, e.g. library("plyr")

However, this only works when there are no external lib dependencies for the package, since the only volume we have grabbed from hadleyverse is the site.library (also, this clobbers the existing /usr/local/lib/R/site.library, not obvious how to avoid that). For instance, library(XML) will fail because the shared XML.so lib cannot find libxml2 on the shiny container.

Is there any good way around this? e.g. a way to install standalone binaries instead of shared binaries such that the containers are more suitable for linking up in this way?

Thanks for your thoughts

[eddelbuettel]

that seems ... hard

[wch]

Here's a sketch of one possible approach. I have no idea whether this is feasible at all.

Call the container you're running is the main container, and the one you're mounting volumes form the aux container.

• In the main container, add a directory (like /volume), where the aux container's root directory will be mounted.
• For system libraries, add an entry to LD_LIBRARY_PATH to point to /volume/usr/lib.
• For R libraries, add an entry to R_LIBS or R_LIBS_SITE (or whatever it's supposed to be) that points to /volume/some/path.

If the volume isn't mounted on the host container, I think these extra paths will just be ignored.

It would also be nice if it were possible to have a stable, unchanging Docker image with TeX on it, and access it this way. But on the other hand, this sort of feels like we're rebuilding a regular stateful Linux distribution with Docker containers...

Edit: Mounting the aux container's root dir probably isn't a good idea. It would be better to mount the specific directories needed.

[cboettig]

@wch Thanks for the suggestion; mounting each of the specific directories as needed and setting the paths with the appropriate environmental variables makes sense; I'll give that a go.

Yup, I've used this strategy for tex before: http://www.carlboettiger.info/2014/11/05/notes.html In this case it is easy because the install of texlive from source in leodido/texlive means there's no need to also link shared libraries. (Sometimes it's handy to have the all of texlive-full available, though for regular use I still think it makes sense to have some basic tex support on the rocker container; at least as long a LaTeX remains so integrated into R). Note that it takes a long time to launch a container with a shared volume as large as texlive-full.

Re: reinventing the wheel. Yeah, I wonder about that too. Though I suppose the norms are still evolving somewhat for this more abstracted context.

[cboettig]

@wch hmm, I must be missing something but I'm not seeing a way in which I can change where the volume is mounted on the main (e.g. shiny in this case) container. In the example I give above, the path is the same on the main and aux containers (e.g. /usr/local/lib/R/site.library on both)

docker run --name hadleyverse -v /usr/local/lib/R/site.library rocker/hadleyverse true
docker run --volumes-from hadleyverse -ti rocker/shiny R

It's not obvious to me how I would modify this call such that the /usr/local/lib/R/site.library volume from hadleyverse would be mounted somewhere else on shiny. Clearly this would be a problem with the shared libs, since I don't want to clobber the entire shared libs directory of the main container.

[cboettig]

Ah-ha! It looks like one can work around this, it just requires a bit more manual approach than the the convenience of --volumes-from http://stackoverflow.com/questions/23137544/how-to-map-volume-paths-using-dockers-volumes-from

[wch]

Oh, interesting, that is more complicated than I expected. I had sort of assumed that it would be as simple as mapping directories from the host (like -v /hostpath:/containerpath), but I guess I was wrong.

I also just learned about the :ro flag that lets you mount volumes read-only. That would be useful here.

[dmenne]

Winston wrote:

But on the other hand, this sort of feels like we're rebuilding a regular stateful Linux distribution with Docker containers...>>

I understand what you mean, but this is seen from a programmer's perspective with a Unix background. My medical colleagues are locked in a corporate (=hospital) Windows installation. To create a custom report with a Shiny interface and pdf output, they have to ask their IT to install R, R-packages, Latex, and possibly RStudio. No chance that anything will be done, because the IT fears supporting this (mess). If you can supply everything in a container, it may work out; I am not sure, though, currently flying a kit.

[schugh-gopivotal]

@cboettig so did you get it to work? Can you post the final solution based on the stackoverflow thread as applicable to shiny and rstudio containers?

[dmenne]

No, not yet. I tried to get Compose to work on Boot2Docker/Windows, but it ended up in a big struggle against Pythonic creatures - see stackoverflow for some "not so working and maybe working" solution. Have given up and went back to https://bitbucket.org/dmenne/rstudio-shiny-server-on-ubuntu.

[cboettig]

@schugh-gopivotal The approach from that stackoverflow post works for most packages, but it can be messy in general if you have packages that depend on shared libraries. For instance, you can map each of the directories in .libPaths() on the shiny container to different directories (e.g. a subdirectory, like /usr/local/lib/R/site-library/shiny) in the rstudio container and then you'll have access to those packages installed on the shiny directory, but this won't work if those packages that are using shared system libraries (e.g. in /usr/lib or /usr/local/lib). Mapping those as well and then reconfiguring the packages to know where to find them is going to be a nightmare.

In general, I think the the best solution is to install the necessary libraries within each container. Composing containers and using docker-compose works wonderfully for any application that exposes an API to interact with (e.g. database services like redis or mysql). But the dependencies for each service should be self-contained (e.g. both rstudio container and shiny container should have all the packages you need in each). This is a bit easier to do when your images have a modular install script rather than an explicit list of packages in the Dockerfile, but the cost is that Dockerfiles loading external scripts cannot cache builds effectively.

[eddelbuettel]

Close for inactivity?

[cboettig]

Yup thanks