Overview

• This is an open source fork of Kubeflow notebook servers with new features, latest packages and others.

• The following images are considered base images, which you can extend:

  • Jupyter: The base JupyterLab image with built-in Elyra supports

• The Jupyter built-in with:

  • Python 3.10
  • JupyterLab 3.5
  • Notebook 6.5
  • Rust toolchain nightly
  • Lance
  • Elyra 3.15
  • kfp 1.8
  • jupyterlab-code-formatter
  • black
  • isort

How do I extend these images?

• Any changes made by users after spawning a Kubeflow notebook will only last the lifetime of the pod, unless they are installed into a PVC-backed directory

Adding pip packages

• Extend one of the base images and install any pip packages your Kubeflow notebook users are likely to need.

Adding apt-get packages

• Extend one of the base images and install any apt-get packages your Kubeflow notebook users are likely to need.
  • WARNING: ensure you swap to root in the Dockerfile before running apt-get, and swap back to jovyan after.

Adding container startup scripts

• 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.
• To make this easy, we use the s6-overlay.
• The s6-overlay differs from other init systems, such as the popular 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.

Custom startup 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.
• 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.

Custom service scripts:

• 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 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.
  • WARNING: our example images run s6-overlay as $NB_USER not root, meaning any files or scripts related to s6-overlay should be owned by the $NB_USER user.
• 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.