I gave the lecture in German. But I translated the slides into English:
Kielux 2021 Docker for EGroupware Handout EN.pdf (1.6 MB)
I have also translated the questions asked in the lecture in the slides. Sorry for the German screenshots…
Hallo Zusammen,
wie angekündigt:
habe ich mit Ralf einen Vortrag gehalten:
Docker für EGroupware
Oder:
Warum wir Docker als Basis für EGroupware-Installationen verwenden
Die Folien und das Vortragsvideo stehen nun bereit.
Die Fragen aus dem Vortrag habe ich noch einmal schriftlich und ausführlich in den Folien und am Ende dieses Beitrag beantwortet.
Kielux 2021 Docker für EGroupware Handout DE.pdf (1.6 MB)
Das Vortragsvideo wird angeboten in unserem YouTube-Channel:
Als Link:
https://www.youtube.com/watch?v=_5lw5o-Ne-o
Viele Grüße
Stefan
EGroupware Community Manager
Fragen/Antworten
[15:31] Uli : wie sehen die hardware requirements aus für einen V-Server ?
[15:31] Uli : standard installation
[15:31] Ralf [EGroupware] : Das hängt stark von der gleichzeitigen Anzahl Benutzer ab
[15:31] Uli : 10 user
[15:32] Uli : ok danke
Die Anforderungen beginnen bei 2GB RAM/1CPU/10GB Platte für eine EGroupware mit installierten Collabora Online.
Der Ressourcenbedarf während der Laufzeit hängt immer davon ab, was die Benutzer tun, wie viele gleichzeitig und wie intensiv sie in EGroupware arbeiten.
Es können weitere Dienste wie z. B. Guacamole, Rocket.Chat oder ein E-Mail-Server nachinstalliert/betrieben werden.
Insbesondere der E-Mail-Server schlägt sich natürlich auf den Festplattenbedarf nieder. Collabora Online benötigt insbesondere RAM für die geöffneten Dateien.
Man sollte sich bei der Auswahl des Installationssystems die Möglichkeit frei halten die Ressourcen flexibel anpassen zu können.
Wir wollen im Forum einen Artikel erstellen/veröffentlichen, in dem wir versuchen die Ressourcenanforderung besser aufzuschlüsseln und ein paar Beispiel nennen.
Weiteres Beispiel:
70 gleichzeitige Benutzer EGroupware, hauptsächlich E-Mail, Kalender, Remote-RDP für HomeOffice und Dateiablage IT-Abteilung, Mail-Server getrennt
Konfiguriert:
4 CPU / 6 GB RAM / 37 GB Storage
System verwendet:
~ 25% CPU (1 CPU)
~ 50% RAM (3 GB RAM)
~ 32 GB Storage (einige Files)
[15:48] Niclas : Also muss man Euer Docker-Setup letzendlich in einer VM kapseln, sonst kommt man in die Hölle? ^^
[15:49] Stefan [EGroupware.org] : Die Installtion möchte ein eigenes System. Die Hölle hätte ich, wenn nativ installiere.
Kurze Antwort:
Ja, die „Standard-Installation“ sollte auf eine eigene System (VM, Bare Metal, …) vorgenommen werden.
Längere Antwort:
Die „Standard-Installation“ ist dafür gedacht und ermöglicht praktisch jedem, eine EGroupware mit all seinen Teilen zu installieren/betreiben.
Die Installation erwarten ein System für sich alleine.
Die Gründe dafür sind im Vortrag ausgiebig dargelegt.
Keinesfalls sollte man so über eine bestehende Installation „drüber installieren“. Es ist unbedingt angeraten die Release-Notes zu lesen und Backups anzulegen!
Mit dem nötigen Know-How können die angebotenen Container überall eingesetzt werden, in denen Docker zur Verfügung steht.
Eine Installation auf einem UCS-Server ist eine Alternative. In dem Fall werden ebenfalls die 3 nötigen Container installiert/betrieben.
Professioneller Support für den Betrieb in der eigenen Docker-Umgebung ist (in gewissen Fällen) auch über unseren Support möglich:
https://www.egroupware.org/de/technischer-support
[15:48] Niclas : Was, wenn ich schon 400 Container laufen habe und Eure dazu nehmen möchte? ^^
[15:49] Stefan [EGroupware.org] : Die Container kannst du natürlich auch in eine bestehende Installation mit Know-How integrieren.
Wie im Vortrag/in den Folien beschrieben, besteht EGroupware aus 3 Containern welche integriert werden müssen.
Die nötigen Informationen finden sich in:
[15:49] Niclas : Könnt Ihr nochmal was zu den Konsequenzen eines Paket-Updates sagen bzw. was bei einem dist-upgrade passiert? Damm muss man sich doch sicher durch die inzwischen angepasste Konfiguration wurschteln, oder? Wo finde ich die…?
[15:50] Niclas : (Frage füre einen Kumpel, der viel mit Debian macht. hust)
[15:51] Stefan [EGroupware.org] : Die angepasste Installation schreibst du in deine override.yml
Ein Paket-Update, welches Konfigurationsdateien ändert zeigt erst einmal während der Installation an dass eine Konfigurationsdatei geändert wird. Man kann sich dann die Änderungen anzeigen lassen, entscheiden bzw. nacharbeiten. Das ist erst einmal nichts anderes als bei anderen Paketen (postfix, …) auch.
Letztendlich ist es wie bei jeden Paketupdate (eines Server-Dienstes): Man muss aufpassen was man macht und eine Backup ist Pflicht.
Eigene Konfigurationen sollten in die *.override.yml geschrieben werden. Diese werden von einem Update nicht ausgetauscht.
[15:50] Wolle : Kann ich egroupware mit einem bestehenden Reverse-Proxy im Subdirectory laufen lassen?
Ja. Genau da machen wir mit
/egroupware
/rocketchat
/…
Siehe auch die Grafik oben in de Folien.
In einer Standard-Installation wird ebenfalls ein Reverse-Proxy eingerichtet der die Dienste als Subdirectory anbietet.
So ist es dann auch möglich z. B. Rocket.Chat im Webbrowser oder von Mobile-Clients direkt anzusprechen. Neben der Integration als iFrame in EGroupware.
[15:51] H. Rohde : Watchtower schön & gut - wie stellt ihr sicher, daß die in eurem eigenen Containern verwendeten Dienste & Bibliotheken in den von euch verwendeten Versionen keine Sicherheitslücken enthalten?
Die verwendeten Container basieren entweder auf etablierten Linux Distributionen (Ubuntu, Alpine) oder auf offizielle Images von Docker Hub bzw. verwenden diese direkt.
Unsere eigenen Images werden auf quay.io laufend auf neue Security Vulnarabilites gescanned und wir sind für unsere kritischen Componenten (PHP, Nginx, Dovecot) auf deren Mailinglisten subscribed.
GitHub prüft ebenfalls Abhängigkeiten und informiert uns:
Sollten Sicherheitsupdates anstehen, bewerten wir diese und stellen turnusmäßig (~10-12 Updates pro Jahr) oder sofort neue Images bereit.
Somit reagieren wir zeitnah auf bekannte Schwachstellen und liefern die Updates (hoffentlich) per Autoupdate aus.
Wir informieren ausdrücklich im Forum und unseren Social Media-Kanälen wenn ein Security-Update ansteht:
Nach unserer Einschätzung hat das die Sicherheitssituation der EGroupware Installationen dadurch in den letzten Jahren deutlich verbessert, weil viel mehr Installationen auf einem aktuellen Stand sind.
Darüber hinaus sind die Container nur über den Reverse Proxy auf dem Host zu erreichen. Dieser terminiert die TLS Verbindung und dient auch als Applikation Level Firewall für HTTP.
Ob man das als Vor- oder Nachteil sieht hängt sicher davon ab, ob man mehr Vertrauen hat das der eigene Admin alle Updates automatisiert hat (oder zeitnah durchführt), oder man darauf vertraut das wir die Container bei Sicherheitsproblemen zeitnah neu bauen. Wir waren da in der Vergangenheit immer sehr schnell, sprich sobald PHP Updates verfügbar waren, wurden die Container neu gebaut.
Für den „unbedarften“ Betreiber ist unsere Standard-Lösung sicherlich besser. Alle mit Know-How können natürlich EGroupware in allen erdenklichen Konstellation betreiben.
Wenn jemand sehr paranoid ist, kann er auch automatische Sicherheitsupdates in unseren Containern aktivieren, bzw. manuell durchführen:
docker exec -it egroupware bash -c “apt update && apt upgrade”
Beispiel für Security Update:
Den Collabora Online-Container „bauen“ wir selber. Dies ist so von Collabora vorgesehen.
Werden Updates von Collabora veröffentlicht, bekommen wir zeitnah, meist Tage vorher, Benachrichtigung. Wir bauen dann den Container als latest und testen selber auf Funktion. Danach geben wir den Container als stable frei und updaten auch unser Hosting.
Dies alles geschieht in der Regel innerhalb weniger Tage. Wenn Sicherheitsupdates anstehen auch mit einer noch höheren Priorität.
Den Rocket.Chat-Container stellen wir auf
https://quay.io/repository/egroupware/rocket.chat?tag=latest&tab=tags
Jeweils in einer von uns getesteten Version zur Verfügung.
Die Update-Frequenz von Rocket.Chat ist derart hoch, dass es in der Vergangenheit das ein oder andere Problem gegeben hat. Nun geben wir jeweils wenige notwendige Versionen frei.
Rocket.Chat soll künftig auch als LTS-Version bereit gestellt werden.
Weitere Container beziehen wir „direkt“:
Nginx Webserver für EGroupware
Wir verwenden den „Standard“-Container nginx:stable-alpine:
https://hub.docker.com/layers/nginx/library/nginx/stable-alpine/images/sha256-1a14d20c4f6513f0a01eba9ba76d17281275e88bcf465b8f634b78e4e9737fee?context=explore
Somit aktualisiert sich der Container, wenn NGINX einen neuen stable-Container zur Verfügung stellt.
Gleiches gilt für die weiteren Anwendungs-Container.
Der verwendete Reverse-Proxy auf dem Host wird über die Paketverwaltung des Host aktualisiert. Hier ist der Admin des Systems gefragt und verantwortlich.
[15:51] Niclas : An Wolles frage anschließend: Liefert das System https-Links, auch wenn es hinter einem Reverse-Proxy per http angebunden ist? 
[15:54] Niclas : Nice
Kurze Antwort:
Ja.
