Docker-mailman: Redacción de ventana acoplable de pila completa

Gracias por su interés en esto, ¡me encantaría que esto sucediera!

• Creo que deberíamos mantener la composición de pila completa como una opción separada de la actual, principalmente para las personas que necesitan su MTA / Servidor Web en el host para hacer otras cosas además de servir a Mailman.
• Mover las variables de entorno al archivo .env realmente no tiene mucho sentido para mí, entiendo que probablemente desee mantener sus secretos más seguros, pero a menos que uno esté usando algunos permisos de Linux para denegar el acceso a .env archivo pero no a docker-compose.yaml , es algo inútil, ¿verdad? Y no estoy seguro de cómo haría uno para hacer eso.
• Agregar un contenedor postfix debería ser de gran ayuda, no está relacionado con # 282, pero podemos manejar eso en un MR separado.
• Creo que lo mejor sería agregar un contenedor Nginx que comparta un volumen con mailman-web . No estoy muy interesado en el # 144 en este momento, especialmente porque realmente no nos acelera mucho ni nada. La generación de archivos estáticos al inicio normalmente debería estar bien.
• Iniciar sesión en stdout debería ser genial, Django probablemente pueda hacerlo fácilmente, Core podría hacerlo.
• ¿Por qué queremos eliminar las entradas predeterminadas para el nombre de host, el nombre del contenedor, los enlaces?
• Eliminar las cosas de la red codificadas de forma rígida es algo que realmente quiero hacer, que podría tener algunos desafíos según la forma en que Hyperkitty autentica las solicitudes de Core, pero también podemos solucionarlo en sentido ascendente.

En general, me gustan la mayoría de las ideas. Idealmente, quisiéramos que cada cambio esté en su propia Pull Request separada y luego podamos discutir con más detalles en sus respectivos RP.

Acerca del archivo .env :

• deja en claro al usuario final qué variables deben cambiarse sin buscar arrojó todo el docker-compose.yml
• elimina las definiciones duplicadas (como la clave api de Hyperkitty)
• podría / debería facilitar la actualización de un docker-compose.yml (ya que uno está usando el anterior) y solo tiene que agregar / modificar las variables cambiadas en el .env local
• los usuarios finales pueden registrar su docker-compose.yml en ejecución en el control de fuente sin exponer secretos

Creo que un PR lo aclarará, no es mucho trabajo, así que no hay problema si lo dejamos.

Los enlaces son una característica obsoleta, de forma predeterminada, todos los contenedores en una sección de servicio están en una red, por lo que están vinculados de todos modos. El nombre de host y el nombre del contenedor se ajustan de forma predeterminada a la sección actual en la definición del servicio, por lo que son los mismos que se definen explícitamente actualmente y creo que eliminarlos hace que todo el archivo sea más pequeño y, por lo tanto, más fácil de entender.

Algo relacionado, integré estos contenedores en Mailu (https://github.com/Mailu/Mailu) que proporciona el resto de la pila. ¿Existe interés en tal configuración?

@pgeorgi Si ya tiene esa integración que le gustaría mantener usando estas imágenes, me complacerá agregar un enlace a su repositorio / publicación en la documentación.

@pgeorgi definitivamente

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

Estoy de acuerdo con @morbidick sobre el .env , principalmente porque facilita mucho la actualización.
Simplemente puede hacer un git pull sin contaminar su repositorio.
Además, el archivo .env debe estar en .gitignore

Ejemplo : mira cómo Sentry hace esto:
https://github.com/getsentry/onpremise

También proporcionan un archivo env.example que puede copiar en su propio archivo .env .