Container
für paketierte Anwendungen

Container stellen ein kompaktes Format bereit, in das eine (wissenschaftliche) Software zusammen mit all ihren Abhängigkeiten "paketiert" wird. Dieses "Paket" kann dann von sog. "Container-Runtimes" so ausgeführt werden, als wäre die komplette Anwendung mit all ihren Abhängigkeiten lokal installiert worden.

Überblick

Während Container einen bequemen Weg bieten, komplexe Anwendungen fertig verpackt zu nutzen, bergen die Container-Laufzeitumgebungen einige Möglichkeiten für Probleme.

Beispielsweise muss jeder Zugriff auf Dateien unserer clusterweiten Filesysteme pro Container eigens konfiguriert werden (durch Definition sog. „volumes“). Hinzu kommt, dass die meisten Container-Laufzeitumgebungen nicht (bzw. nicht gut) mit Netzwerk-Dateisystemen umgehen können (sowohl NFS als auch GPFS/SpectrumStorage, worauf unser Lichtenberg-Speicher basiert).

Außerdem ist es schwierig bis unmöglich, aus einem Container heraus auf unser Software-Modulsystem zuzugreifen.

„Über“-Containerisierung

In manchen Fällen enthält ein Container nur eine bestimmte Python-Interpreter-Version zuzüglich einiger Python-Module.

In solchen Fallen ist es einfacher, dafür mit denselben Modulen ein "python virtual environment „ aufzusetzen.

Viel leichter einzurichten und zu pflegen, arbeitet es außerdem perfekt mit den Cluster-Filesystemen und unserem Modulsystem zusammen.

Prüfen Sie daher Ihr gewünschtes Container-Rezept zuerst darauf, ob es wirklich sehr komplexe Abhängigkeiten elegant löst, oder nur solch ein “einfaches" Setup beinhaltet!

Unterstützte Container-Laufzeitumgebungen

Auf dem Lichtenberg-Cluster unterstützen wir nur folgende CRIs:

  • Apptainer (früher Singularity)

Teilweise unterstützt und mit viel manuellem Aufwand unsererseits verbunden:

  • podman – benötigt manuelles Mapping von sub-UIDs und sub-GIDs, und arbeitet nicht gut mit Netzwerk- bzw. geteilten Dateisystemen zusammen

Nicht unterstützt wird

  • docker – benötigt erweiterte Rechte („root“-Zugriff)

Apptainer

Apptainer (früher Singularity) ist eine relativ leichtgewichtige und portable Container-Laufzeitumgebung. Weil mit explizitem Fokus auf HPC-Umgebungen entwickelt, läuft es verhältnismäßig gut auf Linux-Clustern und deren Netzwerk-Dateisystemen.

Aufsetzen

Um fertige Container-Abbilder im docker-Format (hier als Beispiel „lolcow“) in das apptainer-Format zu wandeln:

# Aus der „docker“-Registry:​

mkdir -p myCont && cd myCont
singularity build lolcow.sif docker://godlovedc/lolcow​
singularity run lolcow.sif​


# Vom „docker“-Archive („podman pull“ only works if podman is correctly configured):

mkdir -p myCont && cd myCont
podman pull docker://godlovedc/lolcow​
singularity build lolcow_from_archive.sif docker-archive://$(pwd)/lolcow_docker_archive.tar​
singularity run lolcow_from_archive.sif​


# Aus einem „docker“-File:

mkdir -p myCont && cd myCont
git clone https://github.com/GodloveD/lolcow​
source myenv/bin/activate​
spython recipe lolcow/Dockerfile ./sing.lolcow​
singularity build --fakeroot lolcow_from_dockerfile.sif sing.lolcow​
singularity run lolcow_from_dockerfile.sif​
deactivate​
Diese Schritte sind nur einmalig auf einem Loginknoten erforderlich, nicht in jedem Batch-Job!

Verwendung im Batch-Job

Um solche konvertierten apptainer in einem Batch-Job zu benutzen, brauchen Sie jetzt nur noch die zwei Zeilen

cd myCont
singularity run lolcow_from_dockerfile.sif​

in Ihr Jobscript aufzunehmen.