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.

Beispiel mit NVidia GPUs

Es ist auch möglich, Container mit NVidia-GPUs zu verwenden (AMD und Intel haben derzeit Schwierigkeiten). Hier ist ein Beispiel.

# Wir reservieren 2 NVIDIA Hopper H100 GPUs für eine interaktive Nutzung:​

srun -t 07:00:00 -n16 --mem-per-cpu=4G --gres=gpu:h100:2 --pty /bin/bash

# Wir exportieren ein paar Umgebungsvariablen für temporäre Dateien, um sicherzustellen, dass wir genügend Platz haben:

export TMPDIR=/work/scratch/${USER}/tmp; export APPTAINER_TMPDIR=${TMPDIR}; mkdir -p ${TMPDIR}

# Wir bauen einen Apptainer Container Image und speichern es in der Datei "pytorch_cont.sif":

apptainer build pytorch_cont.sif docker://nvcr.io/nvidia/pytorch:25.03-py3

# Wir führen einen Container auf diese Image basiert aus:

apptainer shell --nv pytorch_cont.sif

# Wir testen es ein bisschen:

Apptainer> python
Python 3.12.3 (main, Feb  4 2025, 14:48:35) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.cuda.is_available()
True
>>> torch.cuda.device_count()
2
>>> exit()
!