Docker-mailman: Fullstack docker-compose

Created on 4 Jan 2019 · 7Comments · Source: maxking/docker-mailman

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 #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 #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 #144 but could probably be solved by a multi stage dockerfile
- split config overwrite folders from data folders
- log to stdout (#2, #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 #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.

Source

morbidick

👍3

Most helpful comment

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

pgeorgi on 12 Jan 2019

❤4

All 7 comments

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 #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 #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.

maxking on 10 Jan 2019

👍1

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.

morbidick on 10 Jan 2019

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?

pgeorgi on 11 Jan 2019

@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.

maxking on 12 Jan 2019

@pgeorgi definetly

morbidick on 12 Jan 2019

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

pgeorgi on 12 Jan 2019

❤4

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.