1 (edited by bmackay 2018-01-18 05:18:18)

Topic: iRedmail and Docker - Architecture Proposal

I'm about to begin the rebuild of our customer email environment and thought I'd share a few ideas.

The plan here is to containerize the full email stack architected as a proper Docker distributed application.  I have seen a few email system Docker images where the author has really just stuffed everything into a single monolithic container.  There is little point to this approach as it defies 90% of what Docker was designed to do.  Docker is not a virtualization solution.  We have lots of VM options out there already.

It occurred to me as I was drafting the architectural diagram for our deployment that, if ZHB were to move to solely building iRedMail and iRedAdmin-Pro as distributed containers, it would radically simplifyy the support matrix.   Docker runs on almost any platform, even Windows, so there would be no need to support five different Linux variants.  Just pick one distro that has a lean base install.   I'd take this a step farther and suggest that there's no need to support both Postgres and MySQL.  You need LDAP, but I suspect the use case for demanding a particular flavour of containerized database is somewhat on the edge.  If you want MySQL for other apps, whether monolithic or containerized, it doesn't stop you from using Postgres for your mail app.    Ditto for web servers, but Apache has already been dropped from the iRedMail matrix.

Our plan is to use CentOS running on Atomic hosts.   The choice of which Linux distro to choose for iRedMail is largely irrelevant to everyone except ZHB, as the developer.  The choice of host platform is irrelevant to ZHB and entirely up to the admin setting up the environment. 

The primary goal of the architectural change from my perspective, is to create discrete services which can be independently scaled, upgraded, switched out.  If you're getting hammered on the front end, fire up a second web or app container.  If your filters are slowing down delivery, spin up another filter container.  These containers are disposable, so they can be created and destroyed on demand.  Only the storage is persistent.

Configuration can be largely driven by a single docker-compose.yml file.  Any tweaks can be covered off with a bit of additional Python or Bash scripting.  Orchestration can be handled through manual scripts or through tools like Kubernetes.

iRedMail becomes even more of a turnkey solution, becomes far more scalable and it opens up more hosting platforms, including Windows, while simplifying the support matrix at the same time.

Post's attachments

iRedmail_Docker.png
iRedmail_Docker.png 115.96 kb, 2 downloads since 2018-01-17 

You don't have the permssions to download the attachments of this post.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: iRedmail and Docker - Architecture Proposal

You're right, i will start working on Docker in few months.

Your proposal is very good, and here's still room for improvement.

After deployed load-balance iRedMail cluster (with Ansible) for customers, and move iRedMail installer from shell script to Ansible (not yet published), i found some tweaks required to get a better scaleable mail server and easier for sysadmin to maintain, it will split core config files and allow sysadmins to maintain their own modular config files without modifying those core config files maintained by iRedMail. I will roll out these changes one-by-one in iRedMail-1.0 and later releases.

3

Re: iRedmail and Docker - Architecture Proposal

That was just a first draft.  Of course, the "private" LDAP or DB containers could be exposed by the admin, but I think the default should be to only make them accessible via the Docker network.

I specified Memcached, only because I believe SOGo is using it.  I think for 2018, perhaps Redis is a better choice.

I didn't address load balancing as many cloud hosting providers have turnkey solutions available. 

I also didn't include Varnish or any sort of front end cache as I think for mail systems, there's limited HTTP cache opportunities.

You know how to reach me if you want to bounce any ideas around or want someone to beta test.  I'm rarely on these forums.

4

Re: iRedmail and Docker - Architecture Proposal

bmackay wrote:

I specified Memcached, only because I believe SOGo is using it.  I think for 2018, perhaps Redis is a better choice.

SOGo uses memcached. But it doesn't support redis. So it's not our choice.

bmackay wrote:

I didn't address load balancing as many cloud hosting providers have turnkey solutions available. 

HAProxy is very easy to setup, it's also a good choice.

bmackay wrote:

You know how to reach me if you want to bounce any ideas around or want someone to beta test.  I'm rarely on these forums.

I may not have enough time for Docker soon, i'd like to know how we can work together to make it happen.

5

Re: iRedmail and Docker - Architecture Proposal

Personally, I would prefer not running iRedmail in a docker-container, but if the option exist for other people that would be great!

6 (edited by Kawaii 2018-02-01 08:27:08)

Re: iRedmail and Docker - Architecture Proposal

+1 for Docker! I would love to see the project become Docker-based or at least offer it as an option. With regards to the comments about SQL - I think that SQL support should still be kept and maintained along with LDAP, but perhaps only PostgreSQL? Surely there aren't people using MySQL in critical production environments? tongue

My suggestion would be to use Debian 9 (Stretch) as the base image for the new Dockerfiles, iRedMail works very well on this platform - I use it myself. big_smile

If you're looking for help with this I've got a great deal of experience with Docker and Docker Compose/Swarm and would love to help out or offer guidance/advice any way I can. smile

7

Re: iRedmail and Docker - Architecture Proposal

Hi @Kawaii,

*) How about start working on a iRedMail Docker? i will help review the iRedMail part as much as i can.

Another user built a docker here:
https://hub.docker.com/r/lejmr/iredmail/

*) We will continue supporting OpenLDAP, MySQL/MariaDB, PostgreSQL.

Currently MySQL/MariaDB has most users.

8

Re: iRedmail and Docker - Architecture Proposal

ZhangHuangbin wrote:

*) How about start working on a iRedMail Docker? i will help review the iRedMail part as much as i can.

Another user built a docker here:
https://hub.docker.com/r/lejmr/iredmail/

Perhaps next week or after that I might be able to start prototyping something, with the services split between different containers where appropriate. I will need some time to examine the installation scripts for iRedMail in order to properly understand how it all works first. smile

I will keep you guys updated if I start work on anything!

9

Re: iRedmail and Docker - Architecture Proposal

Cool, feel free to post your questions in this forum. smile

10

Re: iRedmail and Docker - Architecture Proposal

@bmackay, please reach out to me via email <kane (AT) cute (DOT) im> if this is something you'd like to assist with. I'm confident enough with Docker as a tool, but iRedMail is quite an ambitious project to even just prototype. smile

11

Re: iRedmail and Docker - Architecture Proposal

Do you have any detailed plan to implement iRedMail in Docker now?

*) Are you going to implement a MySQL/PGSQL multi-master cluster in Docker? Or just one standalone MySQL/PGSQL server?
*) Are you going to split different softwares to different dockers, or use only one docker with all components (Postfix, Dovecot, MySQL, Nginx, Roundcube, etc)?

12 (edited by Kawaii 2018-02-06 04:48:23)

Re: iRedmail and Docker - Architecture Proposal

ZhangHuangbin wrote:

Do you have any detailed plan to implement iRedMail in Docker now?

Somewhat, I've created a blank project skeleton in a GitHub repository here:

https://github.com/kawaii/iredmail-docker
https://github.com/kawaii/iredmail-dock … ompose.yml

I don't tend to commit very often, so it is likely you might see long gaps of inactivity in the repository between my pushes. Though, I can commit more often and we can make PRs on various sections of the project if anyone would like to help out with this. I will still spend a lot more time just reading through the various installation scripts for iRedMail and deciding how best to split it up. smile

ZhangHuangbin wrote:

*) Are you going to implement a MySQL/PGSQL multi-master cluster in Docker? Or just one standalone MySQL/PGSQL server?

Users will use environment variables to set the hostname, port, user, password and database of the system they want to connect to. I can provide example docker-compose.yml files for both MySQL and PostgreSQL stacks too. The default will be a single PostgreSQL container, but advanced users are of course able to deploy their own cluster with multi-master replication and use the environment variables to tell iRedMail to use that cluster if they want to.

ZhangHuangbin wrote:

*) Are you going to split different softwares to different dockers, or use only one docker with all components (Postfix, Dovecot, MySQL, Nginx, Roundcube, etc)?

As you can see from the repository skeleton above, I plan to split as many of the components as possible into different containers, this is the purpose of Docker after all. smile One issue I forsee is with the Roundcube (and any other PHP things) is that it is impossible for PHP-FPM to serve static content from a pure PHP container over to the nginx container unless they share a volume, but that makes it Docker Swarm unfriendly, so Roundcube is likely one of the last components I decide to figure out. iRedAdmin itself is a Python application, so upstreaming to that service remotely over a network is possible by default. big_smile

Please feel free to either email me with suggestions or if you want to work on this with me I'm happy to give you any help too. Unfortunately I do work full-time during the day (GMT+0) so progress on this will be slow, so if at any time you wish to take over, please do so. wink

13 (edited by Clouseau 2018-02-06 05:01:38)

Re: iRedmail and Docker - Architecture Proposal

What selea said. And to add - you cannot just switch to container based enviroment only, bmackay. iRedMail is installed on a lot of servers (hardware, not just vps) and the project is present for a long time. Also some servers do other stuff, not just mail. Ditching everything and going with docker would just make too much problems on current implemetations, not to mention problems with migrations to new environment...

14

Re: iRedmail and Docker - Architecture Proposal

Kawaii wrote:

One issue I forsee is with the Roundcube (and any other PHP things) is that it is impossible for PHP-FPM to serve static content from a pure PHP container over to the nginx container unless they share a volume, but that makes it Docker Swarm unfriendly, so Roundcube is likely one of the last components I decide to figure out.

For php applications like Roundcube, you may have to run Nginx + php-fpm + application in one docker.

15

Re: iRedmail and Docker - Architecture Proposal

Would be sweet to add Lets Encrypt next to the iRedMail smile

16 (edited by GuiltyNL 2018-06-14 21:52:54)

Re: iRedmail and Docker - Architecture Proposal

selea wrote:

Personally, I would prefer not running iRedmail in a docker-container, but if the option exist for other people that would be great!

Good that I'm not the only one. I evaluated Mail Cow Dockerized last week and I feel handicapped. For me I don't want to master the Docker principles and I don't see advantages for normal usage.

I was just happy to find iRedMail as a normal server suite that just installs on a server. I dont want to run docker and maintain containers.

I don't see the hype or the advantage of running a mail server in Docker? What do I miss?

17

Re: iRedmail and Docker - Architecture Proposal

I have to agree with @selea, @Clouseau and @GuiltyNL. Sure, provide Docker as an option or fork it or whatever for those who want it, but for the rest of us running production mail servers and happy with the current way of doing things, if it ain't broke, don't fix it.

Sure, there are advantages to Docker, but they are not absolute across the board, and the Internet is not a command economy. I'm not against progress, of course, but throwing out the baby with the bath water makes no sense.