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
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