MRBS dockerized (speziell für linuxmuster)

Server Container
1

Hallo,

ich habe mal eine kleine Appliance für MRBS gebaut, speziell für linuxmuster.net 6.2 die funktioniert schon ganz gut und kann dort getestet werden:

https://hub.docker.com/r/linuxmuster/mrbs

Eckdaten:

  • Aktuellstes MRBS
  • Datenbanken werden automatisch beim Containerstart konfiguriert
  • Funktioniert mit der lmn62, ldap auth
  • Kann dort auch Gruppenzugriff abbilden (mit meheren Gruppen, die frei konfigurierbar sind…)
  • Kann einfach mehrere MRBS Instanzen managen/starten (Räume/Klasenarbeiten etc.)
  • Könnte gut auf demselben Dockerhost wie der Mailserver laufen, wenn man die Frage des Reverse Proxys klärt.

Da bin ich von den vollcontainerisierten Varianten wie von @Tobias beschrieben und getestet nicht so überzeugt, die für jeden Mist nen Container brauchen (Letsencrypt, httpd und was weiss ich noch alles…).
Meine Idee wäre eher schlank und KISS:

  • Der Dockerhost bekommt einen eigenen apachen und dehydrated, dann kann man bequem alle Zertifikate für alle Containerdinste einfach dort holen.
  • Die Container binden sich an 127.0.0.1 ohne SSL, der Apache macht dann den Reverse-Proxy von aussen mit SSL.

Das erscheint mir für die Anwendung, die ich erwarte vollkommen ausreichend, zumal ich nicht in die Verlegenheit kommen werde, meine Container orchestriert über die Server schieben zu wollen. Gibt eben keinen Vollautomatismus mehr, man muss “von Hand” dafür sorgen, dass ein Vhost auch ein SSL Zertifikat bekommt.

Der MRBS Container wird noch einen Befehl zur Datensicherung bekommen, so dass man per Cronjob die Datenbanken aus dem Container rausdumpen kann, dafür ist das Verzeichnis dbdumps gedacht.

VG

Frank

P.S.: Wer sich an diesem Beispiel nochmal in den Containerbau vertiefen mag: Die Quellen sind dort: https://github.com/ironiemix/linuxmuster-docker-mrbs

2

Hallo Frank,

paßt ja wie die Faust aufs Auge: ich bereite gerade eine FoBi zu docker
vor: und da wollte ich auch mrbs rein nehmen :slight_smile:

Der Container läuft: jetzt muß ich nur noch die Anbindung an die AD der
lmn7 hinbekommen.

Generell hab ich da aber noch ein Problem mit der Position des
Dockerhosts in der lmn7, weil er (noch?) in grün steht.

Vielen Dank für deine Arbeit.

LG

Holger

3

Hallo Holger,

Das sollte ohne Änderung am Image in der Konfiguration gehen. Für die 6.2 verwende ich ja eine angepasste Auth Methode, nämlich ‚linuxmuster62‘, die dafür nötige Datei baue ich beim Bau des Containers in MRBS ein. Mit einem normalen AD sollte das einfach gehen, indem du die Auth Methode in der ./config/whatever.php.inc auf ldap umstellst und das dann normal konfigurierst, dort hast du ja auch das group-member Overlay zur Auswahl der erlaubten Gruppen, das bei der 6.2 fehlt.

VG

Frank

4

Hallo,

Das ist nicht das einzige Problem daran. IMHO macht „der Dockerhost“ so einfach überhaupt gar keinen Sinn. Auch dass z.B. das Mailserver-Paket da in der ganzen Host Konfiguration rumfroscht will bei Docker ja keiner haben.

Ich denke, die Docker-Apps sollten am Ende auch nicht als Debian Pakete kommen, sondern per git clone und git pull aus Github.

Außerdem sollten die deutlicher gekapselt sein, selbst wenn man wie beim Mailserver eine Autokonfiguration haben will, sollten die Templates und Skripte alle in z.B. /srv/docker/meine-app sein und nicht im System verteilt.

Es wäre auch besser, einfach beliebig einen Dockerhost erzeugen zu können, ich habe dafür ein ansible Playbook, das macht aus einem 18.04 oder einem Stretch mit einem einzigen Befehl ein (für mich) dockerfähiges Gerät, inklusive Letsencrypt und apache (s.o. meine Gedanken zum reverse Proxy). Das kann ich dir gern auch zukommen lassen.

Der Host könnte dann auch in dem Netz sein, wo er hingehört und man könnte auch 3 oder 4 davon haben, je nachdem was für Dienste man in welchem Segment haben will. Und sogar externe Server würden sich mit der gleichen Doku integrieren lassen.

Der Ablauf wäre dann:

  • Ich will appXYZ in NetzsegmentS
  • Mach ich mir nen Dockerhost in NetzsegmentS (oder ich hab schon einen dort…)
  • git clone https://github.com/.../appXYZ nach /srv/docker
  • Dort kommt vielleicht ein Skript mit, das die Configs macht, oder halt eine Aneitung wie man appXYZ in Betrieb nimmt.

Der Dockerhost könnte jetzt wenn man will z.B. noch ein systemd Skript haben, das in /srv/docker/*/control Dinge abarbeitet. Man könnte auch eine Möglichkeit vorsehen, dass der Dockerhost vom LMN7 Server eine .ini Datei mit Konfiguratuonsparametern bekommt und die an einer Stelle ablegen, dann könnten die appXYZ Apps diese zur Autoconfig Nutzen oder halt nicht.

LG

Frank

5

Hallo Frank,

Das ist nicht das einzige Problem daran. IMHO macht “der Dockerhost” so
einfach überhaupt gar keinen Sinn. Auch dass z.B. das Mailserver-Paket
da in der ganzen Host Konfiguration rumfroscht will bei Docker ja keiner
haben.

rumfroscht :slight_smile:
Geiles Wort: kannte ich noch gar nicht.
Da gebe ich dir recht: mir wäre es auch lieber, wenn die alle gesammelt
in /srv/docker/ wären.

Ich denke, die Docker-Apps sollten am Ende auch nicht als Debian Pakete
kommen, sondern per git clone und git pull aus Github.

ich kann die Verwendung von Debianpaketen verstehen: es ist für die
Nutzer viel einfacher ein Debianpaket zu installieren (und wir können
nach Installation noch scripte laufen lassen) als wenn sie git verwenden
sollen, wo wieder nur ein kleiner Prozentsatz versteht was das ist und
was das soll.
Nicht dass das viele bei Debianpaketen verstehen: aber die Anwendung
sind sie gewohnt.
Ich mach bisher keins von beiden, sondern erstelle nur das Verzeichnis
/srv/docker/appname, lege eine docker-compose.yml Datei rein,
konfiguriere sie und starte sie dann.

Außerdem sollten die deutlicher gekapselt sein, selbst wenn man wie beim
Mailserver eine Autokonfiguration haben will, sollten die Templates und
Skripte alle in z.B. /srv/docker/meine-app sein und nicht im System
verteilt.

ja: das sehe ich auch so.

Es wäre auch besser, einfach beliebig einen Dockerhost erzeugen zu
können, ich habe dafür ein ansible Playbook, das macht aus einem 18.04
oder einem Stretch mit einem einzigen Befehl ein (für mich)
dockerfähiges Gerät, inklusive Letsencrypt und apache (s.o. meine
Gedanken zum reverse Proxy). Das kann ich dir gern auch zukommen lassen.

dass wir einen dediziert dafür vorgesehenen Host haben, finde ich auch
nicht schlecht: nur würde ich ihn nicht in Grün verorten.

Zur Infrastruckutur und dem reverse Proxy.
Da bin ich mir auch noch nicht sicher, wie ich das haben will: was der
beste Ansatz wäre.
Auf meinen bisherigen Nextcloud Servern hab ich ja auch docker: für das
collabora Office.
Aber da macht der Apache des Hosts den Reverse Proxy.
Und so willst du das ja haben, wenn ich das richtig verstehe: der
Hostapache soll das machen.
Die andere Möglichkeit ist ein nginx Proxy der beenfalls in Docker läuft.
Der kann mit einem autodiscover automatisch neue Hosts versorgen: und
auch diese mit letsencrypt versorgen (weil beim Proxy die verschlüsselte
Verbindung endet, wenn ich das richtig verstanden habe).
Das ist natürlich schon auch sehr fein, wenn das klappt: aber noch hab
ich es nicht vollständig verstanden: und dass ist dann auch das Problem:
es ist komplex.
Unsere Frage ist, wie so oft, wie bekommen wir das immer
komplexerwedende Problem „Schulnetzwerk“ für die Admins möglichst gut
heruntergebrochen.
Da könnte ein nginx Proxy Blackbox helfen …

Ende nächster Woche ist Arbeitstagung: da kommt das bestimmt auch noch
mal auf den Tisch.

Viele Grüße

Holger

6

Update:

Es gibt jetzt eine fertige APP mit (halb)automatischer Konfiguration, so dass sich das Testen nochmal sehr vereinfacht.

VG

Frank

Ich habe die Infos auf den DockerHub angepasst. https://hub.docker.com/r/linuxmuster/mrbs

7

Ein Beitrag wurde in ein neues Thema verschoben: Docker KISS + linuxmuster-mrbs