Closed cboettig closed 4 years ago
Don't know if it's a feature of if it just needs to be documented, but in order to let users have unrestricted access to the contents of the repository, including .git
, they must include a Dockerfile like this:
FROM w201rdada/portfolio:657d111
USER root
COPY . /home/rstudio/
RUN chown -R rstudio:rstudio * .*
USER ${NB_USER}
Where FROM
is my own extension of rocker/binder
. This is necessary because I assume the repo is cloned as root and not as rstudio, but perhaps that could be changed upstream to render this part unnecessary.
Giving users unrestricted access to the contents of the repo would seem to be the default desired behavior. Could this outcome be implemented in the base image?
I believe this is documented already: http://mybinder.readthedocs.io/en/latest/dockerfile.html#preparing-your-dockerfile
problem is that COPY
needs root. Generally it's good to avoid COPY
since it breaks docker caching anyway, you can always do a git clone
or wget
in a RUN command to get data from an S3 bucket or github etc
@cboettig @yuvipanda
We have a working Jupyterhub installation, and we were wondering if there is a way to use this docker image as a drop-in image for Jupyterhub and launch R studio directly? This example for Binder seems encouraging.
In other words, a user would login through Jupyterhub and the first page they see would be R studio web-IDE as opposed to choosing RStudio Session from the menu.
@syoh I think that should already work, provided you include the ?url=rstudio
as in https://github.com/rocker-org/binder#opening-rstudio-once-binder-launches ?
For JupyterHub, you should be able to set c.Spawner.default_url = "/rstudio"
to have users directly get into RStudio when they log in.
@yuvipanda Cool! We will try that
For JupyterHub, you should be able to set
c.Spawner.default_url = "/rstudio"
to have users directly get into RStudio when they log in.
@yuvipanda
Would this be the same jupyterhub on kubernetes? I'm having the same issue as @syoh. I'm also using the rocker/binder image.
Would this work in my config.yaml?
singleuser:
defaultUrl: "/rstudio"
image:
name: rocker/binder
tag: 3.5.1
This is the error that I receive:
2018-09-24 22:28:26+00:00 [Warning] Error: failed to start container "notebook": Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "exec: \"jupyterhub-singleuser\": executable file not found in $PATH"
@erniee I think the python package 'jupyterhub' needs to be installed in the image. I think rocker/binder doesn't have that?
@yuvipanda correct, that's not currently in the Dockerfile, maybe we should add that.
but I'm a bit lost here: what's the advantage of installing jupyterhub and adding a defaultUrl
parameter in a separate config
file to go directly to RStudio, vs just including the ?url=rstudio
to go directly to rstudio (which is working for me in the current image, at least with binderhub). Sorry, I'm probably not following something obvious here about the context
Thank you @cboettig @yuvipanda I may be using the wrong image but I wanted to setup z2jh to use an image that could automatically launch rstudio. I may be using the wrong image to do that with. With your help, I have this working but I do have a problem, saving files to the persistent storage is still an issue.
The home directory is set to /home/rstudio and persistent storage is mounted on /home/jovyan
Please let me know if there is a better image to use.
@erniee Maybe @yuvipanda is already aware of the details you refer to so I'm happy to defer to him, but it would help me to have a bit more understanding of what you are trying to do.
If you simply want to setup an RStudio server instance, and you want persistent data storage, the standard Rocker images work pretty well in this context. e.g. See the rocker docs for persistent storage: https://www.rocker-project.org/use/shared_volumes/. Sorry if I'm just missing the context of what you want to do, I'll defer to Yuvi on the jupterhub side.
@erniee and I figured out the issues and successfully created a rstudio image that can be launched directly. Thank you for your help @cboettig and @yuvipanda.
On a different topic, is there a way to make "Sign Out" button in Rstudio also sign the user out of Jupyterhub? This is a feature that would be useful (but may be difficult to implement) for using Rstudio within Jupyterhub. Right now, logging out of Rstudio gives an error: "Missing or incorrect token."
@yuvipanda Following up on your other question from #10 here.
Clearly this depends on what we mean by 'feature'.
On the port / networking side, it would be good to make sure that RStudio can open up other browser windows, e.g. when previewing an HTML document output by rmarkdown, or a website built by blogdown/bookdown, but I think that should work out of the box unless the proxy is doing something non-standard.
More complex are examples that require listening on an additional port: e.g. Doing the OAuth dance using the
httr
package, R listens for a callback on port 1410, see?httr::oauth_listener
for details. Usually this means just making sure that port is exposed.Most other features can "probably" be addressed by user installation, though this isn't always trivial; particularly when requiring certain sometimes non-obvious dependencies. The current Dockerfile builds on
tidyverse
, we have two more images in ther-ver
stack,verse
which primarily adds common R LaTeX libraries (in an approach that is at least a little more subtle than the 4GB worth oftexlive-full
) and ageospatial
stack which is particularly relevant on thedebian:jessie
based tags, since the relevant geospatial dependencies (GDAL, GEOS) need to be compiled from source with particular configuration to make sure sure you get a fully featured rather than minimal geospatial capability. (even ondebian:stretch
where sufficiently recent versions are available fromapt
these installations can be a stumbling point for users). TeX libraries and geospatial libraries are obviously just two common 'features' we see requested; clearly we could include these in a somewhat kitchen-sink binder just by bumping ourFROM
image torocker:geospatial
, but clearly other domain-specific configurations can create similar issues. Geospatial an TeX are pretty common dependencies in data-science stuff in general though; I don't know the python stack but I presume there's something on that side supporting bindings to the GDAL,GEOS, proj4, lwgeom libraries as well; so perhaps there's some synergy there. Anyway, lemme know what you think