repo2docker icon indicating copy to clipboard operation
repo2docker copied to clipboard

How to replicate start file that accesses host environment variabels using ENTRYPOINT

Open d-diaz opened this issue 6 years ago • 3 comments

I am trying to get a Dockerfile-based build working through pangeo's binder (original issue posted here), but am running into difficulty replicating the functionality of the start script they have in their cookie cutter recipe.

In a nutshell, that start script replaces some fields in a jupyterlab-workspace.json file by accessing the ${JUPYTERHUB_USER} environment variable on the host machine. However, when I set this start script up as an ENTRYPOINT at the end of my Dockerfile, when the docker image is built and run using pangeo's binder link, it is not accessing this environment variable, and the server is failing to launch because jupyter lab doesn't generate an appropriate workspace in the ENTRYPOINT script. I suspect this is because the pangeo binderhub setup doesn't specify an argument like -e JUPYTERHUB_USER when it calls docker run. Any idea how I can pull host environment variables into my ENTRYPOINT script if the host machine doesn't use this -e flag? It seems like this variable is picked up when the using the start file in the conda buildpack approach, just not when I'm trying to replicate it in a Dockerfile.

d-diaz avatar Feb 11 '19 17:02 d-diaz

I think the underlying issue is https://github.com/jupyterlab/jupyterlab/issues/5977 - workspaces shouldn't rely on JUPYTERHUB_USER. JUPYTERHUB_USER is only set when running under a JupyterHub - so it's set on mybinder.org but not on repo2docker itself.

yuvipanda avatar Feb 11 '19 20:02 yuvipanda

Seems like a good lead, but would that explain why this fails using a Docker build but but not with the conda buildpack that included a start file? If you follow the pangeo-binder link from this repo, it gets running fine. This is using a binder folder with files that trigger the conda build pack. The start file handles the JUPYTERHUB_USER substitution for workspace and in call to jupyter lab, and seems to work fine. I had expected that using ENTRYPOINT as a substitute for the start file would replicate the functionality of the start file under other buildpacks. I had assumed that the ENTRYPOINT script would have access to the host's environment variables, but that is apparently not the case (unless they're explicity provided with docker run -e ...).

d-diaz avatar Feb 11 '19 23:02 d-diaz

@yuvipanda You've added the documentation label. Have you since figured out what the expected behaviour is, or where to find it?

manics avatar May 17 '21 20:05 manics