Docker - Strategisch für linuxmuster gedacht


#1

Hallo,

ich wollte zum Thema Docker noch mal eine Diskussion auf der Metaebene anstossen.

Was wir insgesamt gerade hier machen ist eine Mischung aus “lernen” und “anwenden”, das ist natürlich der richtige und einzig mögliche Ansatz, das anzugehen, aber das ist IMHO gefährlich um Entscheidungen zu treffen.

Hat wirklich jeder von euch verstanden, was genau jede Anweisung in den Docker-Compose Dateien, die ihr zum Containerstart aus irgendeiner Anleitung nehmt bewirkt? Da kann ich natürlich Netzwerke erstellen in allen Farben und Formen, Volumes kreieren bis ich schwarz werde und dergleichen, verstehen muss ich da aber nix für :wink:

Meine Vorstellung wäre ungefähr folgende:

Wir (linuxmuster.net) kuratieren eigene Images, die “offiziell” sind. Dafür stellen wir eine möglichst einfache virtuelle Maschine als Vorlage zur Verfügung, auf denen unsere Container funktionieren.

Das kuratieren kann man mit sehr wenig Aufwand machen: man nimmt das Nextcloud Image, baut es als linuxmuster/nextcloud neu, eventuell mit Anpassungen oder auch ohne, testet das auf unserem Docker Host und pusht es in unser Repo. Dazu gibt es die passende Compose Datei, so dass das auf unserem Docker Host mit unserem Reverse Proxy out of the box läuft.

Außerdem dokumentieren wir, wie man z.B. einen Container mit einem weiteren Dienst da anflanschen kann.

Und wer mehr will, soll das selber machen.

Problematisch an der Docker Sache ist, dass die “industriellen” Lösungen um Skalen zu groß sind für das, was wir brauchen.
Der Docker Host + Reverse Proxy hat null Anhängigkeiten, ein simples Netzwerk, das ist überschaubar. Wenn wir anfangen, jede Eventualität mit irgendwelchen zusätzlichen Containern abzufangen, macht das Aufwand und erhöht die Komplexität, womit wir potentiell Mitarbeiter und Containerisierte Dienste aus der Community verlieren.

Beispiel: Einen eigenen MRBS Container zu pflegen ist deutlich einfacher, als ein linuxmuster-mrbs Paket zu pflegen - wenn die Rahmenbedingungen hinreichend klar sind.

VG

Frank


#2

Hallo zusammen,

zuerst einmal ein frohes neues Jahr und ein dickes Dankeschön für die viele Arbeit und das große Engagement für dieses tolle Projekt! Persönlich würde ich gern folgende Gedanken äußern, die mir nicht nur bei Docker, sondern auch bei anderen Themen wie der zukünftigen Firewall durch den Kopf gehen.

Technisch betrachtet erweitert Docker die Virtualisierungsebene weiter vom Betriebssystem bis auf Applikationsebene. Aus meiner Sicht liegt der Sinn vor allen Dingen darin, die Sicherheit der Applikation selbst zu verbessern. Erkauft wird das Ganze aber durch Steigerung der Komplexität. Was genau will ich jetzt damit sagen? :wink: Ich will sagen, dass der Betrieb der Umgebung vielleicht einfacher wird, aber das notwendige Wissen, um die Umgebung solide zu betreiben, steigt. Dessen muss man sich auf jeden Fall bewusst werden! Diese Problematik kann ich fortsetzen bei der Diskussion um eine neue Firewall. IPFire ist eine Firewall, die die Komplexität des Themas dadurch reduziert, dass sie Funktionalitäten und Netze bewusst begrenzt, was wahrscheinlich für 90% der Schulen ausreichend ist. Soll jetzt eine neue Firewall wie OPNsense o.ä. eingesetzt werden, so bietet Diese natürlich alle nur möglichen Funktionalitäten, aber sollte man auch wissen, was man da tut. Wenn die Mehrheit davon profitiert, Klasse! Sofort umsetzen!

Ich bitte, mich nicht falsch zu verstehen; aber ist es nicht jetzt schon so, dass Dinge, wie z.B. die Netzsegmentierung oder das WLAN von der Mehrheit nur durch “Schritt für Schritt” Anleitungen umgesetzt werden können, die zwar den Weg beschreiben, aber nicht, warum der Weg genau so beschritten wird. Dies wird immer dann problematisch, wenn es Probleme gibt.

Jede neue Funktionalität ist aus meiner Sicht ein Mehrwert, solange der Nutzen den Aufwand wirklich übersteigt …

In diesem Sinne und herzliche Grüsse,
Bertram


#3

Ich würde sagen: natürlich ist das so, dass die meisten hier (die ja fast alle keine hauptberuflichen Admins sind!) viele Dinge am besten mit einer Step-by-Step-Anleitung umsetzen können. Besser, als wenn es gar keiner macht?!? :slight_smile:

Deine zweite Aussage “warum Dinge genau so (und nicht anders) beschritten werden” kann ich jedoch bestätigen: bei manchen neueren Entscheidungen wäre mir eine Diskussion / kurze Begründung / weitergehende Informationen auch ganz recht.
Auf Nachfrage lässt sich aber vieles davon hier in Erfahrung bringen.
Michael


#4

Hallo Bertram, Hallo Michael,

erstmal zur Firewall:
die Problematik wurde oft diskutiert.
Am Ende benötigen wir Funktionalitäten der OPNsense die IPFire eben
nicht mehr hatte: also schwenken wir um.
Das bedeutet für viele, dass die Firewalloberfläche komplizierter wird
… ist aber nicht so schlimm, da sie für viele sowiso keine Ecke war, an
der sie rumgestellt haben.
Das merke ich auch im Telefonsupport: da schaue ich immer mal auch nach
der Firewall und stelle noch was ein: die LEute sind dann froh, dass sie
es nicht selber machen müssen.
Für die ändert sich also nix.

Deine zweite Aussage “warum Dinge genau so (und nicht anders)
beschritten werden” kann ich jedoch bestätigen: bei manchen neueren
Entscheidungen wäre mir eine Diskussion / kurze Begründung /
weitergehende Informationen auch ganz recht.

alle diese Dinge wurden, inzwischen Jahre lang, ausgiebigst diskutiert:
auf mehereren Treffen in Pfinztal und in Essen.
Zu diesen ist jeder immer eingeladen: wer also mitdiskutieren will: die
nächste Sitzung ist irgend wann März/April in Pfinztal (Karlsruhe).
Die letzte war in Essen im Linuxhotel (Anfang Dezember).

Und wer in ungezwungener Umgebung einen Tag locker über die lmn reden
will, der kommt zum Listengrillen (muss ich das jetzt in Forumsgrillen
umbenennen?) irgend wann im Juni, ebenfalls in Karlsruhe.

Viele Grüße

Holger


#5

Hi Holger, du hast recht: die Dinge werden ausgiebig diskutiert und ganz sicher auch vernünftig gegeneinander abgewogen, doch manchmal wäre halt es schön, wenn die Ergebnisse & Begründungen für irgendwelche tiefgreifenden Entscheidungen auch hier im Forum landen würden, damit auch alle, die nicht zu den Treffen kommen konnten, Bescheid wissen.

Ich weiß, dass es ein Protokoll gibt und dass es natürlich auch wieder Arbeit ist, “alles” nochmal hier zu posten, doch so grundlegende Dinge wie der Wechsel der Firewall oder auch damals die Ausrichtung in Richtung XEN könnten manchmal imho transparenter / direkter dargestellt werden, anstatt erst eine ewig lange Diskussion “für & wider” los zu treten. Einfacher wäre es imho in diesen Fällen, wenn zB ein kurzer Beitrag aus Entwicklersicht hier gepostet würde, der dann in etwa lauten könnte: “Die FW muss aus diesen und jenen Gründen von IPFire auf OPNSense umgestellt werden.” Fertig.

Ich will damit aber keinem auf die Füße treten, da hier ja keiner mit irgendwelchen Infos hinter dem Berg hält, wenn man konkret danach fragt…
Ist eher als Anregung gedacht.
Schönen Gruß,
Michael


#6

Hallo Michael,

Hi Holger, du hast recht: die Dinge werden ausgiebig diskutiert und ganz
sicher auch vernünftig gegeneinander abgewogen, doch /manchmal/ wäre
halt es schön, wenn die Ergebnisse & Begründungen für irgendwelche
tiefgreifenden Entscheidungen auch hier im Forum landen würden, damit
auch alle, die nicht zu den Treffen kommen konnten, Bescheid wissen.

Ich weiß, dass es ein Protokoll gibt und dass es natürlich auch wieder
Arbeit ist, “alles” nochmal hier zu posten, doch so grundlegende Dinge
wie der Wechsel der Firewall oder auch damals die Ausrichtung in
Richtung XEN könnten manchmal imho transparenter / direkter dargestellt
werden, anstatt erst eine ewig lange Diskussion “für & wider” los zu
treten. Einfacher wäre es imho in diesen Fällen, wenn zB ein kurzer
Beitrag aus Entwicklersicht hier gepostet würde, der dann in etwa
lauten könnte: “Die FW muss aus diesen und jenen Gründen von IPFire auf
OPNSense umgestellt werden.” Fertig.

normalerweise würde ich genau solche Infos hier ins Forum reintragen,
nur leider war ich dieses Jahr nicht in Essen auf der Tagung: da musste
ich kurzfristig absagen, da meine Frau von Mitte Oktober bis Mitte
Dezember im Krankenhaus war und ich hier Zuhause zwei Töchter und einen
Hund versorgen musste … ach so: arbeiten musste ich natürlich auch.

Wirt hatten das zwar schon im März/April in Pfinztal besprochen… aber
leider war das zu lange her für mein Gedächtnis.

Also: nächstes mal bin ich wieder besser informiert :slight_smile:

LG

Holger


#7

Hallo Holger,
ist doch klar, dass persönliche Dinge vorgehen. Bestell’ Deiner Frau die besten Wünsche und gute Besserung. Alles andere kann warten (oder muss von anderer Stelle erledigt werden). :+1:
Schöne Grüße,
Michael


#8

Hallo zusammen,

danke für Eure Antworten, die aus meiner Sicht zeigen; und bitte wieder nicht falsch verstehen; dass wir uns in einem semiprofessionellen Umfeld bewegen. In diesem Umfeld ist Docker ein super Beispiel dafür, dass die Vorteile, die die Applikationsvirtualisierung bringt, mit Komplexität erkauft wird. Dies ist doch die Problematik, um die es hier geht, oder? :wink:

Wir haben eine:

  • zusätzliche Netzwerkebene - Nicht schlimm, wenn hier was schief geht …
  • zusätzliche Filesystemebene - Unter Umständen schlimm, wenn hier was schief geht …

Persönlich unterstütze ich das Vorhaben sehr, allerdings sehe ich die Gefahr, dass die Dinge zu komplex werden könnten…

Grüße
Bertram


#9

Hallo Bertram,

Wir haben eine:

  • zusätzliche Netzwerkebene - Nicht schlimm, wenn hier was schief geht …
  • zusätzliche Filesystemebene - Unter Umständen schlimm, wenn hier was
    schief geht …
    Persönlich unterstütze ich das Vorhaben sehr, allerdings sehe ich die
    Gefahr, dass die Dinge zu komplex werden könnten…

als vor einigen Jahren die Virtualisierung auf kam, gab es auch mehrere
die genau das gesagt haben: zusätzliche Komplexität erhöht die
Ausfallwahrscheinlichkeit und erfordert zuviel Wissen auf Seiten der Admins.

Und was haben wir jetzt?
Wer hat den noch sein Server auf dem Blech laufen und einen IPFire
daneben und eine Nextcloud und den unifi/Coova Server?
So gut wie niemand.
Jeder hat virtualisiert, weil es inzwischen “normal” ist und die
Vorteile davon sich durchgesetzt haben.
Inzwischen blicken mehr durch bei der Virtualisierung und trauen sich
dann auch mal hin zu fassen.

Es hat uns aber auch Sicherheitstechnisch etwas gebracht. Vorher haben
noch viele z.B. moodle auf dem server direkt installiert und verwendet.
Davon sind wir jetzt weg.

Und nun stehen wir mit der Version 7 vor der Frage: ziehen wir das
Sicherheitstechnisch ordentlich durch: von Anfang an, oder machen wir
weiterhin einen eher angreifbaren Multitalentserver?
Wir haben uns für die Sicherheitsversion entschieden, die die
Komplexität erhöt: ja, wissen wir, haben wir so entschieden nach langer
Diskussion.

Mein Argument ist: weil wir die Sicherheit erhöhen müssen: es schmeckt
mir nicht, dass horde auf meinem Server läuft: das ist ein von außen
zugreifbarer Dienst auf meinem Server, der in Grün steht…: ich will es
nicht, ich halte das für überhaupt keine gute Idee
2) weil wir gleichzeitig nicht noch mehr Feature abschalten wollen

Was haben wir bisher abgeschlatet: mit der paedML3 gab es noch ein von
außen zugängliches Collaborations und communikations Dingens (hab den
Namen vergessen). In Version 4 verloren wir die /html Verzeichnisse in
den Schülerhomes: bis dahin war es möglich dort einfach html Seiten rein
zu stellen und man konnte von außen draufschauen durch
http://meineschule.de/~meinusername

Das sind Funktionalitäten die wir verloren haben, weil sie
sicherheitstechnisch ein Alptraum waren: und das würde nun den
Mailserver mit horde treffen.

Also: wir haben uns entschieden, dass wir diese Funktionalitäten anders
wieder zur Verfügung stellen wollen und dabei kam Docker auf, um das
explodieren der virtuellen Maschinen zu verhindern.
Kurzer check: bei mir laufen auf den Servern folgende VMs
ipfire, server, nextcloud, webserver (mit zwei moodleinstanzen, mrbs,
portfolio und docker für collaboraoffice), airdroid, Schoolsolution und
der unificontroller.
Das sind 7 virtuelle Maschinen… da bin ich schon ganz froh, wenn das
nicht noch mehr werden.

Aber: wer das lieber will, weil er moodle bei belwue hat und die
nextcloud bei weisnichwas, dann hat er nur 2 oder 3 server virtuell
laufen: bitte, einfach eine Kiste dazu und mailserver drauf ohne docker.
Das geht ja, das darf man gerne machen.
Und wer jetzt die ganzen Dinger lieber auf dem Blech installiert und
eben 3 oder 4 server hin stellt statt einen virtualisierungsserver:
bitte, darf man auch.
Es geht ja nur um den vom Verein empfohlenen Weg: und der wird Docker
sein und ich halte es für richtig :slight_smile:

LG

Holger


#10

Hallo Holger,

Dann habe ich wohl Franks Absatz falsch interpretiert. Ich habe ihn so verstanden, dass er auf diese Problematik aufmerksam machen wollte und die Entscheidung eben noch nicht getroffen wurde, dass es Docker werden soll … Mein Fehler … ;-(

Services vom Schulserver herunter zu nehmen, hat nichts mit der Frage zu tun, ob ich die Virtualisierung bis auf Applikationsebene durchziehe oder nicht! Es ist unbestritten, dass Services, die aus dem Internet errichbar sind, nicht in ein grünes Netz gehören.

Ich habe keine Zweifel daran, dass Du und alle anderen fleissigen Schreiber die Sache im Griff habt. Alles was ich möchte, ist darauf hinzuweisen, dass ich die Gefahr sehe, dass es zu einer Überforderung kommt. Falls das nämlich der Fall sein sollte, kann ich aus langer Berufserfahrung sagen, ist es egal, ob ein System auf dem Papier sicher ist - wenn die Nutzer nicht wissen, was sie da eigentlich machen. Diese Entwicklung gibt es meiner Auffassung nach durchaus auch bei den Profis, wo es viele Spezialisten, wie Netzwerk-, Server-, DB-, Storage- und sonstwas für Admins gibt - alle Spezialisten auf Ihrem Gebiet - und es kommt trotzdem zu Ausfällen, Datendiebstahl und Verlust, weil nur die Wenigsten noch das Gesamtbild verstehen. Das schwächste Glied in einer Kette bestimmt die Sicherheit des Gesamtsystems …

Und nun möchte ich wirklich nicht weiter in Fettnäpfchen treten … :wink:

Herzliche Grüße
Bertram


#11

Hallo Bertram, hallo Holger,

ich finde es gut, dass Bertram diese Bedenken hier einbringt.

Ehrlich gesagt bin ich in HH bei der Einführung von linuxmuster zunächst
auch vor der Virtualisierung zurückgeschreckt, weil ich ja den TfK
Schulrouter als Firewall und Proxy nehmen musste und damals nicht mit
ipfire kaskadieren durfte. Eine KollegIn hat die Einführung von
linuxmuster 2017 auf Eis gelegt, weil sie die Installation virtualisiert
nicht hinbekommen hat.

Jetzt wurde mir der Umstieg auf Iserv und Windows 10 verordnet, worüber
ich insofern nicht unglücklich bin, weil Iserv sich jetzt damit
herumschlagen darf, weshalb sich MS Office 2016 trotz FWU 2.0 nicht
aktivieren lässt …
Anfangs fand ich es wie Iserv selbst fragwürdig, dass iserv in HH keine
Schnittstelle in GRUEN haben darf, sondern nur eine in ORANGE, das er
mit niemandem teilen muss. Theoretisch bremst dies die Windows Clients
in GRUEN erheblich aus. Praktisch ist tut es jedoch nur weh, wenn man
zig Rechner auf einmal mit OPSI beharkt. Allerdings sind die Clients in
HH alle nur mit 100 MBit/s angebunden, was im “Normalbetrieb” wohl nicht
reicht, um den mit 1 GBit/s angebundenen Schulrouter in die Knie zu zwingen.
Es ist also durchaus möglich, Holgers berechtigte Anforderung “keine von
außen erreichbaren Dienste in GRUEN” in einem deutlich einfacheren
Szenario mit nur einem Server auf bare metal zu erfüllen, wenn man in
Kauf nimmt, dass man dann alle Dienste über die Firewall laufen lassen
muss.
(Wegen der Portweiterleitung von Port 443 auf server für Horde von ROT
nach GRUEN hatte ich hier vorher nach Bedenken gefragt. Die hielten sich
damals u. a. bei Holger in Grenzen und auch die Behörde hat dies im
Gegensatz zu Schnittstellen in ORANGE und GRUEN akzeptiert.)

Ich ahne, was die Schulleitung der Kollegin trotz 2017 gegenüber 2016
verdreifachter(!) Preise für Neukunden demnächst kaufen wird …

Wenn linuxmuster keine einsame Insel bleiben oder werden soll, sollte es
auch weiterhin einfach möglich und vor allem dokumentiert sein,
linuxmuster 6.2/7 auf bare metal (in ORANGE von ipfire oder sonst
irgendeiner Firewall/Proxy-Lösung) zu installieren - ohne einen Wust aus
virtuellen Schnittstellen, den wahrlich nicht mehr jede® (sicher)
durchschaut!

Just my 2ct
Jürgen

P.S.: Trotzdem macht ein modularer Aufbau mit virtualisierten Appliances
Sinn und wenn es mit Docker einfacher geht als mit XEN oder KVM gerne
damit. Wenn ich mit linuxmuster und Windows 10 hätte weitermachen
sollten, wäre ich wegen OPSI (inklusive KMS!) und des inzwischen
zugestandenen kaskadierten ipfire (oder sonstwas vergleichbaren) das
Thema auch noch einmal angegangen.


#12

Noch ein Nachtrag: Vielleicht wäre auch diese Distribution zukünftig eine elegante Ausgangsbasis für das, was wir vorhaben?

Zudem habe ich gestern einen moodle-Container via docker installiert (bitnami). Das lief ootb und dank Franks Videos ist auch klar, was da mit Hilfe von docker-compose im Hintergrund ablief! Version 3.4 ist tatsächlich ein RIESIGER Sprung im Vergleich zu der alten Version 2.9, die bei uns noch läuft. OT: Läuft da das openlml_enrol-Paket noch? Wer hat das bereits ausprobiert?

Schöne Grüße,
Michael


#13

Hallo Michael,

Nenn mich altmodisch, aber ich halte ein minimales Ubuntu für uns für besser geeignet, weil ich da den Docker Host pflegen kann wie den Rest meiner Server auch.

VG

Frank


#14

Hi Frank.
Da hast du sicher recht … ich fand nur erstaunlich, wie schnell das angeblich gestartet ist und dass es komplett im RAM läuft. Allerdings steht dort ja auch, dass “Using it for any kind of production workloads at this time is highly discouraged.” Bei Ubuntu weiß man wenigstens was man hat :slight_smile:

Schöne Grüße,
Michael

Nochmal OT: Es gibt für moodle auch dieses kleine “portable” Projekt – wenn man moodle unbedingt mal mit auf die grüne Wiese nehmen muss :slight_smile: -->


#15

Guten Abend zusammen.
Ich schreibe hier einfach munter weiter … da es erneut zum großen Thema “Docker” passt :slight_smile:

Also wenn die Roadmap von linuxmuster tatsächlich (auch) in Richtung docker geht und es irgendwann einen moodle- / NextCloud-Container geben sollte, wäre es prima, wenn wir dazu gleich folgendes beachten: Man kann NextCloud so installieren, dass es auf einen mySQL/mariaDB-Container zugreift. Genaueres steht hier unter “Using an external database”

Da ich den moodle-Container bereits installiert und gesehen habe, dass der bereits eine mariaDB mitbringt, wäre es doch elegant, wenn man das nun kombinieren könnte (auch im Sinne der gemeinsamen Dateiablage von beiden Systemen). Wozu noch einen DB-Container laufen lassen, wenn’s auch mit einem geht? Was sagen die Wizzzards dazu?

Schönen Gruß,
Michael


#16

Hallo Michael,

Dafür spricht: ich muss nur einen DB Container pflegen.

Dagegen spricht: man kann die Betreuung der Container schwerer verschiedenen Personen übertragen, weil ich dann natürlich Abhängigkeiten zwischen den Containern bekomme.

Wenn es am Ende z.B. Moodle, Nextcloud, MRBS +X gibt, und die benutzen alle einen exernen DB-Container, dann muss der Betreuer des DB Containers bei allen Aktualisierungen sicherstellen, dass alle Apps, die darauf zugreifen auch noch tun.

Wenn jeder Anwendungscontainer seine eigene Datenbank mitbringt, kann das eine ambitionierte Person ohne weiteren Kommunikationsoverhead aktuell halten.

Das ist für mich also ein typischer Fall von LMZ-Neusprech: “Professionell” wäre ein DB-Container für viele Apps, für uns besser geeignet sind wahrscheinlich Container die Ihre Abhängigkeiten dabei haben.

VG

Frank


#17

So habe ich das noch gar nicht gesehen. Aus dieser Sicht aber richtig!

Dann ist die nächste Frage, wieviel overhead X nebeneinander laufende DB-Docker erzeugen, die einzeln betrachtet nicht soooo viel zu tun haben dürften…?