Open Source: Interaktives Rechnen mit Jupyter-Notebooks
Jupyter-Notebooks, nicht zu verwechseln mit einem physischen Laptop, sind in der Wissenschaft eine beliebte Darstellungsform, da sie auf elegante Weise die Ausführung von Code gemischt mit entsprechenden Anweisungen, Dokumentation oder Grafiken ermöglichen. Damit lassen sich unter anderem Resultate von Berechnungen nachvollziehen, mit eigenen Daten versorgen oder einfach reproduzierbare Tutorials zur Datenverarbeitung aus der gewohnten Browserumgebung heraus entwerfen.
Der darunterliegende Kernel, genauer die Zwischenschicht, welche die Ausführung von Programmen ermöglicht, ist von Haus aus auf interaktive Ausführung von Python-Code zugeschnitten ( ipykernel ), es existieren aber auch andere Implementierungen, wie beispielsweise für die Sprache Julia, welche aufgrund ihrer verbesserten Performance gegenüber Python gerne in wissenschaftlichen Anwendungen eingesetzt wird.
Das darauf aufbauende Open-Source-Projekt Jupyterhub(öffnet im neuen Fenster) stellt eine Serverumgebung zur Verfügung, die es erlaubt, ohne lokale Installation ausführbare Notebooks mit der entsprechend nötigen Software in der Cloud oder auch lokal per Klick zu starten. Die Voraussetzung dafür ist, dass sich die Notebooks auf einem zugänglichen Git-Repository wie Github, Gitlab usw. befinden.
Per Binderhub zum Jupyter-Notebook
Für öffentliche Jupyter-Anwendungen übernimmt mybinder.org(öffnet im neuen Fenster) die Schirmherrschaft mit dem Projekt Binderhub, unterstützt durch mehrere Cloud-Hoster. Auf der Webseite findet sich zunächst eine einfache Eingabemaske, in die wir die URL zu einem Git-Repository (welches *.ipynb-Dateien enthält) eingeben können. Per Launch-Knopf wird der Server gestartet. Dabei passiert (per repo2docker -Script) Folgendes:
- Das Repository wird geklont und nach Konfigurationsdateien durchforstet.
- Basierend auf der Konfiguration wird ein Docker-Container mit Jupyter-Support gebaut und zwischengespeichert.
- Der Container wird gestartet und ein Jupyterlab-Serverprozess aktiviert, auf dessen URL der Browser schließlich weitergeleitet wird.
Das kann je nach Anwendung und Auslastung der Server etwas Zeit in Anspruch nehmen. Wenn nichts schiefgeht, präsentiert sich danach die Jupyterlab-IDE und es kann gearbeitet werden, allerdings sollte das auch aktiv geschehen. Die laufenden Jupyter-Kernels unterliegen einem Timeout und werden nach circa zehn Minuten Inaktivität beendet. Dann sind ohne Vorwarnung auch alle eingegebenen Daten erst mal weg oder müssen mühevoll manuell aus dem Notebook gerettet werden.
Wurde das Repository in seiner Konfiguration schon einmal gebaut, werden der erste und zweite Schritt übersprungen und der Server startet etwas schneller, auch hier wieder abhängig von der Konfiguration des Containers.
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(öffnet im neuen Fenster) -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
wobei "mein_lab" durch den Namen des passenden Images ersetzt wird. Eine Liste passender Standard-Images(öffnet im neuen Fenster) 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.
Vielfältige Anwendungsmöglichkeiten umsetzbar
Die Jupyter-Umgebung braucht sich vor einer klassischen IDE nicht zu verstecken. Für eine Vielzahl von Dateiformaten bietet der eingebaute Editor (der eher für längere Quelltexte genutzt wird) entsprechende Kontextsensitivität wie Highlighting, zudem lässt sich für die Puristen vim - oder emacs -Verhalten einstellen.
So lässt sich auch fernab klassischer Python-Programmierung ein Lehrgang erstellen, der z. B. die Anwendung einer C-Bibliothek, deren Kompilation oder ein Beispiel zur Ein- und Ausgabe dokumentiert. Beispielsweise:
- Systemtest einer Signalverarbeitungs-Bibliothek
- Modellierung von Filtern per Octave-Erweiterung
- Gegentest (Co-Simulation) von DSP-Algorithmen als Hardware-Implementationen
- Hardware-Synthese für FPGA aus ebendiesen Beschreibungen
Die Jupyterlab-IDE lässt sich auf mehrere Arten elegant erweitern. Dazu ist eine Auswahl eingebaut, die Erweiterungen von Drittparteien anzeigt und per Klick installiert. Nach Installation einer Erweiterung findet sich typischerweise ein weiteres grafisches Element in der Menüleiste oder es lässt sich eine neue Cell-Magic-Anweisung(öffnet im neuen Fenster) wie %cd in einer Jupyter-Zelle eingeben, die den folgenden Code oder Kommandos speziell behandelt. Einige Beispiele für nützliche Erweiterungen:
- RISE(öffnet im neuen Fenster) für Erstellung von Slide-Präsentationen
- Cython(öffnet im neuen Fenster) als Magic-Zellanweisungen, um bestehenden Python-Code automatisch als C-DLL zu kompilieren
- pytest-notebook(öffnet im neuen Fenster) zum automatisches Testen von Notebooks
Letztere Erweiterung ist insbesondere in der laufenden Entwicklung hilfreich und hilft sicherzustellen, dass nach größeren Releases und der Ansammlung von Testszenarien auch noch alles funktioniert wie davor und die technische Dokumentation zu einem API oder ein 'HOWTO' mit Kommandosequenzen noch auf dem aktuellen Stand ist.
Neben den Timeouts und der fehlenden Speichermöglichkeit gelten bei mybinder.org noch einige Einschränkungen. Aufwendige Berechnungen und großer Speicherbedarf können unter Umständen dazu führen, dass man temporär von der Nutzung ausgeschlossen wird, bis auch sichergestellt ist, dass die Server nicht per Bot-Software für Kryptomining oder Ähnliches missbraucht werden. Weitere Einschränkungen gegenüber der lokalen Installation:
- Keine nachträgliche Installation von Softwarepaketen auf Systemebene (keine Root-Rechte per sudo)
- Beschränkte Netzwerkverbindungen (git, http)
- Absolute URL-Pfade auf laufende Notebooks sind nur per Sitzung gültig und können für Links nicht verwendet werden.
Den Lesern, die nun Appetit auf mehr bekommen haben, sei das erfrischend geschriebene Tutorial Zero-to-Binder nahegelegt, welches ebenfalls direkt auf der mybinder-Einstiegsseite verlinkt ist. Dort finden sich auch weitere Listen von Beispiel-Repositories.
Nicht zuletzt sollte auch erwähnt werden, dass diese kostenlose Cloud-Umgebung von einer Föderation, der Binder Federation, bestehend aus Hostern wie OVH, Google Cloud, wie auch dem GESIS Leibniz-Institut getragen wird. Es bleibt zu hoffen, dass dieses Ökosystem als de-facto-Standard auch weiterhin Schule macht.