Per Docker-Container zur Quellcodebearbeitung

Normalerweise reicht das Python-Ökosystem mit seinen pip- oder conda-Paketmanagern zur Nachinstallation von Software aus. Wer allerdings auf externe Software aufbaut, kann verschiedene Konfigurationsdateien per Repository mitliefern, die gegebenenfalls Abhängigkeiten beim Bau des Containers auflösen, also zusätzliche Software oder eine spezifische Version installieren.

Das kann auf verschiedenen Ebenen geschehen, bis zur Erstellung eines angepassten Dockerfiles im Repository. Das bringt allerdings etwas Komplexität mit sich, tunlichst sollte von einer gut funktionierenden Vorlage ausgegangen werden. Die mybinder-Dokumentation (über den read the docs-Link der Hauptseite erreichbar) gibt dazu genauere Auskünfte.

Lokale Ausführung

Als ein großer Nachteil erweist sich, dass die eingegebenen Daten nicht persistent sind. Es ist allerdings möglich, sich mit Einmal-Passwörtern oder oauth2-Tokens Schreibzugriff auf die eigenen Git-Repositories zu ermöglichen. Allerdings bietet das keine optimale Sicherheit, sensible Repositories ohne Sicherheitskopie sollte man damit nicht kompromittieren.

Somit kommt man nicht umhin, eine lokale Kopie der Umgebung zu nutzen. Einen eigenen Jupyterhub aufzusetzen, ist aber nicht zwingend nötig, denn ein passender Docker-Container kann lokal gestartet werden.

Linux-Nutzer installieren sich so üblicherweise die Docker-Laufzeitumgebung und starten den Container per

docker run -it --rm -v$HOME/src:/home/jovyan/src -p 8888:8888 mein_lab jupyter-lab --ip=0.0.0.0 --port=8888

wobei "mein_lab" durch den Namen des passenden Images ersetzt wird. Eine Liste passender Standard-Images findet sich auf der Seite der offiziellen Jupyter-Docker-Images. Der exotisch anmutende Username jovyan ist der Standard-Nutzername der Jupyter-Community und kann prinzipiell per Dockerfile-Anpassung geändert werden.

Die -v-Option (Volume) macht ein lokales Entwicklungsverzeichnis $HOME/src aus der Containerumgebung zugänglich. Dabei ist es sinnvoll, ein Zielverzeichnis unter dem Nutzer-Home (innerhalb des Containers) zu wählen, da Jupyterlab selbiges als höchste Ebene in seiner Dateiauswahl ansieht, darüberliegende Dateien sind nicht sichtbar.

Nach erfolgreichem Start des Jupyterlab-Servers gibt die Konsole eine lokale URL aus, unter der per Browser die frisch gestartete grafische Umgebung aufgerufen wird. Für weitere Betriebssysteme läuft die Docker-Umgebung unter dem Terminus Docker Desktop und lässt sich von der Docker-Webseite herunterladen.

Quellcodebearbeitung

Für die schnelle Ansicht eines Notebooks mögen die Anzeigefähigkeiten von Github ausreichend sein, aber im Sinne von detaillierterem Spielen ist die mybinder-Lösung eine wunderbar effiziente Umgebung, um in Zeiten erzwungener Heimarbeit die Projektpartner mit nachvollziehbaren Resultaten zu versorgen. Das motiviert auch zu nachhaltiger Dokumentation und hat so seine Vorteile gegenüber knappen Informationstransfers in der Mittagspause oder per E-Mail.

Für die Erstellung von Inhalt allerdings benötigt man ein gemachtes Nest. Ohne lokale Installation von Software wird es knifflig, dann müssten sich die Nutzer ihre Strategie zur Speicherung von Änderungen innerhalb der Cloud selbst erarbeiten. Schön wäre eine Lösung analog zu Google Docs, allerdings ist das noch Zukunftsmusik, über die innerhalb der Entwicklerriege offenbar noch nachgedacht wird.

Für akademische Zwecke bietet der Ansatz ohne Zweifel einen Zugewinn an Komfort. Eigene Experimente haben ergeben, dass sich die Umgebung sogar eignet, um Onlinetests abzulegen. Dazu ist allerdings eine eigene Jupyterhub-Instanz vonnöten, die nicht bei fehlender Aktivität die Sitzung abschießt und bei Verbindungsproblemen zumindest einen Wiedereinstieg ermöglicht. Die abgeschlossenen Tests werden aus dem Notebook heraus schlicht per Git-Kommando in das eigene Repository geschoben.