From f7e37b7d4b4c8aa85920bd9aebf7b78bc3271752 Mon Sep 17 00:00:00 2001 From: Ionut Filip Date: Fri, 11 Jan 2019 16:25:32 +0200 Subject: [PATCH 1/4] Removed unbound resolver for stack flavor --- setup/flavors/stack/docker-compose.yml | 25 ---------------------- setup/templates/steps/stack/03_expose.html | 7 ------ 2 files changed, 32 deletions(-) diff --git a/setup/flavors/stack/docker-compose.yml b/setup/flavors/stack/docker-compose.yml index 480aafeb..e1382d20 100644 --- a/setup/flavors/stack/docker-compose.yml +++ b/setup/flavors/stack/docker-compose.yml @@ -31,15 +31,6 @@ services: deploy: replicas: {{ front_replicas }} - {% if resolver_enabled %} - resolver: - image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}unbound:${MAILU_VERSION:-{{ version }}} - env_file: {{ env }} - networks: - default: - ipv4_address: {{ dns }} - {% endif %} - admin: image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}admin:${MAILU_VERSION:-{{ version }}} env_file: {{ env }} @@ -69,10 +60,6 @@ services: - "{{ root }}/overrides:/overrides" deploy: replicas: {{ smtp_replicas }} - {% if resolver_enabled %} - dns: - - {{ dns }} - {% endif %} antispam: image: ${DOCKER_ORG:-mailu}/${DOCKER_PREFIX:-}rspamd:${MAILU_VERSION:-{{ version }}} @@ -83,10 +70,6 @@ services: - "{{ root }}/overrides/rspamd:/etc/rspamd/override.d" deploy: replicas: 1 - {% if resolver_enabled %} - dns: - - {{ dns }} - {% endif %} # Optional services {% if antivirus_enabled %} @@ -97,10 +80,6 @@ services: - "{{ root }}/filter:/data" deploy: replicas: 1 - {% if resolver_enabled %} - dns: - - {{ dns }} - {% endif %} {% endif %} {% if webdav_enabled %} @@ -121,10 +100,6 @@ services: - "{{ root }}/data:/data" deploy: replicas: 1 - {% if resolver_enabled %} - dns: - - {{ dns }} - {% endif %} {% endif %} {% if webmail_type != 'none' %} diff --git a/setup/templates/steps/stack/03_expose.html b/setup/templates/steps/stack/03_expose.html index 820ff154..5377d3bd 100644 --- a/setup/templates/steps/stack/03_expose.html +++ b/setup/templates/steps/stack/03_expose.html @@ -3,13 +3,6 @@ and let users access their mailboxes. Mailu has some flexibility in the way you expose it to the world.

-
- -
-
Date: Thu, 17 Jan 2019 14:17:44 +0200 Subject: [PATCH 2/4] Unbound docs for Swarm --- docs/swarm/master/README.md | 41 +++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/docs/swarm/master/README.md b/docs/swarm/master/README.md index 61319cfd..d03ba562 100644 --- a/docs/swarm/master/README.md +++ b/docs/swarm/master/README.md @@ -250,3 +250,44 @@ Run the follwoing command: ```bash core@coreos-01 ~ $ docker stack rm mailu ``` + +## Notes on unbound resolver + +In Docker compose flavor we currently have the option to include the unbound DNS resolver. This does not work in Docker Swarm, as it in not possible to configure any static IP addresses. There is an [open issue)](https://github.com/moby/moby/issues/24170]) on this over at Docker. However, this doesn't seem to move anywhere since some time now. For that reasons we've chosen not to include the unbound resolver in the stack flavor. + +If you still want to benefit from Unbound as a system resolver, you can install it system-wide. The following procedure was done on a Fedora 28 system and might needs some adjustments for your system. Note that this will need to be done on every swarm node. In this example we will make use of `dnssec-trigger`, which is used to configure unbound. When installing this and running the service, unbound is pulled in as dependency and does not need to be installed, configured or run separately. + +Install required packages(unbound will be installed as dependency): + +``` +sudo dnf install dnssec-trigger +``` + +Enable and start the *dnssec-trigger* daemon: + +``` +sudo systemctl enable --now dnssec-triggerd.service +``` + +Configure NetworkManager to use unbound, create the file `/etc/NetworkManager/conf.d/unbound.conf` with contents: + +``` +[main] +dns=unbound +``` + +You might need to restart NetworkManager for the changes to take effect: + +``` +sudo systemctl restart NetworkManager +``` + +Verify `resolv.conf`: + +``` +$ cat /etc/resolv.conf +# Generated by dnssec-trigger-script +nameserver 127.0.0.1 +``` + +Most of this info was take from this [Fedora Project page](https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test). From 711f2bcfaf73f59d60f21a855b05c48f65437829 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20M=C3=B6hlmann?= Date: Thu, 17 Jan 2019 15:01:33 +0200 Subject: [PATCH 3/4] Docker swarm warnings --- docs/swarm/master/README.md | 38 +++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/docs/swarm/master/README.md b/docs/swarm/master/README.md index d03ba562..39baebc5 100644 --- a/docs/swarm/master/README.md +++ b/docs/swarm/master/README.md @@ -1,5 +1,43 @@ # Install Mailu on a docker swarm +## Some warnings + +### How Docker swarm works + +Docker swarm enables replication and fail-over scenarios. As a feature, if a node dies or goes away, Docker will re-schedule it's containers on the remaining nodes. +In order to take this decisions, docker swarm works on a consensus between managers regarding the state of nodes. Therefore it recommends to always have an uneven amount of manager nodes. This will always give a majority on either halve of a potential network split. + +### Storage + +On top of this some of Mailu's containers heavily rely on disk storage. As noted below, every host will need the same dataset on every host where related containers are run. So Dovecot IMAP needs `/mailu/mail` replicated to every node it *may* be scheduled to run. There are various solutions for this like NFS and GlusterFS. + +### When disaster strikes + +So imagine 3 swarm nodes and 3 GlusterFS endpoints: + +``` +node-A -> gluster-A --| +node-B -> gluster-B --|--> Single file system +node-C -> gluster-C --| +``` + +Each node has a connection to the shared file system and maintains connections between the other nodes. Let's say Dovecot is running on `node-A`. Now a network error / outage occurs on the route between `node-A` and the remaining nodes, but stays connected to the `gluster-A` endpoint. `node-B` and `node-C` conclude that `node-A` is down. They reschedule Dovecot to start on either one of them. Dovecot starts reading and writing its indexes to the **shared** filesystem. However, it is possible the Dovecot on `node-A` is still up and handling some client requests. I've seen cases where this situations resulted in: + +- Retained locks +- Corrupted indexes +- Users no longer able to read any of mail +- Lost mail + +### It gets funkier + +Our original deployment also included `main.db` on the GlusterFS. Due to the above we corrupted it once and we decided to move it to local storage and restirct the `admin` container to that host only. This inspired us to put some legwork is supporting different database back-ends like MySQL and PostgreSQL. We highly recommend to use either of them, in favor of sqlite. + +### Conclusion + +Although the above situation is less-likely to occur on a stable (local) network, it does indicate a failure case where there is a probability of data-loss or downtime. It may help to create redundant networks, but the effort might be too much for the actual results. We will need to look into better and safer methods of replicating mail data. For now, we regret to have to inform you that Docker swarm deployment is **unstable** and should be avoided in production environments. + +-- @muhlemmer, 17th of January 2019. + ## Prequisites ### Swarm From d593c783a3d6299333dea895d82c1921aad62663 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20M=C3=B6hlmann?= Date: Thu, 17 Jan 2019 18:22:16 +0200 Subject: [PATCH 4/4] Fix typo in link --- docs/swarm/master/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/swarm/master/README.md b/docs/swarm/master/README.md index 39baebc5..58723c33 100644 --- a/docs/swarm/master/README.md +++ b/docs/swarm/master/README.md @@ -291,7 +291,7 @@ core@coreos-01 ~ $ docker stack rm mailu ## Notes on unbound resolver -In Docker compose flavor we currently have the option to include the unbound DNS resolver. This does not work in Docker Swarm, as it in not possible to configure any static IP addresses. There is an [open issue)](https://github.com/moby/moby/issues/24170]) on this over at Docker. However, this doesn't seem to move anywhere since some time now. For that reasons we've chosen not to include the unbound resolver in the stack flavor. +In Docker compose flavor we currently have the option to include the unbound DNS resolver. This does not work in Docker Swarm, as it in not possible to configure any static IP addresses. There is an [open issue](https://github.com/moby/moby/issues/24170) for this at Docker. However, this doesn't seem to move anywhere since some time now. For that reasons we've chosen not to include the unbound resolver in the stack flavor. If you still want to benefit from Unbound as a system resolver, you can install it system-wide. The following procedure was done on a Fedora 28 system and might needs some adjustments for your system. Note that this will need to be done on every swarm node. In this example we will make use of `dnssec-trigger`, which is used to configure unbound. When installing this and running the service, unbound is pulled in as dependency and does not need to be installed, configured or run separately.