Docker-mailman: Docker de pile complète composer

Merci de votre intérêt pour cela, j'aimerais que cela se produise!

• Je pense que nous devrions conserver la composition de la pile complète en tant qu'option distincte de l'option actuelle, principalement pour les personnes qui ont besoin de leur serveur MTA/Web sur l'hôte pour faire autre chose que simplement servir Mailman.
• Déplacer les variables d'environnement vers le fichier .env n'a pas vraiment de sens pour moi, je comprends que vous vouliez probablement protéger vos secrets, mais à moins que vous n'utilisiez des autorisations Linux pour refuser l'accès à .env mais pas vers docker-compose.yaml , c'est un peu inutile, non ? Et je ne sais pas comment on s'y prendrait.
• L'ajout d'un conteneur postfix devrait être d'une grande aide, il n'a aucun rapport avec #282 , mais nous pouvons gérer cela dans un MR séparé.
• Je pense qu'il serait préférable d'ajouter un conteneur Nginx qui partage un volume avec mailman-web . Je ne suis pas très intéressé par le #144 pour le moment, surtout parce qu'il ne nous fait pas vraiment accélérer ou quoi que ce soit. La génération de fichiers statiques au démarrage devrait généralement être correcte.
• La connexion à stdout devrait être excellente, Django peut probablement le faire facilement, Core pourrait le faire.
• Pourquoi voulons-nous supprimer les entrées par défaut pour le nom d'hôte, le nom du conteneur et les liens ?
• Supprimer les éléments de réseau codés en dur est quelque chose que je veux vraiment faire, cela pourrait poser des problèmes en fonction de la façon dont Hyperkitty authentifie les demandes de Core, mais nous pouvons également résoudre ce problème en amont.

Dans l'ensemble, j'aime la plupart des idées. Idéalement, nous voudrions que chaque changement soit dans leur propre demande de tirage distincte, puis nous pourrons discuter plus en détail dans leurs PR respectifs.

À propos du fichier .env :

• il indique clairement à l'utilisateur final quelles variables doivent être modifiées sans rechercher l'ensemble du fichier docker-compose.yml
• il supprime les définitions en double (comme la clé api hyperkitty)
• cela pourrait/devrait faciliter la mise à niveau d'un docker-compose.yml (puisque l'on utilise celui en amont) et n'a qu'à ajouter/modifier les variables modifiées dans le .env local
• les utilisateurs finaux peuvent enregistrer leur docker-compose.yml en cours d'exécution dans le contrôle de source sans exposer de secrets

Je pense qu'un PR rendra cela plus clair, ce n'est pas beaucoup de travail donc pas de soucis si nous le laissons tomber.

Les liens sont une fonctionnalité obsolète, par défaut, tous les conteneurs d'une section de service sont dans un réseau, donc liés de toute façon. Le nom d'hôte et le nom du conteneur sont définis par défaut dans la section actuelle de la définition du service, de sorte qu'ils sont les mêmes que ceux actuellement explicitement définis et je pense que leur suppression rend le fichier entier plus petit et donc plus facile à comprendre.

Un peu lié, j'ai intégré ces conteneurs dans Mailu (https://github.com/Mailu/Mailu) qui fournit le reste de la pile. Y a-t-il un intérêt pour une telle configuration ?

@pgeorgi Si vous avez déjà cette intégration que vous souhaitez conserver en utilisant ces images, je serais heureux d'ajouter un lien vers votre référentiel/poste dans la documentation.

@pgeorgi définitivement

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

Je suis d'accord avec @morbidick à propos du .env , principalement parce qu'il rend la mise à jour beaucoup plus facile.
Vous pouvez simplement faire un git pull sans polluer votre repo.
De plus, le fichier .env doit être dans .gitignore

Exemple : Regardez comment Sentry fait cela :
https://github.com/getsentry/onpremise

Ils fournissent également un fichier env.example que vous pouvez copier dans votre propre fichier .env .