From 6bd365e7714e765c75d8fdd93bc04065a53eae14 Mon Sep 17 00:00:00 2001 From: ofthesun9 Date: Mon, 8 Oct 2018 21:00:44 +0000 Subject: [PATCH] Change title layout --- docs/swarm/master/README.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/swarm/master/README.md b/docs/swarm/master/README.md index c09f1dd3..2a2a021a 100644 --- a/docs/swarm/master/README.md +++ b/docs/swarm/master/README.md @@ -56,12 +56,12 @@ core@coreos-01 ~ $ sudo umount /mnt/local/ ``` -### Networking mode +## Networking mode On this example, we are using: - the mesh routing mode (default mode). With this mode, each service is given a virtual IP adress and docker manages the routing between this virtual IP and the container(s) providing this service. - the default ingress mode. -## Allow authentification with the mesh routing +### Allow authentification with the mesh routing In order to allow every (front & webmail) container to access the other services, we will use the variable POD_ADDRESS_RANGE. Let's create the mailu_default network: @@ -73,7 +73,7 @@ core@coreos-01 ~ $ docker network inspect mailu_default | grep Subnet In the docker-compose.yml file, we will then use POD_ADDRESS_RANGE = 10.0.1.0/24 In fact, imap & smtp logs doesn't show the IPs from the front(s) container(s), but the IP of "mailu_default-endpoint". So it is sufficient to set POD_ADDRESS_RANGE to this specific ip (which can be found by inspecting mailu_default network). The issue is that this endpoint is created while the stack is created, I did'nt figure a way to determine this IP before the stack creation... -## Limitation with the ingress mode +### Limitation with the ingress mode With the default ingress mode, the front(s) container(s) will see origin IP(s) all being 10.255.0.x (which is the ingress-endpoint, can be found by inspecting the ingress network) This issue is known and discussed here: @@ -84,22 +84,22 @@ A workaround (using network host mode and global deployment) is discussed here: https://github.com/moby/moby/issues/25526#issuecomment-336363408 -## Don't create an open relay ! +### Don't create an open relay ! As a side effect of this ingress mode "feature", make sure that the ingress subnet is not in your RELAYHOST, otherwise you would create an smtp open relay :-( -### Scalability +## Scalability - smtp and imap are scalable - front and webmail are scalable (pending POD_ADDRESS_RANGE is used), although the let's encrypt magic might not like it (race condidtion ? or risk to be banned by let's encrypt server if too many front containers attemps to renew the certs at the same time) - redis, antispam, antivirus, fetchmail, admin, webdav have not been tested (hence replicas=1 in the following docker-compose.yml file) -### Variable substitution and docker-compose.yml +## Variable substitution and docker-compose.yml The docker stack deploy command doesn't support variable substitution in the .yml file itself (but we still can use .env file to pass variables to the services). As a consequence we need to adjust the docker-compose file in order to : - remove all variables : $VERSION , $BIND_ADDRESS4 , $BIND_ADDRESS6 , $ANTIVIRUS , $WEBMAIL , etc - change the way we define the volumes (nfs share in our case) - add a deploy section for every service -### Docker compose +## Docker compose An example of docker-compose-stack.yml file is available here: ```yaml @@ -340,7 +340,7 @@ volumes: device: ":/mnt/Pool1/pv/mailu/redis" ``` -### Deploy Mailu on the docker swarm +## Deploy Mailu on the docker swarm Run the following command: ```bash docker stack deploy -c docker-compose-stack.yml mailu @@ -359,7 +359,7 @@ ID NAME IMAGE NODE tbu8ppgsdffj mailu_fetchmail.1 mailu/fetchmail:1.5 coreos-01 Running Running 11 days ago ``` -### Remove the stack +## Remove the stack Run the follwoing command: ```bash core@coreos-01 ~ $ docker stack rm mailu