Apptainer - Anwendungcontainer für Linux

• Open-Source-Container-Plattform, entwickelt mit Fokus auf Einfachheit, Geschwindigkeit und Sicherheit
  • Optimal für HPC (High Performance Computing) und Shared-System-Umgebungen
• Bietet ein unveränderliches (immutable) Single-File-Container-Image-Format mit Unterstützung für Verschlüsselung und Signierung
• Statt auf Isolation liegt der Fokus auf integrierter Nutzbarkeit, sodass sich in Cluster-/Server-Umgebungen GPU, Hochgeschwindigkeitsnetzwerke und parallele Dateisysteme direkt nutzen lassen
• Kann Container aus OCI-(Open Containers Initiative)-Registries abrufen und maximiert die Kompatibilität mit Docker
  • Unterstützt das Pullen (pull), Ausführen (run) und Bauen (build) der meisten Container auf Docker Hub ohne Änderungen
• Vom bisherigen Singularity umbenannt und als Projekt zur Linux Foundation überführt
• Mit Single-File-Containern auf Basis von SIF (Singularity Image Format) lassen sich Container leicht verschieben, verteilen und teilen
• Innerhalb und außerhalb des Containers gelten dieselben Benutzerrechte; angewendet wird ein sicheres Sicherheitsmodell, das standardmäßig keine zusätzliche Rechteausweitung auf dem Host erlaubt
• BSD-Lizenz

[galadbran]

In den Hacker-News-Kommentaren erwähnter Artikel zu unregistry:
Unregistry – „docker push“ direkt ohne Registry an den Server senden | GeekNews

[GN⁺]

Hacker-News-Kommentare

• Unser Team hat Apptainer in einem Compute-Cluster für Siliziumdesign/-verifikation ausprobiert, ist am Ende aber wieder zu klassischen TCL-Modulen (umgestellt auf Lua) zurückgekehrt

  • Wir hatten mehrere Probleme.
    • Erstens können Container nicht gegenseitig aufeinander zugreifen. Wenn sich zum Beispiel Tools wie Make, GCC, Git jeweils in unterschiedlichen Apptainern befinden, sieht man GCC nicht mehr, sobald man in Make drin ist
    • Zweitens funktionieren Artefakte, die vom Inneren des Containers abhängen, nicht richtig. Wenn man ein Programm mit dem GCC-Apptainer baut, ist das erzeugte Binärprogramm an Bibliotheken im Apptainer gebunden und läuft nicht, außerdem gab es C-Header-Probleme
    • Drittens geriet der PATH-Wert ständig durcheinander, sodass notwendige Pfade oder Tools außerhalb von Apptainer immer wieder nicht sichtbar waren
    • Insgesamt war die Idee gut, aber bei der praktischen Nutzbarkeit war es nur umständlich, sodass es am Ende viel einfacher war, direkt ein altes OS (RHEL8) zu verwenden
  • Ich betrachte Apptainer/Singularity als etwas Ähnliches wie Docker (nur ohne vollwertige Netzwerkkonfiguration). Solche Probleme treten auch bei traditionellen Docker-Containern genauso auf.
    • In meinem HPC-Workflow nutze ich Apptainer als Drop-in-Ersatz für Docker, und dafür passt es gut
    • Der größte Vorteil von Apptainer sind Container ohne Root-Rechte. Dadurch sind komplexe Netzwerkkonfigurationen zwar nicht möglich, aber in Multi-Tenant-Umgebungen wie HPC ist es deutlich sicherer
  • Wenn die größte Beschwerde an Container-Apps ist, dass sie sich wie Container verhalten, dann ist das eben das Wesen von Containern
  • Man sollte Container-Bausteine nicht miteinander vermischen. Das ist so, als würde man Binärprogramme aus verschiedenen Linux-Distributionen mischen
    • Idealerweise nutzt man Container für die Entwicklung in einer integrierten Umgebung. Container sind isolierte Umgebungen, daher sollten auch die Ergebnisse von Kompilierungen in ihrem eigenen Container bleiben
    • Man kann allerdings mehrere Container mit derselben Base-Image erzeugen, um Dateikompatibilität sicherzustellen (aber nur, wenn man alle nötigen Abhängigkeiten einschließt)

• Es ist schön zu sehen, dass Apptainer Aufmerksamkeit bekommt. In manchen Situationen ist es Docker, Podman usw. überlegen

  • Wenn mehrere Jobs in einem Container ausgeführt werden müssen (was bei anderen Container-Technologien nicht empfohlen wird)
  • HPC (und einige Hochschulumgebungen)
  • Unterstützung für ein Single-File-Deployment-Modell (allerdings ohne Deltas)
  • Verschlüsselte Signierung von SIF-Dateien ohne separaten externen Server
  • Starke GPU-Unterstützung

• Auch Docker ermöglicht mit den Befehlen docker save und docker load ein Single-File-Deployment.

  • Es unterstützt zwar keine Deltas, aber kürzlich wurde auf HN eine Lösung namens „unregistry“ verlinkt, die auch ohne Docker Registry so etwas wie „docker push“ und Delta-Übertragung ermöglicht

• Sowohl Apptainer als auch singularity ce werden in HPC häufig verwendet. Beide Produkte wurden zwar aus dem alten Singularity-Projekt heraus abgespalten, sind aber nicht völlig identisch

  • Wir verwenden singularity auf mehreren Supercomputern (HPC), und einige Forschende installieren und nutzen Apptainer lokal
  • Kürzlich haben wir in Python-Code (matplotlib, xarray usw.) einen Zeitzonen-Bug gefunden; mit singularity ce gab es Probleme, aber in Apptainer funktionierte es korrekt
  • Das neue Apptainer hat eine ähnliche Codebasis, aber Bugfixes werden schneller übernommen. Zum Beispiel überschreibt singularity die Zeitzone des Benutzers im System, was Probleme verursachte
  • Referenzlink: singularity issue #3686
  • Apptainer ist kein Fork des alten Singularity-Projekts. Apptainer ist das ursprüngliche Hauptprojekt, nur mit einem per Community-Abstimmung geänderten Namen. Es ist unter das Dach der Linux Foundation gewechselt
    • singularity ce ist der Fall, in dem Sylabs den ursprünglichen Entwickler angeworben und das Projekt geforkt hat
    • Referenz: community announcement
  • Die gegenseitige Container-Kompatibilität bleibt trotzdem erhalten, sodass man in Apptainer bauen und in Singularity ausführen kann (und umgekehrt)

• Apptainer ist im Grunde Singularity. Das zugehörige Paper ist hier

  • Wenn man auf gemeinsam genutzten Systemen an Hochschulen oder in staatlichen Clustern arbeitet, ist Apptainer fast immer vorhanden, Podman/Docker dagegen kaum
  • In solchen Umgebungen ist es oft vorteilhafter, statt Container zu verwenden, sich mit den Systemadministratoren gutzustellen und zu verstehen, wie der betreffende Cluster betrieben wird
  • Mich würde interessieren, warum Docker/Podman weniger genutzt werden und warum es gut sein soll, Container zu vermeiden. Liegt das vielleicht an Performance?

• Flatpak will von OSTree auf einen containerbasierten Ansatz umsteigen. Gut gepflegte Container-Tooling sei dabei ein großer Vorteil. Ich frage mich aber, wie sich das von Apptainer unterscheidet

  • Vermutlich ist das Besondere bei Flatpak, dass es über xdg-dbus eine feingranulare Rechtevergabe und andere Kontrollen für einzelne App-Sandboxes ermöglicht, damit sich Anwendungen nativer anfühlen
    • Ich bin mir nicht sicher, ob Apptainer in diesem Maß vollständig trennt/isoliert
    • Mit Tools wie containertoolbx wird der Unterschied zwischen Container-Ansätzen ohnehin weniger wichtig
    • Ehrlich gesagt gibt es viel Funktionsüberschneidung zwischen den Tools, aber ich finde das an sich in Ordnung

• In meiner Umgebung ist der Hauptgrund für den Einsatz von Apptainer weder Deployment noch Isolation noch Softwareverfügbarkeit.

  • Unser HPC-Cluster hat für jeden Benutzer ein Inode-Quota-Limit, wodurch sich Software mit sehr vielen Dateien (z. B. Anaconda) nur schwer installieren lässt
  • Apptainer-Images sind jedoch einzelne squashfs-Dateien, sodass man mehrere davon haben kann, ohne sich um das Inode-Quota zu sorgen
  • Eine normale Installation derselben Software wäre zwar einfacher, aber das Quota ist sehr schnell ausgeschöpft

• Ich stimme Havocs Kommentar zu. Die Botschaft ist etwas unklar: Ist Apptainer ein Flatpak-Ersatz für den Desktop oder eher für Server gedacht?

  • Für Server. Allerdings ist schon die Frage selbst etwas unklar
    • Apptainer ist für die Ausführung von CLI-Apps in unveränderlichen (immutable), rootless Containern gedacht
    • Das ähnlichste Tool ist Fedora Toolbx
    • Der Hauptanwendungsfall von Apptainer ist die Verteilung und Wiederverwendung wissenschaftlicher Rechenwerkzeuge. Es funktioniert ohne Root-Rechte, das rootfs ist pro Container nicht veränderbar, das Arbeitsverzeichnis wird automatisch gemountet, und die GPU-Unterstützung ist gut (das habe ich selbst aber nicht getestet)
    • Referenz: Fedora Toolbx

• Der Name „Apptainer“ ist seltsam auszusprechen und klingt irgendwie nicht ganz richtig

• Als Entwickler sucht man vielleicht nach Container-Tools zur Isolation

  • Ich habe auf Basis von Podman ein Tool gebaut, um verschiedene Entwicklungsprojekte voneinander zu isolieren. Falls das für Sicherheitstests oder den Einsatz interessant ist, siehe den Code oder den Blogpost
  • Ich frage mich, warum toolbox nicht ausgereicht hat
    • Ich fand toolbox okay, weil man für Entwicklungsumgebungen pro Projekt nicht mehrere versteckte Dateisysteme verwalten muss

• In SLURM-Clustern und auf Servern ohne Root-Rechte ist es sehr nützlich

  • Ich habe es ebenfalls in einem SLURM-Cluster verwendet
    • Die offizielle Dokumentation ist gut genug für den Einstieg
    • Wenn man allerdings weder fakeroot noch sudo hat, muss man Apptainer lokal bauen und dann mühsam direkt auf den Server übertragen