Added recipe on docker-mailserver

docs/ha-docker-swarm/design.md

@@ -1,4 +1,4 @@
-# Introduction
+# Design
 
 In the design described below, the "private cloud" platform is:
 
@@ -35,7 +35,7 @@ Under this design, the only inbound connections we're permitting to our docker s
 
 ### Authentication
 
-* Where the proxied application provides a trusted level of authentication, or where the application requires public exposure, 
+* Where the proxied application provides a trusted level of authentication, or where the application requires public exposure,
 
 
 ## High availability

docs/ha-docker-swarm/docker-swarm-mode.md

@@ -1,4 +1,4 @@
-# Introduction
+# Docker Swarm Mode
 
 For truly highly-available services with Docker containers, we need an orchestration system. Docker Swarm (as defined at 1.13) is the simplest way to achieve redundancy, such that a single docker host could be turned off, and none of our services will be interrupted.
 

docs/ha-docker-swarm/keepalived.md

@@ -1,4 +1,4 @@
-# Introduction
+# Keepalived
 
 While having a self-healing, scalable docker swarm is great for availability and scalability, none of that is any good if nobody can connect to your cluster.
 

docs/ha-docker-swarm/shared-storage-ceph.md

@@ -1,4 +1,4 @@
-# Introduction
+# Shared Storage (Ceph)
 
 While Docker Swarm is great for keeping containers running (_and restarting those that fail_), it does nothing for persistent storage. This means if you actually want your containers to keep any data persistent across restarts (_hint: you do!_), you need to provide shared storage to every docker node.
 

docs/ha-docker-swarm/shared-storage-gluster.md

@@ -1,4 +1,4 @@
-# Introduction
+# Shared Storage (GlusterFS)
 
 While Docker Swarm is great for keeping containers running (_and restarting those that fail_), it does nothing for persistent storage. This means if you actually want your containers to keep any data persistent across restarts (_hint: you do!_), you need to provide shared storage to every docker node.
 

docs/ha-docker-swarm/traefik.md

@@ -1,4 +1,4 @@
-# Introduction
+# Traefik
 
 The platforms we plan to run on our cloud are generally web-based, and each listening on their own unique TCP port. When a container in a swarm exposes a port, then connecting to **any** swarm member on that port will result in your request being forwarded to the appropriate host running the container. (_Docker calls this the swarm "[routing mesh](https://docs.docker.com/engine/swarm/ingress/)"_)
 
@@ -21,7 +21,7 @@ The traefik container is aware of the __other__ docker containers in the swarm,
 
 Run the following to build and activate policy to permit containers to access docker.sock:
 
-````
+```
 mkdir ~/dockersock
 cd ~/dockersock
 curl -O https://raw.githubusercontent.com/dpw/\
@@ -29,7 +29,7 @@ selinux-dockersock/master/Makefile
 curl -O https://raw.githubusercontent.com/dpw/\
 selinux-dockersock/master/dockersock.te
 make && semodule -i dockersock.pp
-````
+```
 
 ### Prepare traefik.toml
 

docs/ha-docker-swarm/vms.md

@@ -1,4 +1,4 @@
-# Introduction
+# Virtual Machines
 
 Let's start building our cloud with virtual machines. You could use bare-metal machines as well, the configuration would be the same. Given that most readers (myself included) will be using virtual infrastructure, from now on I'll be referring strictly to VMs.