05-10, 11:00–11:30 (Europe/Paris), Louis Armand 2
Building & maintaining the docker image used whenever a user logs into a JupyterHub is one of the most time consuming, hard yet rewarding parts of running a JupyterHub. Done right, it can wow users - "YOU CAN DO THAT?!". But if not properly designed, something as simple as adding a new python package can turn into a multi-week ordeal that breaks everything, and makes the maintainer of the image hate computers. A lot of the industry's docker image advice needs to be modified for use when building docker images for use with JupyterHub, as they are meant to have arbitrary code executed in them. General docker advice often does not cover our use cases at all (who else is putting fortran into docker?).
This talk summarizes lessons learnt in building a wide variety of images for JupyterHubs over the years. It will cover:
- Building the simplest possible image that can work with a JupyterHub
- Best practices for installing python & most python-related packages inside the image, and why (hint: use
- When to base off a community built docker image (such as rocker, pangeo or jupyter-stacks), and the various tradeoffs associated with it.
- Basic maintenance that must be performed on an image periodically so a simple package install doesn't turn into a 3 week nightmare
- Suggestions for automatic building & testing with CI / CD and mybinder.org
- Best practices for including R in your image
- Best practices for running non-Jupyter frontends (such as RStudio, virtual linux desktop, code-server, etc) in your JupyterHub
The audience would be able to walk away with much better knowledge on how to maintain a docker image for use with JupyterHub in a way that keeps both the users and the maintainers of the image happy.
Co-founder at 2i2c.org. Ex Wikimedia, ex GNOME. On a motorcycle or watching star trek or texting someone when not on a computer. Death to accidental complexity.