search

instrumentisto / docker-mailserver

Docker containers for mailserver components
MIT License
8 stars 2 forks source link

TBD first release #6

Open tyranron opened 7 years ago

tyranron commented 7 years ago

Roadmap

LorbusChris commented 7 years ago

Regarding the Kubernetes example: You might be able to easily convert your docker compose to Kubernetes resources with kompose convert

tyranron commented 7 years ago

@LorbusChris thank you for your advice.

AFAIK kompose deploys containers as separate Pods/Services. This is not always desirable and hardly depends on what kind of deployment exactly you want to achieve. For simple installation I'd rather pack everything into single Pod, which simplifies maintance of whole containers set (single lifecycle, resolving each other via localhost). For more complex installation (and for HA) it's reasonable to decouple Postfix and its friends (milters, AMaViS, ClamAV) from Dovecot and even scale.
Also, Kubernetes has multiple ways to expose Service to outside world.
That's why this is not so straightforward and simple as in docker-compose.yml.

LorbusChris commented 7 years ago

Thanks for the answer, @tyranron, sounds totally sensible. I forgot to say that earlier, but it seems like real good work you're doing around here =)

I've been looking at the other repos in this org and one question came to mind: Is there any special reason why you build from source instead of simply installing the distro packages? (like it's done in the Dockerfiles in this repo)

Also, I recently stumbled upon two other things that might be of interest to you for kubernetes support (in case you haven't heard of them, yet):

APBs (see https://github.com/fusor/ansible-playbook-bundle) They are a new standard way to package Kubernetes Apps using Ansible (for use with Service Catalog).

and:

https://github.com/tnozicka/openshift-acme which allows one to automatically get Let's Encrypt Certs for containers on startup and then store them as Kubernetes Secrets for use in the containers. This led me to think that in Kubernetes, config management would be easily possible leveraging Kube ConfigMaps and Secrets, probably making it possible to drop some code in the Dockerfiles for copying over custom configs.

Personally, I am very interested in a solution that runs on Kubernetes, is easily scalable yet runnable on a one machine setup (i.e. all in one pod) and that leverages all of Kubes capabilities for config management, logging and storage. As I see it, this would be quite different than the current approach and require refactoring, but nonetheless I want to ask if this is at all coherent with your vision for this project and something you will be focussing on in the future? If so, how can I help and where should I start?

tyranron commented 7 years ago

@LorbusChris wow, that's a lot to discuss! Thank you for appreciating my work and giving advices!

Now, let's see...

Is there any special reason why you build from source instead of simply installing the distro packages? (like it's done in the Dockerfiles in this repo)

Usually we're using official Docker Hub images for everything. But for this software there is no official images. That's why they are built in a manner of official images. They almost all are compiled from sources. This has some advantages:

  1. Flexibility in compiling software. This is often useful for compiled-in plugins. We can precisely decide what we want to compile and compile plugins that may be absent in distro packages.
  2. Single filesystem layout. Software in Alpine packages and Debian packages quite often have different directories layout (/var/run vs /run, etc). This can end in some fuck-up situation if someone migrates from Debian-based image to Alpine-based (or vice versa). With compiling stuff from scratch we can guarantee same layout for different image versions.
  3. Possibility to upgrade to newer version whenever we want and do not wait until distro maintainer will upgrade their packages. Some times distro packages just do not contain latest versions. Sometimes there is need to maintain multiple major/minor versions of software.

APBs (see https://github.com/fusor/ansible-playbook-bundle)

AFAIK, nowadays the Helm is a de-facto standard.
However, in our Kubernetes installations we are using pure Ansible to template Kubernetes specs and keeping secrets encrypted. The reason is that we started with Kubernetes before Helm was released. And still Ansible is much more comfortable in our own environment. But for sharing code in public I'd rather recommend use Helm.

https://github.com/tnozicka/openshift-acme which allows one to automatically get Let's Encrypt Certs for containers on startup and then store them as Kubernetes Secrets

Yup. We are using Kube-lego for that purposes. It does quite the same job.

This led me to think that in Kubernetes, config management would be easily possible leveraging Kube ConfigMaps and Secrets

And it is! I can confirm that in Kubernetes a config management is something great, because it's simple and "just works well".

probably making it possible to drop some code in the Dockerfiles for copying over custom configs.

Actually, configuration must not be built into container and Dockerfile is not a place for configuration. It's an anti-pattern. It's quite the same if we hardcode some data into source code directly instead of passing it in runtime. And, as you mentioned above, Kubernetes with its ConfigMaps and Secrets does its best to make users avoid doing that.
However, there is one exception named default configuration. Default configuration can (and should) be tuned up in Dockerfile to satisfy different stuff that is related to Docker environments (like logging to STDOUT, etc). Also, sometimes, there is a good practice to tune up security settings to have image settings being "secure by default". This, usually, does not break the way the image is used, but frees image users from some boilerplate configuration in every image installation.

Personally, I am very interested in a solution that runs on Kubernetes, is easily scalable yet runnable on a one machine setup (i.e. all in one pod) and that leverages all of Kubes capabilities for config management, logging and storage. As I see it, this would be quite different than the current approach and require refactoring,

The point of this project is to provide a set of basic images and to show how to use them in Docker Way (one container - one process). Having simple images and configs, the mailserver can be reproduced in any containerized environment, not just Kubernetes.

But I really don't see the way that concrete mailserver configuration can satisfy any mailserver installation requirements. Even in Kubernetes. There is no way for single pod to provide a HA installation, and vice versa - HA installation cannot be deployed on a single machine.

The best we can do is to provide enough examples for people to make them understand how they can build their own mailserver from our containers.
Also, maybe there is a sense to provide some Helm charts for the most common mailserver installations.

fff0x commented 6 years ago

@tyranron I appreciate your work, do you have any plans for carry on this great project? Maybe I can help you with something?