OpenSimulator und Docker

[Manfred Aabye]

# OpenSimulator und Docker

Docker ist ein beliebtes Werkzeug zur Containerisierung von Anwendungen, einschließlich OpenSimulator. Es bietet viele Vorteile, wie zum Beispiel Konsistenz, Portabilität und einfache Verwaltung. Doch wie verhält es sich mit der Leistung? Ein treffender Vergleich könnte helfen, dies zu veranschaulichen.

Stellen Sie sich vor, Sie haben ein Auto, das über ein Abschleppseil gezogen wird. Dieses Auto repräsentiert die Docker-Containerisierung, während das Fahrzeug, das das Auto zieht, das zugrunde liegende Serverbetriebssystem darstellt. Das Auto kann niemals schneller fahren als das Fahrzeug, das es zieht. Ebenso kann OpenSimulator, das in einem Docker-Container ausgeführt wird, niemals schneller sein als eine direkt auf dem Server installierte und optimierte Version.

**Vorteile von Docker:**

- **Konsistenz:** Docker sorgt dafür, dass OpenSimulator in einer standardisierten Umgebung läuft, was die Reproduzierbarkeit und Skalierbarkeit erleichtert.
- **Portabilität:** Docker-Container können leicht zwischen verschiedenen Umgebungen und Servern verschoben werden.
- **Einfachere Verwaltung:** Mit Docker lassen sich Anwendungen einfacher starten, stoppen und aktualisieren.

**Nachteile von Docker:**

- **Leistungsaufwand:** Docker fügt eine zusätzliche Abstraktionsschicht hinzu, was zu einer geringeren Leistung im Vergleich zur nativen Ausführung führen kann.
- **Komplexität:** Während Docker viele Aufgaben vereinfacht, kann die Einrichtung und Verwaltung von Docker-Containern eine zusätzliche Komplexitätsebene hinzufügen.

**Fazit:**

Wenn es darum geht, die maximale Leistung aus OpenSimulator herauszuholen, ist eine direkte Installation auf einem Server mit gezielter Optimierung in der Regel die beste Wahl. Docker bietet jedoch unschätzbare Vorteile für Entwicklungsumgebungen, Tests und die einfache Bereitstellung, insbesondere wenn Konsistenz und Portabilität wichtiger sind als maximale Leistung.

Dieser Vergleich zeigt, dass während Docker eine hervorragende Wahl für viele Anwendungsfälle ist, es Situationen gibt, in denen eine direkt installierte und optimierte Version die bessere Wahl ist, wenn Leistung das Hauptkriterium ist. Jede Millisekunde zählt, in einer Umgebung mit vielen Benutzern und Regionen. Eine optimierte Direktinstallation bietet die beste Leistung.

[Bogus Curry]

Kann ich teilweise zustimmen, zum einen die komplexität, da docker nicht einfach zu verstehen ist. Anderseits finde ich docker intressant für testumgebungen. In diese könnte man verschiedene scenerien testen.

Akira schreibt ja, sie nimmt docker für ihre projekte und bevorzugt auch docker eher als die native art. Das gibt mir schon zu denken

Wegen plattform, mich berwirt das bat hinter den shell scripts, weil ich kenne kein linux wo man bat scrpts ausführen kann.

[nihal]

hallo Bogus
für testkrams wäre meine erste wahl proxmox https://distrowatch.com/table.php?distribution=proxmox auf https://www.youtube.com/@SemperVideo/videos gibt es viele anleitungen sowohl zu proxmox als auch zu docker, eine weitere quelle ist https://www.youtube.com/@tuxwiz/videos

[Bogus Curry]

hallo Bogus
für testkrams wäre meine erste wahl proxmox https://distrowatch.com/table.php?distribution=proxmox auf https://www.youtube.com/@SemperVideo/videos gibt es viele anleitungen sowohl zu proxmox als auch zu docker, eine weitere quelle ist https://www.youtube.com/@tuxwiz/videos

Weiss nicht, da hab ich keine Erfahrung mit.

[Pius Noel]

Mit Proxmox konnte ich nie richtig warm werden. Als ich noch einen grösseren Server hatte, war LXC/LXD meine erste Wahl. Die laufende Entwicklung unter Canonical hat mich dann immer mehr davon abgebracht. Hätte ich noch Bedarf, dann wäre ich heute mit Incus wieder dabei.

Für meine Basteleien und Tests verwende ich heute vorwiegend kleine ARM Instanzen in der Hetzner Cloud. Ansonsten habe ich noch einen Raspberry Pi 4 mit 8 GB RAM auf dem auch eine Region im OSGrid läuft. Wie auch immer, Docker gehört bei mir einfach dazu.

[Mareta Dagostino]

Um mehrere Container auf dem selben Rechner (Host) zu betreiben, genügt mir Distrobox. Die großen Frameworks sind mir den zusätzlichen Administrationsaufwand nicht wert. Anders wäre es, müsste ich die Container auf mehrere physikalische Rechner verteilen, wie es zum Beispiel ein Rechenzentrum macht. Distrobox verwaltet alle Container in einer Liste, so dass weder Hierarchien noch verschiedene Hostrechner berücksichtigt werden können. Es wird einfach mit "list" eine alphabetische Liste der existierenden Container angezeigt, und ob sie gerade laufen oder nicht.

Momentan läuft zum Beispiel der Cool VL Viewer in einem Distrobox-Container, zusammen mit Vivox-Voice über Wine, so dass ich meinen Host nicht mit der Vielzahl von 32-Bit-Libraries "verseuchen" musste.

Distrobox läuft so ziemlich überall, sogar auf Windows in deren eingebautem Linux-Subsystem. Für Container stehen alle bekannteren und auch weniger bekannte Linux-Distributionen zur Verfügung.

Kompatibilitätsliste: https://github.com/89luca89/distrobox/bl...ibility.md

Standardmäßig benutzt Distrobox Podman-Container, aber Docker-Container oder Lilipod-Container können alternativ ebenfalls verwendet werden.

EDIT: Bei kommerzieller Nutzung kostet Docker 11$ pro Monat Abogebühr, oder mit Jahresabo 2$ günstiger. Leider die übliche Methode wie auch beim Visual Studio, erst Studierende "anfixen" und dann hoffen, dass sie später im Beruf die gewohnten Tools weiterbenutzen wollen.

[Akira]

Huhu,

Aktuell betreue ich etwa 10 Server und auf jedem etwa 10 Sims. Auf den Sims ist meist auch nur eine Region installiert. Und mit Regionen > 256 kann ich mich nicht anfreunden. Die Sims laufen nativ auf Mono resp. Dotnet unter Debian. Wie in einem anderen Thread von Manfred schon erwähnt, macht es keinen Sinn auf einem dedizierten OpenSim-Server das ganze unter Docker laufen zu lassen. Mit dem Risiko, dass ein amok laufender Sim den ganzen Server ins elend zieht, kann ich leben. Finde es aber eigentlich ganz gut, wenn die Sims gegenseitig um Ressourcen buhlen. Wenn wir eine Party haben, soll der party-sim auch alles kriegen, was er braucht, da möcht ich keinen container der mich evtl. einschränkt. Vertikales Autoscaling geht auch in Kubernetes Umgebungen nicht automatisch ohne Neustart und eine OpenSim-Region horizontal auf mehrere Sims zu skalieren, interessanter Gedanke, benötigt aber, denke ich, niemand wirklich, dafür ist schlicht zu wenig los in den Grids.

In einem nochmals anderen Thread habe ich ja erwähnt, dass ich noch ein Problem mit Hypergrid habe, wenn der Sim in einem Docker Container läuft. Habe mich da nicht weiter darum gekümmert, weil ich auch nicht gedenke, das zu ändern. Dass auf den entsprechenden Maschinen nun dotnet und mono gleichzeitig laufen, ist halt so. Wenn mal alles umgestellt ist, kann ich mono immer noch wegputzen.

Anders sieht es mit nicht-opensim Sachen aus. Forum, WebServices oder wenn ich mich an das WebRtc machen würd, tät nie nativ auf einem OpenSim Server installieren. Samiras Radio ist was anderes, aber das ist dermassen anspruchslos, braucht je nach Anzahl Zuhörer einfach Bandbreite, hab da auch nicht aktiv nach einer container Lösung gesucht. Als ich das 2014 installiert habe, war Docker noch so frisch, dass ich nichts davon wusste ( März 2013 war der initiale Release ), und seither habe ich ohnehin nichts an der Shoutcast-Installation geändert.

Auf meinem Laborrechner möchte ich nicht leben ohne Container. Datenbank, PhpGridserver, Robust, Mono, das Zeug habe ich nativ gar nicht installiert. Dotnet 8 hab ich nativ drauf, weil ich das auch nur für OpenSim benötige zum kompilieren der Sources, Rider ( die IDE ) ist selbstverständlich ein flatpak, flatpak dotnet 8 hab ich noch keines gefunden.

Distrobox ist auch super interessant. Ist natürlich schon schick eine Distrobox für Mono, eine für Dotnet 8, eine für Dotnet 9 etc. zu haben, je nachdem was gerade ansteht.

Liebe Grüsse
Akira

[Akira]

Huhu,

Habe gerade Distrobox eingebaut. Bin ja wie gesagt unter CachyOS (Archlinux fork) und benötigte eine Software zu der es nur *.deb oder *.rpm gab. Kurz ne Fedora Box aufgesetzt und das *.rpm installiert -> funzt! Goil!

Liebe Grüsse
Akira