Skip to content

Images

This table lists the default list of images that are available as part of the platform.

Image Name Description
kubeflownotebookswg/jupyter-scipy JupyterLab + Common Packages
kubeflownotebookswg/jupyter-pytorch-full JupyterLab + PyTorch + Common Packages
kubeflownotebookswg/jupyter-pytorch-cuda JupyterLab + PyTorch + CUDA
kubeflownotebookswg/jupyter-tensorflow-full JupyterLab + TensorFlow + Common Packages
kubeflownotebookswg/jupyter-tensorflow-cuda JupyterLab + TensorFlow + CUDA
kubeflownotebookswg/rstudio-tidyverse RStudio + Tidyverse
kubeflownotebookswg/codeserver-python code-server + Conda Python

Administrators can create and provide custom images for users. Please review the related documentation for custom images below.

Custom Images

Administrators can build their own custom images to use with Notebooks.

Image Requirements

For a container image to work with Notebooks, please ensure the following requirements are met:

  • Expose an HTTP interface on port 8888:

    • Set an environment variable NB_PREFIX at runtime with the URL path you expect the container be listening under
    • Use IFrames, so ensure your application sets Access-Control-Allow-Origin: * in HTTP response headers

  • run as a user called jovyan:

    • the home directory of jovyan should be /home/jovyan
    • the UID of jovyan should be 1000

  • start successfully with an empty PVC mounted at /home/jovyan:

    • Ensure you mounts a PVC at /home/jovyan to keep state across Pod restarts

Install Python Packages

Users can extend one of the images and install any pip or conda packages their Notebook. A common cause of errors is users running pip install --user ..., causing the home-directory (which is backed by a PVC) to contain a different or incompatible version of a package contained in /opt/conda/...

Install Linux Packages

Users can extend one of the images and install any apt-get packages your Notebook users are likely to need. Ensure you swap to root in the Dockerfile before running apt-get, and swap back to $NB_USER after.

Configure S6 Overlay

Some use-cases might require custom scripts to run during the startup of the Notebook Server container, or advanced users might want to add additional services that run inside the container (for example, an Apache or NGINX web server). To make this easy, we use the s6-overlay.

The s6-overlay differs from other init systems like tini. While tini was created to handle a single process running in a container as PID 1, the s6-overlay is built to manage multiple processes and allows the creator of the image to determine which process failures should silently restart, and which should cause the container to exit.

Create Scripts

Scripts that need to run during the startup of the container can be placed in /etc/cont-init.d/, and are executed in ascending alphanumeric order.

An example of a startup script can be found in ./rstudio/s6/cont-init.d/02-rstudio-env-fix. This script uses the with-contenv helper so that environment variables (passed to container) are available in the script. The purpose of this script is to snapshot any KUBERNETES_* environment variables into the Renviron.site at pod startup, as without these variables kubectl does not work.

Create Services

Extra services to be monitored by s6-overlay should be placed in their own folder under /etc/services.d/ containing a script called run and optionally a finishing script finish.

An example of a service can be found in the run script of .jupyter/s6/services.d/jupyterlab which is used to start JupyterLab itself. For more information about the run and finish scripts, please see the s6-overlay documentation.

Run Services As Root

There may be cases when you need to run a service as root, to do this, you can change the Dockerfile to have USER root at the end, and then use s6-setuidgid to run the user-facing services as $NB_USER.

For example, the default images run s6-overlay as $NB_USER (not root), meaning any files or scripts related to s6-overlay must be owned by the $NB_USER user to successfully run.