By the way, you may want to generate random passwords used in 'config' file, so that your docker users won't use same passwords.

I just updated README: https://github.com/docker-build/iRedMai … /README.md
Maybe these instructions can help you to understand the process that I am thinking.
I want to do most of the installations during the build phase (when the docker image is built)
and later customize the configuration as needed.

OK, I had missed this.

I'm a bit curious as to what the thinking is behind creating a docker container with iRedAPD, postfix, dovecot, mysql, openldap and apache all stuffed into one container.  It seems to me that this is taking the architecture of a dedicated server or VM and trying to transplant it more or less intact into Docker.

Docker is really about deploying fault tolerant applications that consist of microservices distributed across multiple docker hosts.  The idea being that you can scale individual services, set anti-affinity policies on specific containers, define which containers are allowed to communicate, etc...   Moving a complex application to container space really means rethinking the architecture.

So unless you're deploying microservices that scale (ie clustering) I don't understand what you're trying to do.  Perhaps this isn't a production system and just someone's dev box?

iRedMail's installer by design is somewhat counter to the Docker philosophy.   iRedMail is somewhat of a "super package" which helps you install and manage the many packages which are needed to run a complex mail server.   I think what's needed for iRedMail to run in a Docker environment in any meaningful way is to have a separate installer specifically for containerization and clustered versions of the core components which would reasonably be broken out into separate containers.  At first blush, the logical components to break out into separate pods (microservices) might be:  iRedAPD+Postfix, Dovecot, Amavis+SpamAssassin, Apache+RoundCube, OpenLDAP, MySQL.

Because of the complexity of the interaction between these components  (if it wasn't complex, we wouldn't need iRedMail in the first place), I would suggest that the iRedMail installer be used in conjunction with an orchestration tool like Kubernetes.   This would offload a lot of the funky scripting that you've been discussing and ensure the correct number of each pod is running by monitoring it through the replication controller.   It would also offload a bucket load of other tasks that get fairly complex in the Docker world when you start gluing together numerous containers that need to intercommunicate securely and scale.

I'd be very happy to contribute to work on a project of this nature if I could be of any assistance, but I believe the task is fairly large and probably only of interest to a small number of iRedMail admins.

I suppose this begs the question of what your goals were for trying to run a mail server from a single container.

VMs and containers are fundamentally different beasts with very different approaches to application deployment.  If you want everything running from a single container, what you really want is a VM.   There are lots of virtualization platforms out there without subverting Docker to try to make it act like a VM.

By definition, Docker is "a platform for distributed applications".  Two of the fundamental principles of Docker are that containers should be ephemeral and that a container should only run one process.  Your approach ignores both of these best practice design recommendations, so it's not really suitable as a starting point for a properly containerized mail server deployment.  It might be useful if someone wants to build a Vagrant image though.

So this isn't a matter of preferring complex configurations, simply whether Docker is appropriate as your weapon of choice for deploying your application.    If you're not building a scalable, fault tolerant mail server, Docker is the wrong tool.  If you're not planning to deploy to multiple Docker hosts, you're probably wasting your time breaking iRedMail up into distributed components.   After all, the point of distributed apps is building horizontal scalability.

Everyone is jumping on the Docker bandwagon and you'll find both GitHub and DockerHub littered with bad examples of monolithic apps simply stuffed into a container as if it were a VM appliance.

I suppose the idea of a distributed application and the principle of one process per container is fairly straight forward.   What seems to be less understood is the idea of "ephemeral containers".   This is fundamentally contrary to what we've done traditionally with physical servers and VMs.   Docker evangelists describe this using Bill Baker's analogy of pets versus cattle.  VMs and physical servers were pets which we named and nursed back to health when they were sick.   Containers are cattle which you number and shoot if they get sick.   In other words, you can use a replication manager to spin up multiple horizontal scaling instances of what Kubernetes calls a "pod".   If one dies, you check the number of running instances and fire up another or kill one off if you manage to have more running than what you specified.

So yes, deploying all of the elements of iRedMail as "cattle" would be a big and relatively complicated job, but that's what Docker is intended for.   Once the work was done, this could perhaps open up iRedMail to Enterprise class customers, but arguably that space is completely occupied by MS Exchange and commercial IMAP providers like Google, MS Outlook Live, etc...