Portable Container zum Entwickeln, Erstellen, Verteilen und Ausführen von komplexer wissenschaftlicher Software
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 60 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/42502 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
6
13
21
25
41
53
00:00
AlgorithmusCodeDatenstrukturGeometrieSoftwareDateiLaufzeitsystemMetadatenFokalpunktQuellcodeWorkstation <Musikinstrument>SoftwarekonfigurationSystemplattformOverhead <Kommunikationstechnik>VirtualisierungInterface <Schaltung>SimulationVisualisierungC++DownloadingWeb-SeiteProzess <Physik>HochleistungsrechnenOpen SourceUmweltinformatikMedieninformatikSoftwareentwicklerVorlesung/Konferenz
06:48
Singularität <Mathematik>LINUXSchedulingDateiSoftwareLARS <Programm>HTMLUpdateDateiLaufzeitsystemUSB-StickComputeranimationXML
07:40
SoftwareLARS <Programm>HTMLCompilerAbstraktionsebeneUbuntu <Programm>DateiSoftwareVersion <Informatik>Vorlesung/KonferenzXML
09:23
CompilerAbstraktionsebeneSoftwareLARS <Programm>GNU <Software>Ubuntu <Programm>BASICLaufzeitSingularität <Mathematik>Version <Informatik>UploadingKonfigurationsdatenbankSkalarproduktBenutzerführungJenkins CIDownloadingEigenwertproblemImplementierungPersonalinformationssystemSoftwareFunktion <Mathematik>DateiInterpretiererLaufzeitVersion <Informatik>KonfigurationsraumDownloadingServerParametersystemAbstraktionsebeneRepository <Informatik>Klasse <Mathematik>LaufzeitsystemSkriptspracheKomponente <Software>p-BlockUbuntu <Programm>CompilermakeKontinuierliche IntegrationComputeranimationXML
16:00
DownloadingBinder <Informatik>Singularität <Mathematik>Nabel <Mathematik>StatamakeGroßrechnerMultiplikationSoftwareLARS <Programm>GeheimnisprinzipDienst <Informatik>DateiCodeImplementierungSoftwareHausdorff-RaumLaufzeitVersion <Informatik>KonfigurationsraumEckeParametersystemNormalvektorAbstraktionsebeneLaufzeitsystemProzess <Physik>Fluss <Mathematik>Abgeschlossenheit <Mathematik>SystemplattformVerfügbarkeitGroßrechnerSoftwaretestServerQuellcodeOpen SourceGit <Software>XML
22:30
LARS <Programm>IMPACT <Programmierumgebung>PlatteOverhead <Kommunikationstechnik>App <Programm>ComputeranimationVorlesung/Konferenz
23:32
Singularität <Mathematik>LeistungsbewertungHochleistungsrechnenVirtualisierungSoftwareLARS <Programm>PlatteAutomatSoftwareDateiVersion <Informatik>Repository <Informatik>HomepageMittelungsverfahrenTotal <Mathematik>KörpererweiterungEckeInternetGeheimnisprinzipDateisystemHochleistungsrechnenXMLVorlesung/Konferenz
Transkript: Deutsch(automatisch erzeugt)
00:03
Ich fange an mit einer kurzen Einführung zu mir und meinem Institut, dann noch zur Motivation was, warum ich diese Frage stelle und verfolge, wenn was zur Container-Technologie hier eingesetzt wird und dann halt die Container-Generierung und die Benutzung davon sozusagen im Detail.
00:22
Kurz zu mir, wie gesagt, ich habe Medieninformatik studiert in Leipzig in der HTWK und bin seit 2018 am UFZ, also am Helmholtz Zentrum für Umweltforschung, Departement Umweltinformatik und bin dort als Softwareentwickler für unsere Software Open Geosys hauptsächlich zuständig, also dort für die Qualitätssicherung und die ganze Softwareentwicklungsinfrastruktur.
00:44
Und aber daneben gibt es noch ein ganz anderes Betätigungsfeld. Wir haben halt auch ein Visualisierungslabor direkt noch mit bei uns angebunden, wo ich halt auch für zuständig bin und arbeite halt auch im Bereich wissenschaftliche Visualisierung und Virtual Reality.
01:00
Ja, kurz zum UFZ, wer es nicht kennt, es ist halt ähnlich wie auch hier das GFZ, eine außeruniversitäre Forschungseinrichtung, hat circa 1000 Mitarbeiter in Leipzig, Halle und Magdeburg und ist halt großes Forschungszentrum mit ganz diversen Forschungsthemen, alles mit Fokus auf die Umwelt und dem Wohl des Menschen und der Umwelt.
01:25
Noch kurz zu unserer Software Open Geosys, ist eine Open Source Software, ist ein FEM-Simulator für gekoppelte TMC Prozesse in porösen Medien, TMC steht für Thermo-, Hydro-, mechanisch und chemische Prozesse, ist ein C++ Projekt und ja, ich habe hier einfach
01:46
die Entwicklungsziele aufgelistet, soll halt relativ flexibel und modulare Code-Architektur beinhalten, sei entwicklerfreundlich sein mit guter Dokumentation und wir legen halt auch großen Wert auf effiziente Datenschrukturen, Algorithmen, halt im Hinblick auf die Nutzung
02:02
von High Performance Computing Ressourcen und Visualisierung ist halt auch ein Thema bei uns, wir haben da auch direkte Schnittstellen, um gleich auch Ergebnisse zu visualisieren in unserem VR-Labor und angewendet wird es in verschiedenen Bereichen, Hydrologie, Hydrogeologie, Geothermie, Geotechnik und so weiter, genau da unten
02:22
ein paar Webseiten, also das erste ist der Quellcode auf GitHub, dann unsere Webseite opengeosys.org und wer sich für Visualisierung interessiert, kann auch gerne auf ufz.de gehen. So, ja, worum geht's? Es geht halt rum, komplexe wissenschaftliche Simulationssoftware
02:44
ist halt oft relativ schwierig zu erstellen, also zumindest wenn wir über kompilierte Sprachen nachdenken, es gibt halt zahlreiche Software-Konfigurationsvarianten, es gibt zahlreiche Abhängigkeiten zu Bibliotheken und Tools, die alle sozusagen miteinander
03:03
verzahnt sein müssen, damit man am Ende laufhege Simulationstool bekommt und wir wollen es halt auch auf sehr unterschiedlichen Umgebungen ausführen, es kann halt die Workstation des Wissenschaftlers sein, aber wir wollen natürlich auch auf verschiedensten HPC-Systemen in der Lage sein, dort unsere Simulationen auszuführen und ja,
03:23
auch im Sinne von der Reproduzierbarkeit kann man halt auch immer nicht so genau abschätzen, werden die Abhängigkeiten für ältere Softwareversionen auch in der Zukunft noch verfügbar sein, also gibt's die Downloads noch und so weiter. Und deswegen sind halt reproduzierbare Simulationsläufe auf verschiedenen Plattformen schwierig bis unmöglich, da halt alle diese Abhängigkeiten vorher reproduziert werden müssen und
03:46
auch verfügbar sein müssen. Und was ist der Ansatz, um das Ganze zu umgehen oder zu lösen? Wir wollen halt gerne den Code, die Abhängigkeiten, die der Code
04:00
hat und die Ausführungsumgebung als solche und eventuell sogar die Daten, die für eine Simulation wichtig sind, in eine portable Einheit kapseln mit Hilfe von Containertechnologien. Eigenständige Einheit, also einfach, dass es eine Datei ist oder ein Image, was man einfach archivieren kann und später nochmal einsetzen kann. Und ja, da gibt's im Prinzip jetzt speziell für unseren
04:25
Fall, weil wir halt auch HPC verwenden wollen, auch eine neue Containertechnologie, die wir jetzt einsetzen, Singularity, komme ich dann gleich nochmal später zu, die halt auch ermöglicht Container auf HPC Ressourcen einzusetzen. Und ganz generell sind die Container halt eine gute,
04:45
leichtgewichtige Alternative zu Computervisalisierung, also es gibt da keinen großen Performance-Overhead durch diese Teilvisalisierung, Virtualisierung, sondern teilweise kann sogar die Performance etwas steigen, weil halt mit solchen Containern die Ausführunggebung
05:03
oder die ganzen Daten, die für die Ausführung benötigt sind, an einem Ort und Stelle sind, halt in dem Container-Image, was dann halt wieder Vorteile haben kann bei I.O. So, was ist also die Zielstellung von dem Ganzen? Ich will halt meine Simulation-Software portable bereitstellen
05:21
in einem Container. Soll halt komplexe Software-Setups gekapselt werden, soll auf verschiedensten Umgebungen ausführbar sein, also Workstations und auch beliebig ein HPC-System und es soll halt auch möglichst einfach in typische wissenschaftliche Workflows integrierbar sein, also es soll für einen Benutzer einfach sein, das ganze Ding dann auch zu benutzen.
05:41
Und wir wollen natürlich sicherstellen, dass Simulationsergebnisse reproduziert werden können, wir wollen Container-Images archivierbar machen können, auch langzeitarchivierbar und vielleicht sogar kryptographisch signieren, damit man auch sicherstellen kann, dass der Container unverändert die Zeit überdauert hat.
06:02
Außerdem werden die Container mit Metadaten angereichert über die Software-Konfiguration in dem Container, sodass man noch im Nachhinein nachvollziehen kann, wie dieser Container erstellt wurde. So, noch ein paar Sätze zur Container-Technologie. Ich hatte Singularity erwähnt. Es ist ein relativ junges Projekt, auch ein Open-Source-Projekt.
06:24
Es ist kompatibel mit den Docker-Images, also man kann Docker-Images einfach als Grundlage für sein Singularity-Image nehmen. Und hier halt die Besonderheiten, es ist HPC-fähig, man kann halt gängige HPC-Scheduler verwenden und MPI und so weiter. Und auch hier noch eine Besonderheit zu Docker,
06:43
dass die Ausführung eines Singularity-Containers keine erweiterten Rechte des Benutzers braucht. Also man muss nicht root sein, um einen solchen Container auszuführen. Und das ist halt ein wichtiger Punkt für HPC-Umgebung, wo halt dem Benutzern natürlich nicht vertraut wird. Und ja, es ist einfach zu benutzen,
07:02
ermöglicht flexible Workflows, da der Container als solcher in einer Datei ist. Also man braucht jetzt nicht wie bei Docker, sondern so ein Registry, sondern man hat einfach eine Datei mit dem Container. Alles, was dazugehört, kann die auf dem USB-Stick speichern und jemand anderen geben und so weiter. Und ja, es erlaubt halt auch diese signierten,
07:20
unveränderlichen Container-Images. So, wie kann man so einen Container definieren? Das ist jetzt hier mal ein Beispiel für Singularity. Bei Docker ist das ähnlich, das ist ein bisschen ein anderes Format. Das ist jetzt hier ein ganz, ganz einfaches Beispiel. Wir fangen an oben, Bootstrap Docker heißt halt, man basiert auf einem Docker-Image,
07:40
in dem Fall einfach das Ubuntu-Basis-Image unter Post sind jetzt die Schritte drin, die halt ausgeführt werden, wenn der Container gebaut wird. Also es werden verschiedene Tools oder was auch immer installiert. Und RunScript gibt halt an, was ist der Einstiegspunkt des Containers, wenn man ihn ausführt. So, und dann hat man diese Definition und kann dann den Container bauen.
08:03
Hier vielleicht auch noch eine Besonderheit zwischen Singularity und Docker. Unter Singularity ist man halt im Container immer derjenige, der mal noch außerhalb des Containers ist. Das heißt also, wenn man den Container ausführt, ist man ein ganz normaler User. Wenn man den Container bauen will, muss man Root-User sein. Deswegen hier vorne das Sudo.
08:21
Also die Benutzerrechte werden sozusagen in den Container hereintransportiert. So, und das Ganze erzeugt nun das Container-Image, in dem Fall einfach die Datei, example.cif und kann dann halt ausgeführt werden. So, und ich hatte halt gezeigt, so sieht ein einfacher Container-Definition aus, aber im echten Beispiel aus dem wirklichen Leben
08:45
sieht es eher so aus. Es kann relativ komplex sein, wenn man halt seine Software mit all seinen Abhängigkeiten jetzt hier drin abbilden will. Und das von Hand zu schreiben macht keinen Spaß und ist halt auch relativ unflexibel. Also wenn man jetzt einfach irgendwie eine Version von der Abhängigkeit ändern will, dann muss man unter Umständen halt
09:00
Diversionsnummer an zig Stellen ändern. Und da war ich halt auf der Suche nach einer besseren Lösung dafür. Also wie kann man einen Container möglichst einfach und flexibel generieren? Und da bin ich auf ein Open-Source-Projekt von NVIDIA gestoßen. HPC Container Maker. Und das Projekt generiert Container-Definition
09:22
ausgehend von Python-Skripten. Also man hat einen Python-Skript mit all seinen Möglichkeiten, mit all seinen, ja, Klassen und Funktionen und so weiter und kann daraus halt ein Container-Image generieren oder eine Definition generieren. Es ist halt eine höhere Abstraktionsebene und ermöglicht halt
09:42
programmierbare Container-Definitionen. Das wird in dem Fall Recipes genannt, um zum Beispiel mehrere Varianten von seinem Container oder von seiner Software zu generieren, relativ leicht. Und der HPC Container Maker bietet halt eine Sammlung von sogenannten Building Blocks speziell für HPC-Anwendungen.
10:01
Also das können halt so grundlegende Dinge sein wie Compiler oder Interpreter, aber auch MPI-Implementierungen und auch bestimmte Softwarebibliotheken. Und, ja, am Ende erzeugt das Ganze halt entweder Singularity oder Docker-Definition. Also es ist völlig transparent. Man kann da einfach hin- und herschalten
10:20
zwischen den beiden. Und hat dann halt die Container-Definition. Ist halt auch unter GitHub verfügbar. Ist ein sehr interessantes Projekt. Kann ich jedem nur ans Herz legen, wer Container generiert. Ja, wie sieht so ein Python-Skript aus? Ist jetzt auch wieder der einfachste Fall. Man fängt an mit einem Base-Image.
10:40
In dem Fall auch wieder Ubuntu. Und sagt dann, okay, jetzt kommt immer mehr Schritte dazu. Und man sieht dort in der zweiten Zeile Packages ist halt ein so ein Building-Block, den halt HPC Container Maker anbietet. In dem Fall werden einfach Systempakete über den jeweiligen Systempaket-Manager installiert. Also kann halt App-Git sein
11:02
oder YUM oder was auch immer. Je nachdem, was man für ein Base-Image hat. Und ja, das Listing unten zeigt dann halt, wie man das Tool selber ausführt. Man sagt HPC Container Maker. Dann gibt man das Recipe-Skript an. Welches Format. Und das wird dann halt in eine Definitionsdatei geschrieben.
11:21
Diese Definitionsdatei baut man dann mit seinem Tool, also Singularity oder Docker. Und hat am Ende dann den Container, den man haben will. Und ich habe jetzt auf HPC Container Maker aufbauend noch ein eigenes, kleines Open-Source-Projekt gestartet. Speziell für unsere Software. Was halt darauf aufbaut
11:40
und was im gleichen Stil halt Building-Blocks für unsere Abhängigkeiten bereitstellt. Also wir haben halt verschiedene Bibliotheksabhängigkeiten. VTK zum Beispiel. Oder Patsy für die parallelen Löser. Und das habe ich halt quasi im gleichen Stil programmiert. Und habe es aber noch ein bisschen erweitert. Also es gibt Skripte für gängige Konfiguration von unserer Software.
12:02
Die halt immer mal wieder gebraucht werden. Zum Beispiel auch für unser Continuous Integration System. Was halt auch Container einsetzt, um unsere Software in einem Container zu bauen. Sodass quasi da auch die Grundlage für die Continuous Integration halt genau dieser Container Maker ist. Sodass man im Continuous Integration System
12:22
halt im Prinzip dieselbe Umgebung einsetzt. Wie jetzt auch als Benutzer oder als Entwickler. Es gibt des Weiteren die Möglichkeit zu unterscheiden, will man jetzt einen Entwicklungscontainer bauen oder einen Container, der nur die Laufzeitkomponenten enthält. Das ist jetzt kein Feature von meinem Projekt, sondern vom HPC Container Maker selber.
12:40
Und das hat halt den Vorteil, dass dann die Images viel kleiner werden. Also ein Entwicklungscontainer, wo alle Abhängigkeiten drin sind. Für unsere Software ungefähr 350 MB. Und ein Laufzeitcontainer, wo wirklich nur die Anwendung am Ende drin ist und noch die Laufzeitabhängigkeiten 90 MB. Also deutliche Ersparnis hier. Und des Weiteren habe ich noch
13:01
ein parametrisiertes kombinatorisches Skript erstellt, um halt unsere Software mit all ihren Abhängigkeiten zu bauen in verschiedensten Varianten. Und dazu einfach mal hier die möglichen Optionen. Aber wie gesagt, das lässt sich natürlich genauso auf beliebige andere Software anwenden, diese Art und Weise.
13:23
Und man kann halt jetzt hier bei den verschiedenen Optionen auch einzelne Optionen mehrfach setzen. Also man kann sagen, Format ist Singularity. Man kann sagen, wir nehmen den systemweiten Parketmanager für die Abhängigkeiten. Und wir wollen aber mehrere Container bauen mit verschiedenen OpenMPI-Implementierungen.
13:41
Dann sagt man einfach minus minus OMPI. Und dann halt Version 2.1.1 und 3.1.2 zum Beispiel. Und dann kann man sagen, welche Softwareversionen von unserer Software gebaut werden soll, gibt man in einer Schreibweise an, die ein GitHub-Repository
14:00
oder ein Branch referenziert. Kann da auch wieder mehrere angeben. Und am Ende werden halt alle Kombinationen dieser Parameter gebaut. Also es werden halt mehrere Images gebaut in einem Schritt. Und hat dann halt mehrere Images um verschiedene Konfigurationen auch dann zu testen. Man kann
14:20
gleich das Image selber bauen lassen. Es wird dann halt der jeweilige Befehl zum Bauen des Images ausgeführt. Entweder Docker oder Singularity-Bild. Man kann auch alternativ gleich die Images auf ein Docker-Image-Registry hochladen. Und was auch ein interessantes Feature ist, man kann Docker-Images nach Singularity-Images
14:42
konvertieren. Das ist speziell für die Entwicklung halt hilfreich, weil unter Docker werden ja die einzelnen Image-Layer gecached. Also das heißt halt Schritte, die schon vorher ausgeführt wurden, werden beim zweiten Bauen nicht ausgeführt. Und das beschleunigt einfach generell sehr stark
15:01
die Bauzeit der Container. Und im Prinzip mache ich es immer so. Ich baue eigentlich Docker-Images und konvertiere die am Ende in den Singularity-Image, weil das einfach schneller ist. Und dann halt die Option ein runtime-only-Image zu erstellen, was dann halt die Größe deutlich verkleinert. So, wie kann
15:21
das Ganze benutzt werden? Also Benutzung im Sinne von User, der einfach nur unsere Software ausführen will oder dafür entwickeln will, ohne irgendwas mehr wissen zu müssen. Dafür habe ich eine einfache Containergenerierung für den Nutzer mithilfe von unserem Jenkins Continuous Integration Server aufgesetzt, wo man
15:41
über eine Eingabemaske eine spezifische Software- konfiguration sich bauen lassen kann von Jenkins. Und die generierten Images werden dann auch von Jenkins zum Download angeboten. Sodass der User selber gar keine Tools und so weiter installieren muss. Und ja, Eingabemaske sieht so aus. In dem Prinzip die gleichen Parameter, wie man auch im Kommandozeileninterface
16:01
gesehen haben. Und ist halt eine sehr nutzerfreundliche Sache. Und ja, wartet dann 10 Minuten und dann ist das Ding fertig und kann es dann halt von jedem beliebigen Ort dann auch runterladen, zum Beispiel von einem HPC-System. Wir bieten mittlerweile auch Container bei unseren Software-Releases mit an.
16:21
Ganz zu den klassischen ZIP-Downloads. Sodass man auch hier die jeweils letzte Version auch als Container-Image bekommt. In dem Fall halt nur in einer ausgewählten Anzahl an Konfigurationen. Und ja, jetzt hat man halt den Container runtergeladen, den generierten.
16:40
Wie kann man den jetzt benutzen? Hier ist jetzt mal exemplarisch das Starten eines Containers gezeigt. Also wir sagen Singularity Exit, dann das Container Image. Dann kommt das Kommando, was man ausführen will. In dem Fall halt unsere Software mit Parametern. In dem Fall halt eine Projektdefinition. Also eine Simulation-Definition. Und was
17:00
das Kommando macht, das startet den Container. Es bindet das Benutzerverzeichnis im Container ein. Also alle Daten im eigenen Benutzerverzeichnis sind auch im Container verfügbar. Das ist auch ein Unterschied zu Docker, wo man das selber mit angeben muss.
17:21
Diese Verzeichnisse, die halt im Container verfügbar sein sollen, übergibt auch das aktuelle Arbeitsverzeichnis. Und führt dann am Ende die Executable, die man oben eingegangen hat, mit den gegebenen Argumenten aus. Also man sieht schon, wenn man das Singularity Exec und den Containernamen weglässt, ist es ein ganz normaler Kommandoaufruf, wie auch
17:40
auf einem nativen System. Es ist halt sehr transparent für den Benutzer. Noch ein paar mehr Beispiele zur Benutzung. Das erste haben wir schon gesehen. Einfach ausführen unsere Software mit einem Projekt. Das zweite wäre eine parallelisierte Simulation
18:00
mit OpenMPI parallelisiert. Man sagt auch hier einfach nur MPI run, dann die Anzahl der Prozesse, Singularity Exec, Container und Kommando. Also auch hier wieder völlig transparent für den User. Kein Unterschied zur normalen Ausführung. Man kann aber natürlich auch direkt im Container arbeiten, also man kann sich quasi
18:20
per Singularity Shell in den Container hereinbegeben. Man kann dort auch in den Container in den Verzeichnissen herumschauen, was gibt's da noch für Executables. Und am Ende über Exit kommt man halt wieder raus. So, man kann aber das Ganze natürlich auch benutzen, um damit zu entwickeln.
18:41
Also in dem Fall, erste oder zweite Zeile, ich hole mir unseren Source Code über Git. Bin jetzt immer noch sozusagen auf meinem Host, also nicht im Container. Leg mir dann ein Bildverzeichnis an und dann starte ich CMake, um unsere Software zu konfigurieren, allerdings dann im Container mit den gegebenen CMake-Optionen und sage dann
19:02
Make, aber auch wieder im Container. Und das baut nun OGS im Container, aber trotzdem in meinem aktuellen Arbeitsverzeichnis und kann dann auch wieder die Anwendung ausführen im Container. Und die generierten Daten sind dann aber ganz normal im Arbeitsverzeichnis, aber natürlich nur innerhalb des Containers ausführbar. So,
19:23
ja, das war's im Prinzip zum Inhalt. Noch kurz, was sind jetzt noch so die nächsten Arbeiten? Wir wollten halt unsere Software über Container auf verschiedensten HPC-Plattformen ausführbar machen. Da geht's jetzt halt noch zu überprüfen, was muss man bei MPI-Kompatibilität beachten. Also
19:42
sind verschiedene Versionen zueinander kompatibel, welche Version muss im Host sein, welche im Container. Da gibt's aber jetzt relativ viele Bewegungen mit verschiedensten, ich sag mal, Abstraktionsebenen, die diese Versionskompatibilität oder Inkompatibilität noch ein bisschen umgehen.
20:00
Und dann wollen wir natürlich auch schauen, wie sieht die Performance aus zu den nativ gestalteten Simulationen, aber wir gehen davon aus, dass es da ganz gut aussehen wird. Und ein weiterer Punkt, der interessant ist, es gibt eine Erweiterung, nennt sich Scientific File System, was man mit Docker oder Singularity nutzen kann, wo man quasi nochmal im Container
20:22
abgeschlossene Umgebungen hat. Also man kann sagen, mein Container hat nicht nur eine Anwendung, sondern verschiedene Varianten, die sind alle da drin. Und kann dann halt zur Laufzeit sagen, ich will jetzt Variante A oder Variante B haben. Sodass man einfach mehrere Konfigurationen in einen Container packen kann, was dann auch wieder
20:42
in Größenreduktion bedeutet und B halt man vielleicht noch unabhängiger von der Laufzeitumgebung des Hosts, in dem man einfach verschiedene Varianten auch im Container anbietet, die man dann zur Laufzeit abhängig von der Umgebung des Hosts halt selektiert. Also Stichwort zum Beispiel OpenMPI Implementierung
21:01
könnte halt der Container checken, was hat der Host für eine OpenMPI Version und nimmt dann halt im Container die Version, die auch diese OpenMPI Implementierung verwendet hat. Und ja, schlussendlich wollen wir natürlich die HPC Simulation in verschiedenen Umgebungen ausführen und vor allem die Ergebnisse vergleichen. Sind die ähnlich oder sogar vollständig reproduzierbar, das
21:21
muss ich noch zeigen, da habe ich schon erste Tests gemacht, sieht auch soweit ganz vielversprechend aus, weil ja der Container sozusagen immer der gleiche ist, immer die gleichen Abhängigkeiten in der gleichen Version verwendet wurden, zumindest wenn man nur eine Konfiguration angibt und dadurch sind auch die Ergebnisse sehr, sehr ähnlich. So, wir haben nochmal zusammengefasst.
21:43
Wir haben halt unser relativ komplexes Software in Containern gekapselt, mit ihren Abhängigkeiten. Wir haben zwei Open Source Projekte verwendet, ein generelles HPC Containermaker und ein spezielles für unsere Software, um die Containerdefinition zu generieren.
22:00
Wir bieten einen Dienst für unsere Nutzer an, auf unserem Jenkins Server diese Container für ihn generieren zu lassen. Und ja, der Slogan ist so, ein bisschen dann Container einmal bauen, überall ausführen, das habe ich jetzt in Anführungsstriche gesetzt, weil das muss ich noch zeigen, ob es so ist und ob es vor allen Dingen noch in zehn Jahren so ist, mit einem Container, den man heute gebaut hat. Aber es sieht zumindest relativ viel
22:20
versprechend aus, dass man damit, mit diesen Containertechnologien da einiges erschlagen kann. Hier nochmal die Links zu den zwei Open Source Projekten. Und ja, damit vielen Dank für die Aufmerksamkeit.
22:49
Inwiefern ist denn jetzt dann Overhead noch mit eingebunden, wenn ich jetzt die Application in dem Container ausführe gegenüber, ich bau sie nativ und führ sie auch dort nativ dann aus? Also Startup-Zeit
23:02
und sowas? Genau. Also Startup-Zeit ist, sag ich mal, bei einer Anwendung, die irgendwie mehrere Stunden läuft, egal, ob das jetzt nur eine oder zwei Sekunden sind. Aber jetzt hier speziell in dem zweiten Referenz, da wurde genau das untersucht. Und die sind im Prinzip zu dem Schluss gekommen, dass es keine, ja,
23:22
keine Differenz gibt. Und wie ich schon erwähnt habe, es gibt sogar Fälle, wo die Performance besser ist mit Container. Und da vermuten Sie, dass es daran liegt, dass halt der Container auf der Platte an einer Stelle ist. Also alle Daten, die zur Ausführung gebraucht werden, sind an einer Stelle. Und das halt irgendwie in den parallelen Fallsystem kann Vorteile haben. Das war also
23:42
die Erklärung von denen. Aber das haben wir jetzt selber noch nicht getestet. Aber es scheint so, als wenn es ohne Performance-Overhead möglich ist. Ja, vielen Dank für den spannenden Vortrag. Mich würde nochmal interessieren, wie, sozusagen, wie ist denn eigentlich der, hast du einen Unterschied
24:00
gemerkt jetzt auch in der Performance zwischen Docker und Singularity? Und wie weit verbreitet ist denn Singularity? Also wenn ich jetzt zu irgendeinem HBC-Cluster gehe, was ich nach Jülich rechnen möchte, ist das da installiert? Oder muss ich da die Admin selbst bezeugen? Ja, Jülich bin ich dran, dass die das mal installieren. Aber dort gibt es das noch nicht. Also ich kann jetzt selber bei uns im UFZ
24:20
rechnen auf dem HBC-Cluster und in Dresden auf dem Taurus-Cluster. Aber wenn man mal auf die Homepage von denen geht, ist da eine Liste an HBC-Sendern, die es installiert haben. Das sind schon mittlerweile sehr viele. Ist eher so in den USA, weil auch die Software von dort kommt, werden aber immer mehr und sind definitiv viel, viel mehr als
24:41
HBC-Cluster, die Docker anbieten. Also ich weiß nicht, ob jemand HBC-Cluster könnte die Docker so anbieten, dann irgendwie nur in so einer abgespeckten Variante, wo das noch mal irgendwie gekapselt wird, dass da auch ja nichts rauskommen kann oder sowas. Also ich denke mal, für HBC ist Docker keine Alternative.
25:02
Ich hätte eine Frage zum Datalsystem. Verwendet ihr ein Cluster-Datalsystem? Und wenn ja, habt ihr da Erfahrungswerte mit der Performance? Also ich frage mich, wie sich so ein Cluster-Datalsystem verhält, wenn man das mit Containern, darauf zugreift? Also ja, es wird auch ein Cluster-Datalsystem verwendet, aber
25:21
also kann ich dir nicht sagen, wie da die Performance ist. Angeblich soll es besser sein, weil es halt alles an einer Stelle liegt. Aber das ist jetzt auch nur das, was ich jetzt hier aus der Literatur habe. Wie stark bin ich denn abhängig von der Software
25:42
eigentlich? Also wenn jetzt mal irgendwann Docker oder Singularity keine Lust mehr haben und dicht machen oder verkauft werden an gewisse Firmen, was mache ich dann? Also bei Singularity habe ich mich zumindest ein bisschen eingelesen. Also da gibt es auch Untersuchungen dazu, sozusagen wie alt
26:02
das System im Container sein kann, damit es noch mit der aktuellen Version läuft. Und das geht bei Singularity sehr, sehr weit zurück. Also es scheint sehr lange abwärtskompatibel zu sein. Also ich glaube, es ist nie aufwärtskompatibel, aber abwärtskompatibel. Also das heißt, mit einer neuen Singularity- Version kann man auch immer die alten
26:20
Container ausführen. Da ist mir zumindest jetzt nichts bekannt, dass das bisher ein Problem darstellt. Aber klar, das ist natürlich immer die Frage bei so was. Wie es dann in Zukunft weitergeht. Hier vorne war noch eine Frage. Vielen Dank.
26:41
Ist das jetzt, was du vorgestellt hast, eher eine Lösung nur für High-Performance-Computing oder würdest du es auch anderen Leuten empfehlen? Und wenn du es anderen Leuten empfehlen würdest, also ich persönlich nutze eigentlich eher so Repo2Docker. Ich weiß nicht, ob du das kennst. Also Repo2Docker, das was auch hinter MyBinder steht.
27:01
Und das ist halt sehr, sehr einfach zu nutzen. Da habe ich ein File, das ich in mein Repository reingeben muss und das baut mir dann sozusagen mein Docker- Container. Genau. Ja, also ich sage mal, ganz generell würde ich halt diese Art und Weise der Container-Definition, also eine programmatische Art und Weise der Container-Definition sehr empfehlen, weil es ist halt einfach vereinfacht Varianten zu erstellen.
27:23
Und ob dann Docker oder Singularity, also das muss dann jeder selber wissen. Ich finde halt bei Singularity schön, dass es halt einfach eine Datei ist und nicht irgendwie so ein Registry, die irgendwo im Hintergrund läuft, ist. Macht es halt ein bisschen einfacher damit zu interagieren. Und halt die
27:42
Transparenz sozusagen im Container, außerhalb vom Container ist halt bei Singularity besser oder, finde ich, benutzerfreundlicher. Es wird halt automatisches Home Directory drin gemeldet, das Working Director wird übergeben. Du kriegst im Prinzip gar nicht mit, dass du irgendwas im Container machst. Das finde ich jetzt ein bisschen benutzerfreundlicher. Aber ja, das ist dann
28:00
jedem selbst überlassen. Darf ich noch einmal auf Englisch eine Frage stellen? I was not so sure if I understood about the parallelization via MPI. Can you still use in the system like multiple jobs spread across multiple hosts and parallelize?
28:22
So it's also transparent in that regard. So you just use the regular HPC system scheduler system. So if you have SLURM, then you use SRUN and then Singularity and your executable and so on. So this works just like a normal executable.
28:51
Also about MPI. I was wondering if you say you can do that. I experience that sometimes if you have parallel systems, depending on which thread
29:00
can start when, you can achieve different results. Do you encounter something like that? No. It's a numeric problem. It's just like if you work parallel and then one thread gets earlier and then you have a numeric number. So you don't have exact representation of numbers
29:20
and that can lead to some build up errors and different results. I guess this is then implementation specific to the program. In OpenMPI all processes start at the same time. They start at the same time?
29:40
And they always start at the same time if you parallelize? This is the job of the scheduler. So it reserves the node you want and then they start all at the same time. And then at every time step there is a synchronization between the nodes. That's interesting. So then it's MPI because I did parallelization on a
30:00
normal system. With OpenMPI? OpenMPI for example. Then MPI starts at the same moment and then you don't have that problem.
Empfehlungen
Serie mit 7 Medien