direkt, z.B. für etherpad, markdown-server oder Greenlight für BBB, da habe ich explizit nach dem docker-container gefragt.
Ich setze postgres auch nachgelagert ein, weil ich einen Matrixserver betreibe, dessen installationsskript docker-container zieht, die wiederum postgres beinhalten.
könnte es noch docker-container geben, die als Grundimage ein postgres-docker nehmen und updaten, oder postgres intern einsetzen (da habe ich momentan kein Beispiel am Laufen, glaube ich)
Jetzt ist es so, dass die Fehlermeldung und die neuen Versionen seit 12.Mai existieren. Jetzt, 5 Tage danach, gibt es zwar von postgres offiziell neue Versionen aber im „offziellen“ postgres docker-container noch keine updates, dafür gibt es seit gestern ein github issue
Ich konstatiere:
Das geht ein bisschen langsam vonstatten (ok, so what?), obwohl postgres wohl ein irrsinnig wichtiges Softwarepaket und auch ein global player in der docker-welt ist. Was ist dann erst mit Sicherheitslücken von weniger bekannten Paketen/Containern (z.B. etherpad/etherpad) - wann schließen die die Lücken in den Docker-Containern?
Nachgelagerte Projekte, die docker-container „ziehen“ und nutzen müssen selbst aktiv sein, z.B. ist die Matrix-Community fix (aber auch im Wartemodus auf upstream-docker-images). Das haben wir (zumindest ich) als docker-nutzer nicht im Blick.
Wenn ich als Maßstab ein Moodle-Update und das folgende Roll-Out von Belwue nehme, dann muss ich mir schon an die Nase fassen:
Welche Updates mache ich regelmäßig (z.B. ubuntu/debian wöchentlich?)
Welche Updates mache ich unregelmäßig? (z.B. docker-container updates?)
Welche Updates verpasse ich, weil ich mir deren nicht bewusst bin (z.B. CVEs in docker-containern)
Vielleicht kristallisiert sich ja ein „Best-Practice“ heraus, wenn jemand von euch da organisierter ist, als ich.
VG, Tobias
Versuchen, alle Docker-Container selbst zu bauen und möglichst auf einheitlicher Grundlage (debian oder alpine) hochzuziehen. Das ist aber ein Riesenaufwand, je nach Softwarepaket (z.B. collabora …)
Versuchen, alle Docker-Container zu ziehen und upzudaten - je nach Anwendung kann das gut oder schlecht funktionieren… (im Postgres-update von 14.2 → 14.3 bin ich unsicher)
Hi Tobias,
ich (als bekenned unregelmäßig docker-updates holender) dachte mir (bisher): In meinen Dockers läuft ein MRBS, ein Collabora und ein Schulportfolio. Höchstens letzteres wäre empfindlich auf „Angriffe“. Hier kommt für mich die Frage auf, was dann passieren kann:
Den „Server“ können sie meiner unwissenden Meinung nach nicht übernehmen, das ist ja u.a. der Sinn von docker. In den Container kann man sich auch nur bedingt „einhacken“, da er zumindest nach Neustart wieder „sauber“ sein sollte (dachte ich). Bleibt: Nutzerdaten abgreifen…
ich sehe das weniger als grundsätzliche „Gefahr“, sondern tatsächlich eher als „wie macht man es richtig“.
Aber du hast natürlich Recht: ist die ganze Diskussion nötig, was kann maximal passieren?
Teil eines Bot-Netzes zu werden
Teil eines Cryptoschürfers zu werden
sind vielleicht die naheliegendesten Möglichkeiten, die (zumindest) rechtlichen Schaden anrichten können.
Dann folgt irgendwann die Möglichkeit, Nutzerdaten abzugreifen und schon hat man einen Datenschutzfall mit viel Verwaltungsaufwand (an DSB melden, …)
Man könnte auch Daten verschlüsseln und erpressen (da hilft dir auch der „reboot“ mit frischem Container nix mehr)
Dann folgt vielleicht eine automatisierte Spionage im selben Netz (DMZ bei uns) um andere docker-container von innerhalb anzugreifen…
Erst, wenn auch docker (oder der virtualisierer) selbst noch Lücken aufweist, kann man vielleicht ausbrechen und noch mehr Schaden im Netz machen.
Ich glaube, bei der Dockerisierung ist die Sandbox nicht die wichtigste Idee, sondern die noch einfachere Virtualisierung: Statt virtuellen Maschinen mit ihren Maintenance-Aufgaben und Konfigurationsmöglichkeiten, hast du vorkonfektionierte Softwarebundles. Danach kommen (bei mir von der Wichtigkeit her) die Skalierbarkeit (falls man mal Kubernetes und hunderte von dockercontainern laufen lässt) und das automatische Netzwerken und das Sandboxing.
Daher vielleicht auch der Thread: Wenn man die Maintenance-Aufgaben und Vorkonfiguration von Docker nutzt, dann gibt man auch die Verantwortung an die Docker-ersteller ab. Zumindest sollte man sich dessen bewusst sein, dass es schon toll ist, wenn man alle seine virtuellen Maschinen (z.B. Cloud in der DMZ) immer aktuell hält, aber ebenbürtig nicht so toll, wenn man über die Aktualität des Dockercontainers (z.B. Schulportfolio in der DMZ) nicht Bescheid wissen kann.
Genau das ist das Problem von Docker, und auch der Grund(neben der zusätzlichen Komplexität), weshalb ich es nicht nutze. Wenn man Docker professionell nutzen möchte(wenn Du schon von Kubernetes sprichst), dann braucht man ein eigenes Repository, welches man entsprechend pflegt. In den meisten meisten Schulumgebungen dürfte das den administrativen Aufwand sprengen.
Deshalb ist für mich ein feiner Mittelweg zwischen Docker und einer VM, ein LXC-Container. Da Proxmox die Möglichkeit bietet LXC Container zu erstellen, ist das auch super bequem und ich kann das Betriebsystem mit den üblichen Systemwerkzeugen aktuell halten.
Hi Tobias,
kennst / nutzt Du Portainer (hier ebenfalls direkt als docker-Container)??
Damit kann man sich den Update-Prozess immerhin etwas vereinfachen:
Du könntest auch ganz einfach Postgres ohne Container installieren. Das wäre doch auch eine Möglichkeit und sicher auch ohne Probleme in Deine Infrastruktur aufzunehmen. Docker schön und gut, aber wenn mal was nicht geht, ist es extrem unflexibel. Ich nutze Docker nur, wenn es gar nicht anders geht oder eindeutig unkomplizierter ist als direkt zu installieren.
stimmt, das ist erwähnenswert.
Für mich würde das nur meinen Update-Prozess in die GUI verlagern - ist ok und braucht nicht jeder, Portainer ist aber auch nicht intelligenter, was den Softwarestand angeht als ich bzw. docker-hub.
Was portainer das letzte mal noch nicht hatte, ich aber gerne hätte: wenn es für ein Docker-container ein neues Image gibt, hätte ich gerne eine Nachricht.
(a.k.a. cronjob für „pull“)
Außerdem hätte ich gerne die Nachricht, welche Version denn das neueste Image beinhaltet: wenn ich „docker pull collabora/code:latest“ mache, krieg ich momentan nicht heraus, dass es sich um 21.11.4.2 handelt, steht nicht in den meta-daten drin, so viel ich weiß. Das ist schade. Sobald ich „docker pull collabora/code:21.11.4.2.1“ mache, finde ich das auch in den MEtadaten von collabora/code:latest wieder…
(auch das lässt sich skripten, habe ich aber keinen Bock drauf…)
Ich gebe die Hoffnung ja nicht auf, dass linuxmuster mal ein eigene Repo bereithält.
Müsste ich erst wieder anschauen, bevor ich das kommentiere.
Weil du proxmox ansprichst: Was man dann eine Stufe weniger kritisch und eine Stufe darunter mal ansprechen könnte: Ich sehe kernel-updates bei Proxmox deutlich weniger häufig als bei ubuntu/debian. Das wundert mich (ohne überprüft zu haben, ob das gerechtfertigt ist).
Hm, ja, richtig.
Ich sehe halt: es ist immer sehr einfach, mit docker gleich loszulegen und es ist sehr einfach anderen mit wenigen Befehlen zu sagen, wie sie es auch machen können.
Vermutlich muss man die Reduzierung der Komplexität durch Docker damit erkaufen, dass man sich länger Gedanken macht, ob man ein Softwareprodukt langfristig auch so laufen lassen will und kann.
so wie @garblixa das schreibt, machen wir das inzwischen auch. LXC-Container (in Einzelfällen auch VMs) für jeden Dienst, den wir anbieten oder testen. Webdienste hinter einem NGINX reverse proxy. Bei der Einrichtung jedes Containers je nachdem, wie ich es haben mag „unattended-upgrades“ oder passwortloses SSH vom Server. Und die Mailserver-Konfiguration - so wird man über Neustarts und eventuelle Probleme auf dem Laufenden gehalten.
Den letzten Docker-Container (Collabora) haben wir vor ca. 1 Jahr abgeschaltet - und ich bin ganz froh, dass diese Abstraktionsschicht mir kein Kopfzerbrechen mehr bereitet und ich schnell über die Proxmox-Konsole oder per SSH nachschauen kann. Und Dienste z.B. auch separat sichern, Snapshots machen, gezielt Ressourcen zuteilen oder einfach mal ausschalten kann. Docker wäre ja an sich noch verfügbar - mir ist aber noch nichts begegnet, wo es mir Vorteile gebracht hätte.
Die vielen Dinge, die Proxmox (gerade in Verbindung mit dem Proxmox Backup Server) ermöglicht, finde ich für die Schule perfekt. Aber darum gehts ja hier nicht Schick wäre es natürlich, eine verbindliche Infrastruktur zu haben, so dass man Dienste mit anderen Schulen teilen könnte - irgendwie so eine gemeinsame Muster-Lösung
Der Mehrheit hier wird es ja so gehen, dass docker 1. offensichtlich einfach dokumentiert und 2. einfach hochgezogen ist. Und dass man 3. eben die komplette Umgebung kollaborativ weitergeben kann - geht das mit LXC?
Eine Generalisierung ist vor ein paar Jahren dann zwar eingeschlafen (mit limesurvey und mrbs-1.7.3 habe ich das jetzt immer aktuell gehalten und somit theoretisch für andere verfügbar), aber die Idee eines gemeinsamen Docker-Repositories mit halbwegs verbindlichen Containern oder als Fallback-Alternative ein schnelles Ziehen von hub.docker.com fand ich sehr, sehr gut. Sozusagen eine Musterlösung für Dienste in Containern. „Containern“ ist nachhaltig.
Ich bin ja offen für Neues, also schaue ich mir auch LXC an. Wie für andere bei docker, sehe ich aber auch eine zusätzliche Komplexität kommen (vermutlich nicht so komplex wie docker). Wie ich @thoschi kenne, stapelst du hier unter und euch geht LXC nur deswegen so locker von den Lippen, weil ihr mit ansible und weiteren „schulzeugs“ werkzeugen technologisch fit und flexibel seid… das scherzhafte „wer sonst“ von oben kann ich hier jetzt ernster wiederholen:
gibt’s eine empfohlene Lektüre?
wer sonst würde mal auf LXC umsteigen?
machen wir einen online / vor Ort Workshop und stellen gemeinsam um?
@thoschi s Idee, nicht die Container, sondern die Dienste zu teilen ist ja auch schick. Mit Collabora haben wir das ja schon testweise ganz gut hingekriegt gehabt.
Und für ein paar anonyme Dienste würde das sicher auch noch gehen, aber darüberhinaus? Ich habe viele Dienste mit dem Hauptargument am Laufen, weil es über LDAP authentifizierbar ist und ich damit sagen kann: „SuS können die Dienste nicht-anonym nutzen und wir haben kein Daten(lager)schutz problem.“
Bei einem Workshop: „Containern für Ein- und Aussteiger“ könnten wir ja auch diese Idee angehen. Ich hätte Bock…
)
Schick wäre es natürlich, eine verbindliche Infrastruktur zu haben, so dass man Dienste mit anderen Schulen teilen könnte - irgendwie so eine gemeinsame Muster-Lösung 
