Fullstack docker-compose

[morbidick]

first of all thanks for the amazing containers, it made my installation a lot easier. I recently created a complete production docker-compose setup. I'ld like to propose/discuss a few changes/additions to this project that I learned doing my Setup.

• provide a full docker-compose including MTA and SSL Termination (basicly Provide deployment instructions for pure-container based arch #174)
  • move site specific variables to a .env file (secrets and domains)
  • add a postfix container with the mailman specific config and a configurable local subnet (would help with Consider moving the default MTA to postfix #282)
  • add a nginx container that already includes the static files and proxies to the uwsgi socket (doesnt handle ssl termination, there are already enough containers out there), related to Provide a pre-compiled tarball for all static contents #144 but could probably be solved by a multi stage dockerfile
  • split config overwrite folders from data folders
  • log to stdout (Allow for logging to a central location instead of just files. #2, Feature request: redirect log /opt/mailman/var/logs/mailman.log to stdout in mailman-web container #134)
• remove default entries from the docker-compose (hostname, container-name, links)
• try to remove the hard coded subnet and use dns based routing (not sure if feasable but would be awesome) (related Use environment variables for network setup #44)

I'ld be happy to provide PR's for the above points but wanted to get your feedback first, after writing this ticket and finding all the related tickets im pretty sure all the changes are also in your interest, so mainly creating it as todo list for me.

[maxking]

Thanks for your interest in this, I'd love this to happen!

• I think we should keep the full-stack compose as a separate option to the current one, mostly for the folks who need their MTA/Web Server on the host to do other things than just serve Mailman.
• Moving environment variables to .env file doesn't really make a whole lot of sense to me, I understand that you probably want to keep your secrets safer, but unless one is using some Linux permissions to deny access to .env file but not to docker-compose.yaml, it is kind of useless right? And I am not sure how would one go about doing that.
• Adding a postfix container should be a great help, it is unrelated to Consider moving the default MTA to postfix #282 , but we can handle that in a separate MR.
• I think adding an Nginx container that shares a volume with mailman-web would be best. I am not very interested in Provide a pre-compiled tarball for all static contents #144 at the moment, especially because it doesn't really get us much speed up or anything. Generating static files at startup should usually be fine.
• Logging to stdout should be great, Django can probably do that easily, Core might be able to.
• Why do we want to remove the default entries for hostname, container-name, links?
• Removing the hard-coded network stuff is something I really want to do, that might have some challenges based on how Hyperkitty authenticates requests from Core, but we can fix that in upstream too.

Overall, I like most of the ideas. Ideally, we'd want each change to be in their own separate Pull Request and then we can discuss in more details in their respective PRs.

[morbidick]

About the .env file:

• it makes it clear to the enduser which variables should be changed without searching threw the whole docker-compose.yml
• it removes duplicate definitions (like the hyperkitty api key)
• it could/should make it easier to upgrade a docker-compose.yml (since one is using the upstream one) and only has to add/modify changed variables in the local .env
• endusers can check in their running docker-compose.yml into source controle without exposing secrets

I think a PR will make that clearer, its not much work so no hassle if we drop it.

Links are a deprecated feature, by default all containers in a service section are in one network so linked anyway. Hostname and container-name default to the current section in the service definition so the same as currently explicitly defined and i think removing them makes the whole file smaller and therefor easier to understand.

[pgeorgi]

Somewhat related, I integrated these containers into Mailu (https://github.com/Mailu/Mailu) which provides the rest of the stack. Is there interest in such a setup?

[maxking]

@pgeorgi If you already have that integration that you’d like to maintain using these images, I’d be happy to add a link to your repository/post in the documentation.

[morbidick]

@pgeorgi definetly

[pgeorgi]

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

[viktorsmari]

I agree with @morbidick about the .env file, mainly because it makes updating much easier.
You can simply do a git pull without polluting your repo.
Also, the .env file should be in .gitignore

Example: Look at how Sentry does this:
https://github.com/getsentry/onpremise

They also provide an env.example file which you can copy to your own .env file.

[github-actions]

This issue has not been updated for more than 1year