Docker-mailman: Full Stack Docker Compose

Vielen Dank für Ihr Interesse daran, ich würde mich freuen, wenn das passiert!

• Ich denke, wir sollten die Full-Stack-Komposition als separate Option zur aktuellen Version beibehalten, hauptsächlich für die Leute, die ihren MTA/Webserver auf dem Host benötigen, um andere Dinge zu tun, als nur Mailman zu bedienen.
• Verschieben von Umgebungsvariablen .env Datei macht nicht wirklich eine ganze Menge Sinn für mich, ich verstehe , dass Sie wahrscheinlich Ihre Geheimnisse sicherer halten wollen, aber es sei denn , man einige Linux - Berechtigungen mit Zugang zu verweigern .env Datei, aber nicht zu docker-compose.yaml , es ist irgendwie nutzlos, oder? Und ich bin mir nicht sicher, wie man das anstellen würde.
• Das Hinzufügen eines Postfix-Containers sollte eine große Hilfe sein, es hat nichts mit #282 zu tun, aber wir können das in einem separaten MR behandeln.
• Ich denke, das Hinzufügen eines Nginx-Containers, der sich ein Volume mit mailman-web teilt, wäre am besten. Ich interessiere mich momentan nicht sehr für #144, vor allem, weil es uns nicht wirklich beschleunigt oder so. Das Generieren statischer Dateien beim Start sollte normalerweise in Ordnung sein.
• Die Protokollierung auf stdout sollte großartig sein, Django kann das wahrscheinlich leicht tun, Core könnte das.
• Warum wollen wir die Standardeinträge für Hostname, Containername, Links entfernen?
• Das Entfernen der hartcodierten Netzwerksachen ist etwas, was ich wirklich tun möchte. Das kann einige Herausforderungen mit sich bringen, je nachdem, wie Hyperkitty Anfragen von Core authentifiziert, aber wir können das auch im Upstream beheben.

Insgesamt gefallen mir die meisten Ideen. Im Idealfall möchten wir, dass jede Änderung in einem eigenen separaten Pull-Request steht und wir dann in ihren jeweiligen PRs genauer besprechen können.

Über die .env Datei:

• es macht dem Endbenutzer klar, welche Variablen geändert werden sollten, ohne die gesamte docker-compose.yml zu suchen
• es entfernt doppelte Definitionen (wie den Hyperkitty-API-Schlüssel)
• es könnte/sollte es einfacher machen, eine docker-compose.yml zu aktualisieren (da man die Upstream-Datei verwendet) und muss nur geänderte Variablen im lokalen .env hinzufügen/ändern
• Endbenutzer können ihre laufende docker-compose.yml in die Quellcodeverwaltung einchecken, ohne Geheimnisse preiszugeben

Ich denke, eine PR wird das klarer machen, es ist nicht viel Arbeit, also kein Ärger, wenn wir es fallen lassen.

Links sind eine veraltete Funktion, standardmäßig befinden sich alle Container in einem Serviceabschnitt in einem Netzwerk, also sind sie ohnehin verbunden. Hostname und Container-Name sind standardmäßig im aktuellen Abschnitt in der Service-Definition enthalten, also die gleichen wie derzeit explizit definiert, und ich denke, das Entfernen macht die gesamte Datei kleiner und damit leichter zu verstehen.

Etwas verwandt habe ich diese Container in Mailu (https://github.com/Mailu/Mailu) integriert, das den Rest des Stack bereitstellt. Besteht Interesse an einem solchen Setup?

@pgeorgi Wenn Sie bereits über diese Integration verfügen, die Sie mit diesen Bildern beibehalten

@pgeorgi auf jeden Fall

Siehe https://patrick.georgi.family/2019/01/12/combining-mailman-3-with-mailu/

Ich stimme @morbidick in Bezug auf die Datei .env , hauptsächlich weil sie die Aktualisierung viel einfacher macht.
Sie können einfach ein git pull ohne Ihr Repo zu verschmutzen.
Außerdem sollte sich die Datei .env in .gitignore

Beispiel : Sehen Sie sich an, wie Sentry dies macht:
https://github.com/getsentry/onpremise

Sie bieten auch eine env.example Datei, die Sie in Ihre eigene .env Datei kopieren können.