Hallo!

Wir evaluieren jetzt nach grob einem Jahr erneut die Einführung von egroupware. Soeben wollten wir eine Test-Installation auf dem Ziel-Server vornehmen.
Nach einigen Stunden Spielerei mit docker lande ich aber immer wieder bei der Aussage “bitte über linux package installieren”.

Die dokumentierten docker compose setups funktionieren leider nicht out of the box.
Vorwiegend, weil nicht dokumentiert ist, dass man den swoole source selbst ablegen muss und weil der collabora-key container ständig crashed wegen fehlender config. (die angeblich über das package am host erzeugt würde)

Wie ich in einem anderen Thread lesen konnte, wird ein quasi ein blanker Debian host vorausgesetzt, damit das irgendwie sauber läuft. Das ist zum heutigen Stand der Technik irgendwie sehr schade.

Wir haben ein ziemlich gut aufgesetztes System, wo schon diverse Dienste (Jira, gitlab, etc) in docker laufen, hinter einem Apache als reverse-proxy (SSL termination). Problemlos, seit Jahren.
Es wäre wirklich wirklich schön, wenn das auch mit egroupware möglich wäre. Also ein paar container ergänzen, ein paar volumes mounten und fertig. (Dann hat man z.B. die Möglichkeit den rocket.chat zu entfernen, wenn man den gar nicht braucht.)

Gibt es Pläne, das in naher Zukunft mal auf ein reines Docker-setup umzustellen und von diesen rpm-packages wegzukommen?

Hallo Ralf,

danke für deine Rückmeldung.

Ich erlaube mir ein paar Anmerkungen zu machen:

Das wäre eigentlich der Job von Entry-Scripts im container.
Die fixe Definition der volumes mit den Pfaden im compose-file bedingt halt leider auch, dass ich alle Ordner vorher anlegen muss. Ist aber okay, wenn das dokumentiert ist.

Reverse-Proxy auf Host einrichten? Warum das? Ihr hab ja schon nginx als container.
(Wenn es ein reiner reverse-proxy sein soll, dann ist “traefik” wohl sogar das bessere image)

Wir verwenden auf unserem Server einen Apache als reverse-proxy nativ, weil es noch ein paar native Applikationen gibt, wo das so einfacher ist, aber für reine Docker-Apps ist das eigentlich sogar komplizierter.

Das bezieht sich auf das compose-file?
Das ist natürlich ein legitimer Punkt, aber im Grunde sollte in einem Docker-basierten Setup das so ziemlich die einzige Datei am Host sein, die ich angreifen muss.
Ihr könntet ja für alle, die den Aufwand scheuen hier ein paar Zeilen bei einem update zu ändern, weiterhin die Pakete anbieten. Aber für alle, denen das kein Problem ist (gibt sichtlich mehrere Personen, wie ich hier so im Forum lese, die gerne ohne die Pakete auskommen würden), die können das selbst anpassen.

Was bestätigt das?
Meine Aussage war, dass das compose-file setup leider nicht vollständig ist/dokumentiert ist. Daraus folgen die Probleme.
Ich steuere gerne Dokumentations-Verbesserungen bei, wenn ich den Soll-Zustand wüsste. z.B.
Wie sollen swoole sources bezogen werden? Github release zip-download und entpacken?

Definitiv. Aber “know your tools”, und als Server-Admin ist das eigentlich Pflicht.

Aber wie oben geschrieben, es gibt mittlerweile genug Leute die dieses Wissen haben und die Menge der Nacharbeiten halten sich sehr in Grenzen, wenn nicht gerade neue Services dazukommen.
Wir möchten unsere System unter Kontrolle haben und das wird halt ungleich schwerer, wenn ein Tool/Paket selbst anfängt compose-files zu erzeugen und damit z.B. die exposed ports festlegt.

Ich betrachte das so: Eine container-isierte Anwendung sollte mit einem compose-file einwandfrei laufen. Wenn jemand damit Probleme hat, ist ein Paket hilfreich.

Aktuell ist aber überall zu lesen, dass nur die Paket-Methode empfohlen wird. Bei der manuellen compose-variante steht zum Teil sogar “fehlende Features”. Das ist wirklich bitter.

Wenn es grundsätzlich erwünscht ist, können wir gerne behilflich sein, die Dinge mehr in die Container zu bekommen. Aber wir investieren natürlich keine Resourcen, wenn das ohnehin nicht das Ziel ist.

Was spricht dagegen den reverse proxy nicht einfach als container laufen zu lassen? letsencrypt geht ja zB mit jwilder/nginx-proxy easy und ich brauche gar nichts mehr am host.

Hallo @itwo,

ja, wir setzen EGW nun ein. Wir haben aber unsere Pläne bezüglich Hosting nochmal geändert und haben das nicht, wie ursprünglich angedacht, in einen bestehenden Server integriert, sondern EGW hier einen eigenen vhost spendiert. (Hetzern CPX11 mit Debian 12)

Shared-Hosting ist hier tatsächlich etwas Fehl am Platz, da bin ich ganz bei dir.

Das in einer generellen Docker-Umgebung laufen zu lassen, egal ob jetzt NAS - sofern das docker-compose kann wie z.B. Synology DSM 7.2 - oder ein bestehender Server ist, sehe ich aber als sehr legitimen Wunsch an. Dazu müsste sich vielleicht das eine oder andere im compose-setup (bzw. init Prozess) noch vereinfachen, dann wirft das vielleicht weniger Fragen auf.