🤔 Problem

Docker images used for Renku interactive sessions are required to contain a Jupyter installation. All other front-ends (e.g. RStudio, VSCode) are actually served via a jupyter server proxy extension. This approach has many problems:

• it is prone to breaking when the jupyter server proxy is updated
• it bloats images that don’t need Jupyter or Python
• it requires us to maintain sets of base images
• …

Current workflow and assumptions

Running any container image and have it function within the platform means that it has to satisfy certain conditions. At the moment, we satisfy these conditions “automatically” by providing base images that:

• define and configure a user (uid/gid) with correct non-root permissions
• make sure the command we will execute is there (jupyter notebook)

We hard-code the command that is run in the container, which makes it rather inconvenient to run any image without jupyter inside. We also hard-code the ports.

In Kubernetes terms, we honor the docker ENTRYPOINT of the image (i.e. command) but override the docker CMD (i.e. args).

🍴 Appetite

6 weeks

🎯 Solution

<aside> ☝ See also: ‣

</aside>

Going forward, we would like to enable users to use images that don’t contain Jupyter. This will streamline the image building process and open up possibilities to use “off-the-shelf” images instead of having to continue providing and maintaining a suite of base images.

Overall context