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.