We’re trying to get Z2JH going on AWS and so far so good. However, we’d like to use a CAS based authentication scheme. We should be able to use something like the REMOTE_USER authenticator for this:
However, it wasn’t clear what the right entry point for injecting a custom authentication module should be when using the Z2JH Jupyter Helm charts.
We could probably fork the helm chart and come up with our own version with a custom Docker image, but that means additional work staying in sync with the upstream repo.
Is there a canonical way to add dependencies or packages (such as a pip install) into an existing setup?
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…
hub:
extraConfig:
myExtraConfig: |
# stub written from memory, beware of errors
from jupyterhub.auth import Authenticator
class MyCustomAuth(Authenticator):
pass
# and then declare the authenticator to be used, i don't remember how, see reference:
# https://jupyterhub.readthedocs.io/en/latest/reference/authenticators.html
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.
hub:
extraVolumes:
- name: templates
persistentVolumeClaim:
claimName: my-templates-pvc
extraVolumeMounts:
- name: templates
mountPath: /var/jupyterhub/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.
Building FROM an image will require bumps in the image as well with updates to the helm chart if the image has changed along with the helm chart, but it is fine if it explicit that this is done,
Yes, if building images with all chart upgrades is plausible, then this is perhaps the best option for an additional python package for example. Yepp!!! I now appreciate this solution most
@consideRatio To clarify - I don’t think we want to inject a custom class. Mostly, I want to try and “pip install” a package in the image. Then we can just set the authenticator in the config.
@jhermann I’m assuming I still need to have my own helm repo though, right? (Given that the Dockerfile is in the repo itself).
I was hoping that helm provided a way to “upgrade” an image with custom packages.
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.
OK - great - I think this is the answer I was looking for. I’m still in the early stages of wrapping my head around k8s / helm - thanks for helping provide some guidance here.
Well, I’m living in a world where CI/CD (GitLab CI, Jenkins, GoCD), ample repository support (Artifactory), and on-prem cloud (K8s) is “just there” because co-workers make it so.
Thus, some solutions are ‘obviously’ simple for me, when they might be not so much for others.
