The documentation for Jupyter, Z2JH, and Docker Stacks generally seems to assume or recommend that custom Docker images be based directly on an existing Docker Stacks image.
I have spent considerable time debugging incompatibilities in my custom images, and this process is made harder by their stacked design. I base my images on scipy-notebook, which means that minimal-notebook, base-notebook, docker-stacks-foundation, and ubuntu are also pulled in. And because the docker-stacks Dockerfiles don’t explicitly peg the versions of their base images, the exact contents are also affected by the time at which these images were built and pushed.
I am now considering writing a Dockerfile for an ‘all-in-one’ build based directly on an Ubuntu image. I would start by essentially concatenating the content of the relevant Docker Stacks Dockerfiles and adding my own custom steps at the end. I already did a quick test along these lines and produced a usable image, though I didn’t test it very thoroughly.
However, before going further down this path, I’d like to check that I’m not overlooking any potential problems. There might be good reasons why the documentation only mentions building on top of Docker Stacks and doesn’t discuss using a plain Ubuntu image as the base. Is there anything I should be aware of?
Z2JH contains a minimal singleuser example that’s not based on docker-stacks
The main benefit of using docker-stacks is it contains a lot of pre-installed libraries, it’s well tested, and will “just work” for a lot of users including those with limited experience of installing Jupyter components.
As long as you understand how to install and configure all the Jupyter components and dependencies, and dealing with interacting component versions, it’s fine to build you own container from scratch.
Thanks for the reassurance, and for the link to the minimal Dockerfile! When I first started using Jupyter, singleuser-sample was based on a Docker Stacks image, but I see now that that changed a few months ago.