Hmmmm, I see some options depending on what kind of content to inject. I would not recommend building a new docker image in general though, I feel it is a bit messy solution that isn’t so sustainable as the options that would resist issues during z2jh upgrades better I think.
Here are some thoughts.
Do you want to inject Python code? Then, you can do it like…
# stub written from memory, beware of errors
from jupyterhub.auth import Authenticator
# and then declare the authenticator to be used, i don't remember how, see reference:
Do you want to inject templates for JupyterHub with images etc? Then, you can do it like…
Arrrrgh I hoped to reference a post I wrote recently about this on GitHub, but it was not very findable through google search or GitHub search… Okay so the idea is to use hub.extraVolumes and hub.extraVolumeMounts which should preferably be described in the configuration reference of z2jh but isn’t currently.
- name: templates
- name: templates
# Note JuputerHub would need to be configured to use these after they are injected
# And a Kubernetes PVC needs to be created named my-templates-pvc
# And the PV created dynamically by the PVC would need to be populated with content
# perhaps through the use of `kubectl cp`
Do you want to install additional packages without needing to build a docker image? Then, you can do it by…
Well, ehm… Perhaps by using a script that installs things on startup, or, you could by being knowledgable about pip figure out where to inject a directory with the package using the extraVolumes idea above.
I’ve used the jupyterhub configuration file to execute one time Python code on startup of the hub. So you could potentially install extra libraries from there. Though I think at that point I’d make my own docker image. However you don’t need to make your own helm chart to do that. You can use the existing chart with a custom image.
To use a custom image with the existing chart set hub.image.name and/or hub.image.tag in your configuration file for the helm chart.