Danke @andi für deinen Einsatz, das ganze mit Docker zum Laufen zu bekommen.
Für den Betrieb mit Docker Compose gibt es ja ein paar Variablen (nur Hub/Display oder beides, nginx oder traefik als Reverse Proxy usw.). Meinst du es macht Sinn, für die verschiedenen Konstellationen verschiedene Dateien anzulegen? Dann kann man sich die richtige raussuchen und anpassen.
Die Alternative wäre, eine längere Datei mit Kommentaren, welcher Teil in welchem Fall ein- oder auskommentiert werden soll.
Oder gleich ein Skript, das ein paar Fragen stellt und dann die Datei zusammenbaut?
Die gleichen Gedanken hatte ich auch schon… Für den Anfang würde ich erst mal den „einfachen“ Fall abdecken, dass Hub und Display über ein File abgedeckt ist. Ich denke, dass die meisten erst einmal zum Testen das System hochfahren und es für sich zum Laufen bringen wollen. Dafür verwende ich persönlich gerne ein einfaches docker-compose-Setup.
Meinst du, dass nginx und traefik ebenfalls berücksichtigt werden sollen? Ich hoffe, dass jeder der das System ins Internet stellt, dementsprechendes Know-How verfügt
Einen docker-compose-Konfigurator Klingt interessant, aber ich hoffe, dass sich die Anwender auch ein bisschen schlau machen
Mir sind noch ein paar andere Variablen in den Kopf gekommen. Wie sieht es mit den Docker-Images aus? Sollen die lokal ebenfalls über docker-compose gebaut werden oder z.B. auf dem Docker Hub veröffentlicht werden?
Wenn die Images veröffentlicht werden, wären CI/CD Pipelines nett, um die Images regelmäßig zu aktualisieren…
Wenn die Images lokal über docker-compose (neu-)gebaut werden, sollen dann die Repositories von hub und display als git submodule eingebunden werden? @abrain wie denkst du darüber?
Ja ich denke auch, dass der Großteil der Installationen beide Komponenten beinhalten wird.
Ich würde ja eher hoffen, dass es erst gar niemand ans Internet hängt Abgesehen davon, fände ich eine Transportverschlüsselung im lokalen Netz durchaus sinnvoll. Allerdings öffnet das gleich ein ganzes Fass an Problemen mit selbstsignierten Zertifikaten und ähnlichem. Würde ich jetzt erst mal weglassen. Das muss dann je nach Risikobewertung selbst dazugebaut werden.
Da hatte ich Docker Hub und GitHub Packages im Blick. Die Display beta 1 wurde so auch schon verteilt, allerdings noch manuell. Für die Display beta 2 und die Hub beta 1 hatte ich das dann aufgrund von Zeitmangel nicht mehr hinbekommen. Daher ist ein automatisches Bauen, Testen und Veröffentlichen unerlässlich. Lokal können die Images ja weiterhin gebaut werden, wenn da jemand wert darauf legt.
Abgesehen davon, fände ich eine Transportverschlüsselung im lokalen Netz durchaus sinnvoll. Allerdings öffnet das gleich ein ganzes Fass an Problemen mit selbstsignierten Zertifikaten und ähnlichem. Würde ich jetzt erst mal weglassen. Das muss dann je nach Risikobewertung selbst dazugebaut werden.