Jupyter Server Proxy

Integration externer Tools in JupyterHub

Mit Jupyter Server Proxy lassen sich externe Webanwendungen wie RStudio Server oder Shiny nahtlos in JupyterLab integrieren. In einer Kubernetes-Umgebung profitieren User zudem von stabilen und flexibel erweiterbaren Arbeitsumgebungen – ohne lokale Installation.

Was ist JupyterHub?

JupyterHub ist eine Open-Source-Plattform, die Jupyter Notebooks für mehrere User gleichzeitig bereitstellt. Dabei erhalten die User eine eigene, voneinander isolierte Arbeitsumgebung, in der sie sicher und unabhängig arbeiten können. AdministratorInnen können zentral festlegen, welche Software, Ressourcen und Images zur Verfügung stehen. Durch die flexible Anbindung von Authentifizierungssystemen lässt sich JupyterHub nahtlos in bestehende IT-Infrastrukturen integrieren. In Kombination mit Kubernetes kann die Plattform automatisch skalieren, indem für alle User eigene Pods (kleinste Kubernetes-Einheit, die aus einem oder mehreren Containern bestehen) gestartet werden. Dadurch eignet sich JupyterHub besonders für kollaborative Data-Science-Umgebungen, Trainingsszenarien und produktive Analyseplattformen.

Was versteht man unter "Jupyter Server Proxy"?

Jupyter Server Proxy ist nichts Neues und Ausgefallenes im Jupyter-Ökosystem, sondern eine Software, die von ihren großen Projekten genutzt wird und oft übersehen wird. Die Hauptanwendungsfälle dieser Software sind, wie sie im GitHub-Repository dieser Software beschrieben werden, folgende:

  • Einsatz in Kombination mit JupyterHub oder Binder, um Nutzern den Zugriff auf vollständig eigenständige Weboberflächen zu ermöglichen – etwa RStudio, Shiny oder OpenRefine – obwohl diese nicht direkt zu Jupyter gehören.
  • Sicherer Zugriff auf lokale Web-APIs durch frontendseitiges JavaScript, beispielsweise in klassischen Notebooks oder JupyterLab-Erweiterungen. Dieses Verfahren wird etwa von der JupyterLab-Erweiterung für Dask genutzt, um lokal laufende Dienste kontrolliert und geschützt erreichbar zu machen.

Wie so oft in der Python-Welt gibt es auch hier kaum Grenzen für kreative Einsatzmöglichkeiten.
So können sie beispielsweise Usern den Umgang mit RStudio oder anderen Serveranwendungen vermitteln, ohne dass eine vollständige lokale Installation notwendig ist. Ein wesentlicher Vorteil beim Betrieb auf Kubernetes ist zudem die Containerisierung: Stürzt ein Server ab, reicht ein Neustart aus, um sofort wieder eine saubere und funktionsfähige Umgebung bereitzustellen. Ebenso können Sie den Ansatz nutzen, um eine einzelne Shiny-App bereitzustellen. Für genau solche Szenarien empfiehlt sich besonders die Kombination aus JupyterHub und BinderHub – einem weiteren Projekt aus dem Jupyter-Ökosystem. Dies sind nur einige der Anwendungsfälle, die wir bislang umgesetzt haben. Wenn Sie mehr über weitere Möglichkeiten oder die Nutzung mit anderen Anwendungen als RStudio Server erfahren möchten, lohnt sich ein Blick in die Dokumentation von Jupyter Server Proxy.

Warum funktioniert diese Methode?

Jupyter Server Proxy startet den Proxy-Server zusammen mit dem laufenden Jupyter-Server innerhalb eines User-Session-Pods auf Kubernetes. In einer herkömmlichen JupyterHub-Installation, mit nur einem Server könnten alle Nutzer auf diesen zusätzlichen Dienst zugreifen, sofern ihnen Link und Port bekannt sind – da viele dieser Dienste standardmäßig über Adressen wie „localhost:8080“ bereitgestellt werden.

In einem Kubernetes-basierten JupyterHub besteht dieses Risiko nicht: Der gesamte Datenverkehr wird über den jeweiligen User-Session-Pod und dessen freigegebene Ports geleitet. Der Pod öffnet ausschließlich die für JupyterLab notwendigen Ports und übernimmt gleichzeitig die Benutzerauthentifizierung. Alle integrierten Server laufen vollständig innerhalb des Pods und sind dadurch für andere Nutzer nicht erreichbar. Die folgende Grafik veranschaulicht die Netzwerkverbindungen:

Beispiel einer Server-Architektur von Jupyter Server Proxy

Ein Beispiel

Um diese Lösung selbst auszuprobieren, benötigen Sie zunächst einen JupyterHub auf Kubernetes, den Sie nach Ihren Bedürfnissen konfigurieren können, sowie eine Container-Registry, in der Sie Ihre Images ablegen und abrufen können. Falls Sie aktuell keinen Kubernetes-basierten JupyterHub zur Verfügung haben, können Sie für Testzwecke mithilfe der offiziellen Anleitung „Zero to JupyterHub with Kubernetes“ problemlos einen JupyterHub über Minikube einrichten.

Als Nächstes erstellen Sie ein Container-Image für Ihren Benutzerserver und speichern es in Ihrer Registry. In diesem Image installieren Sie RStudio Server sowie den vorkonfigurierten Jupyter Server Proxy – als Basis eignet sich eines der standardmäßigen JupyterHub-Images. Offizielle Images stellt das Jupyter-Projekt unter anderem in der Red Hat Container Registry bereit.

Im Folgenden finden Sie ein minimales Proof-of-Concept-Dockerfile, das diese Einrichtung zeigt. Um die Image-Größe möglichst klein zu halten und die Build-Zeit zu verkürzen, verwenden wir dafür das Minimal-Notebook-Image von Jupyter.


DOCKERFILE

ARG REGISTRY=quay.io
ARG OWNER=jupyter
ARG BASE_CONTAINER=$REGISTRY/$OWNER/minimal-notebook
FROM $BASE_CONTAINER

# set user for installation
USER root

# Set working directory for installation
WORKDIR /opt/

# Install general system dependencies
RUN apt update && \
    apt install -y \
    gdebi-core \
    git \
    curl && \
    apt autoremove -y && \
    apt clean && \
    rm -rf /var/lib/apt/lists/*

# Install R + RStudio-Server
ARG R_DIR=/opt/R
ARG R_VERSION=4.4.0
ARG RSTUDIO_VERSION=2024.04.2-764

RUN curl -O https://cdn.rstudio.com/r/ubuntu-2404/pkgs/r-${R_VERSION}_1_amd64.deb && \
    apt update && \
    gdebi --non-interactive r-${R_VERSION}_1_amd64.deb && \
    rm r-${R_VERSION}_1_amd64.deb

RUN ln -s /opt/R/${R_VERSION}/bin/R /usr/local/bin/R && \
    ln -s /opt/R/${R_VERSION}/bin/Rscript /usr/local/bin/Rscript

RUN curl -O https://download2.rstudio.org/server/jammy/amd64/rstudio-server-${RSTUDIO_VERSION}-amd64.deb && \
    gdebi --non-interactive rstudio-server-${RSTUDIO_VERSION}-amd64.deb && \
    rm rstudio-server-${RSTUDIO_VERSION}-amd64.deb && \
    rm -rf /var/lib/rstudio-server/r-versions

# install jupyter-server-proxy
RUN pip install jupyter-rsession-proxy

# set user for session
USER ${NB_UID}

# Set working directory for session
WORKDIR "${HOME}"

Als nächsten Schritt konfigurieren Sie Ihren JupyterHub so, dass er das neu erstellte Image verwendet. Passen Sie dazu die Singleuser-Konfiguration Ihres JupyterHub wie folgt an:

config.yaml
singleuser:
  profileList:
    - display_name: "JupyterLab with RStudio"
      description: "Jupyterlab with Jupyter Server Proxy for RStudio"
      kubespawner_override:
        image: {{ your-registry }}/{{ image-name }}

Nachdem Sie die Konfiguration angepasst und Ihren JupyterHub neu gestartet haben, sollte das neue Session-Image in der Serverliste erscheinen. Starten Sie von dort aus einen neuen Server mit diesem Image – anschließend können Sie RStudio Server direkt aus JupyterLab heraus starten.

Fazit

Die Kombination aus JupyterHub, Kubernetes und Jupyter Server Proxy eröffnet einen effizienten Weg, zusätzliche Tools wie RStudio Server oder Shiny in bestehende Data-Science-Plattformen zu integrieren. Für Unternehmen und Teams bedeutet das:

  • geringeren Administrationsaufwand,
  • reproduzierbare und stabile Arbeitsumgebungen,
  • mehr Flexibilität bei der Wahl der Werkzeuge
  • und eine hohe Skalierbarkeit für Schulungen und Projekte.

Gerne unterstützen wir Sie dabei, solche Lösungen in Ihrer Infrastruktur zu implementieren oder maßgeschneiderte Data-Science-Plattformen aufzubauen.

Veröffentlicht: [veroeffentlichungsdatum]

AutorIn

Sebastian Volkmann

Sebastian Volkmann ist seit 2023 Werkstudent bei eoda. Er befasst sich im Team Infrastruktur hauptsächlich mit den Themen Kubernetes, Infrastructure-As-Code, DevOps und der Evaluation von neuen Technologien.

Row edge-slant Shape Decorative svg added to top
Row edge-slant Shape Decorative svg added to bottom

Starten Sie jetzt durch:
Wir freuen uns auf den Austausch mit Ihnen. 

Kontakt_RIK

Ihre Expertin für Dateninfrastrukturen

Ricarda Kretschmer
infrastructure@eoda.de
Tel. +49 561 87948-370







    Nach oben scrollen