So far I use a Dockerfile in my GitHub repo to define my Binder environment. I wonder if it would be better to build & publish (on Dockerhub) the corresponding image, so that Binder can pull it without having to build it?
1 Like
Noting that this issue was also raised in the binderhub repo:
opened 03:49PM - 14 May 21 UTC
enhancement
### Proposed change
In Pangeo, we use CI to build complex docker images wit… h our full stack in https://github.com/pangeo-data/pangeo-docker-images. These images are used directly in various Pangeo JupyterHubs.
We also want to use the same images in binder. We nearly always use use the [nbgitpuller trick](https://jupyterhub.github.io/nbgitpuller/link) to use separate repos for the binder env and contents. Currently this requires making a "passthrough" repo with a single-line Dockerfile pointing at the desired image on Dockerhub, e.g.: <https://github.com/pangeo-gallery/default-binder/blob/master/binder/Dockerfile>
Maintaining this "passthrough" repo is an extra step that leads to unnecessary complexity and also wastes binder resources rebuilding docker containers that are unchanged from the dockerhub version.
**I would love to have an option to launch a binder directly from a dockerhub (or other container registry) image, completely bypassing repo2docker.**
### Alternative options
Just keep doing what we are doing now, which works fine but requires additional complexity.
### Who would use this feature?
[Pangeo Gallery](http://gallery.pangeo.io/) and the entire Pangeo project would use this feature heavily. More generally, this feature would help bridge the gap between cloud-based JupyterHubs using pre-built docker images and Binders, improving interoperability between environments. _It would make it trivial to launch a binder with an identical environment to a cloud-based JupyterHub_, without requiring users to mess around with Dockerfiles.
### (Optional): Suggest a solution
I don't know enough about how binderhub works to propose an implementation.
I’m not sure it is fully solved by the repo2docker GitHub action. That solution still requires a “passthrough” one-liner binder Dockerfile (i.e. FROM myorg/myimage:latest). What @fortierq is asking for is the same thing I asked for in that issue: BinderHub directly launching a container from dockerhub, rather than its own private container inventory .
Also raised here:
opened 03:25PM - 25 Jun 20 UTC
In a recent conversation on gitter @betatim and I brainstormed some ideas about … how we could support "default environments" better. E.g., an environment that users don't have control over, but that they can use in combination with their files.
Here are a few steps that we could take - sharing them here in case others have thoughts/comments, and so we don't forget :-)
1. ~Create a repository that we think has an environment that covers 90% of "I just want it to work, and fast" use-cases~
- Decided this probably wasn't a good idea from a maintenance perspective, and we should probably instead use `docker-stacks` image, or something another org maintains like the kaggle image.
2. Document `nbgitpuller` functionality more cleanly, recommending that people use this repository as a default
3. Add a form to do this at the `nbgitpuller` docs (or the Binder docs?) semi-automatically and advertise it / document it (see https://github.com/jupyterhub/nbgitpuller/issues/125 for reference)
4. Wait and see how people use these steps, collect some data about it
5. Explore adding a "default environment" to BinderHub (or to mybinder.org), decide if it's a good idea
6. Explore adding a short-hand for the `nbgitpuller` pattern we documented in 2, decide if it's a good idea
In case it’s helpful, I was able to partially workaround the issue somewhat by using a GitHub Actions workflow to create a new commit on a special branch every time a new cached image is built (https://github.com/microsoft/Quantum/blob/8118f183e5ae7efed823c4ef20f747f7666ce69f/.github/workflows/prebuild-docker.yml ). It’s not quite directly launching from a given DockerHub image, but it at least allows for prebuilding from a GitHub Actions workflow.
1 Like