Hallo,
das mache ich gerne.
Ich habe mir noch ein paar Gedanken zu einem etwas einheitlicheren Gerüst für Dockerhost und Apps gemacht, das folgende Bildchen zeigt das:
Im Wesentlichen sind das zwei ini-Dateien, die im Dockerhost vorhanden sein müssen:
-
server.iniEnthält alle Infos zum linuxmuster.net Server. Besonders auch die Version des Servers - damit kann man die Migration gestalten. -
docker.inidamit kann man z.B. für den ganzen Dockerhost eine Rolle definieren, ob der z.B. selbst Revers Proxy Dienste machen soll oder ob dieser Docker Host generell “extern” angsteuert wird. - Dann würde ich noch Skripte mitliefern, die App-Erstellern bei der Konfiguration nutzen können, so als eine Art API. Beispiel:
check_dns service.host.tldkönnte überprüfen, ob es einen DNS Eintrag für service.host.tld gibt, der auf den aktuellen Dockerhost zeigt. Im Setup Skript der App könnte man das dann benutzen, um das zu überprüfen, ebenso z.B. für das Zertifikat.
Die Apps sollten zwei Bedingungen erfüllen:
- App spezifische Konfiguration sollte in
app.iniim Verzeichnis der App liegen. Die Datei wird wenn nötig von der setup-Routine der App (s.u.) ausgewertet und kann auch fehlen. - Jede App sollte ein Skript
setuphaben, das in mindestens zwei Varianten funktionieren sollte:setup firstzur Erstkonfiguration undsetup updatezum Update der App. Wenns gut läuft, kann das Skript beides mal dasselbe tun, wenn nötig kann man aber eben zwischen Erstkonfiguration und Update differenzieren. Außerdem sind weitere Funktionen denkbar wiesetup migrate, um z.B. die MRBS DB in die Docker App zu migrieren.
Lasst mich mal wissen, was ihr dazu so denkt. CC: @thomas ich würde den mailserver/Hauptdockerhost auch in diese Richtung vereinheitlichen wollen, um die Dokumetation zu vereinfachen - deine Einschätzung ist also wichtig, was die Konfiguration im Zuge des Serversetups angeht - welche Probleme siehst du diesbezüglich?
VG
Frank