Docker Swarm is a container orchestration platform that enables the management of multiple containers across multiple hosts. It provides a simple and easy way to deploy and manage containers, and it also allows the creation of a highly available and scalable environment for running containerized applications.

High availability refers to the ability of a system to remain operational even when some of its components fail. In the context of Docker Swarm, high availability means ensuring that the services and applications running in containers are always available, even if some of the nodes in the cluster fail.

In This Artical we learn about:

• What is Docker Swarm?
• Implementing High Availability with Docker Swarm
• Prerequisites

What is Docker Swarm?

Docker Swarm is a native clustering solution for Docker. It allows you to create a group of Docker hosts that function as a single virtual host. This means that you can create a cluster of multiple Docker hosts and manage them as a single unit.

When you create a Swarm, you can specify how many replicas of a service you want to run. For example, if you have a web service that you want to run on three nodes, you can specify that you want three replicas of the service to be running at all times. If one of the nodes goes down, the Swarm will automatically start a new replica on another node, ensuring that your service is always available.

Docker Swarm also provides features like service discovery, load balancing, scaling, and rolling updates. This allows you to easily deploy and manage multiple services on a cluster of Docker hosts. Additionally, it provides features like service distribution and replica placement strategies that allow you to ensure your services are running on the appropriate nodes, monitoring and logging to track the health and performance of your services, and a lot more features as well.

Docker Swarm is a powerful tool for creating highly available and resilient environments for your applications. It allows you to take advantage of the benefits of Docker while adding the ability to easily manage and scale your services across multiple hosts.

Implementing High Availability with Docker Swarm

Setting up Docker Swarm HA for production is an easy job. It is much simpler than attempting to deploy the Kubernetes HA cluster. However, when deciding which to use, one should consider other criteria. Kubernetes while much more complex compared to Swarm, provides many more functions out of the box. It also requires a slightly different structure for your project.

The entire process of setting up the Docker Swarm HA cluster fits into just a few steps:

• Prepare all nodes
• Initialize the first cluster manager
• Add more manager nodes
• Add worker nodes
• Deploy a web interface
• Deploy the first stack using the web interface

Note: For this process as usual I will use Centos7 as it is my favorite Linux distro. Whichever distribution you choose the steps are very similar. I will be doing this on DigitalOcean.

Prerequisites

3 or more hosts for managers. When planning the Docker Swarm HA cluster for production need to take into account the resiliency of master nodes. Swarm uses the Raft consensus protocol, which is similar to etcd used in Kubernetes. The swarm cluster can keep full functionality only if more than half of all manager nodes are still available. Therefore, if we can tolerate the loss of 1 manager node, then we are required to have 3 managers. If we are okay with losing 2 manager nodes, we must have 5 of them in total. And so on.

Private networking between all manager and worker nodes. It is not a strict requirement. Newer versions of Swarm use SSL encryption for control plane communication. However, it will send data traffic between containers unencrypted. It is possible to configure encryption on the data plane as well, but this needs additional setup. For this example, we will use Digital Ocean private networking, which lets us keep the data plane unencrypted. Access from the Internet to access example applications. And Internet access on all nodes for the installation process and access to Docker resources.

For this example, I will launch 5 nodes. 3 for managers will be named manager1, manager2 and manager3. 2 for workers where our application will be running. Worker nodes will be named worker1 and worker2. All nodes will have a public IP address as all DO hosts come with public IP, but also will have private networking enabled to allow communication between nodes. This will result in each node having 2 interfaces eth0 for public access and eth1 for the private network. Depending on your environment you may only have one interface with a private IP address. This is what happens on AWS, for example.

NOTE: For the production cluster, you should also take care of security. For public access, you ideally should only open ports on which your application will be accessed by legitimate users. Also, it is best not to have public access to your manager nodes at all. You can configure VPN or some other secure approach to access them. For internal communication here is the comprehensive list of ports and protocols used.

Docker Swarm allows you to create a group of Docker hosts that function as a single virtual host. This is useful for a number of reasons, but one of the main advantages is that it allows you to achieve high availability for your applications.

When you create a Swarm, you can specify how many replicas of a service you want to run. For example, if you have a web service that you want to run on three nodes, you can specify that you want three replicas of the service to be running at all times. If one of the nodes goes down, the Swarm will automatically start a new replica on another node, ensuring that your service is always available.

Examples:

Here is a simple example of how to create a Swarm and service in it:

# create a Swarm
docker swarm init


# create a service
docker service create --name my-web-service --replicas 3 -p 80:80 nginx

In the example above, we are creating a Swarm by running the docker swarm init command and then creating a service named my-web-service that runs the nginx image. We are specifying that we want three replicas of the service to be running and that we want to expose port 80 on the host to port 80 on the container.

You can check the status of the service by running the command docker service ls

Swarm also allows load balancing and scaling on demand if there is a spike in your traffic.

Another key advantage of using a Swarm is that it allows you to easily update your services. When you update a service in a Swarm, the new version of the service is rolled out to all of the replicas, ensuring that there is no disruption to your users.

Overall, using Docker Swarm can be a great way to achieve high availability for your applications. It allows you to run multiple replicas of service, automatically handle failover, and easily update your services.

Another important feature of Docker Swarm is the ability to distribute services across multiple nodes. This is achieved through the use of “labels” and “constraints”, which allow you to specify which nodes a service should run on based on certain criteria.

For example, you can use labels to specify that a service should only run on nodes that have a specific amount of memory or CPU. This can be useful in situations where you have nodes with different hardware configurations and want to ensure that your services are running on the most appropriate nodes.

Here is an example of how you might use labels and constraints to distribute a service across multiple nodes:

# add a label to a node
docker node update --label-add type=memory-intensive node1


# create a service that is constrained to run on nodes with the 'type=memory-intensive' label
docker service create --name my-memory-intensive-service --constraint node.labels.type==memory-intensive -p 80:80 nginx

In this example, we are adding a label of “type=memory-intensive” to the “node1” node. Then we are creating a service named “my-memory-intensive-service” that is constrained to run on nodes with the “type=memory-intensive” label, this way you can make sure that the service is running only on nodes that are capable of handling it.

Also, you can use replica placement strategies to distribute your services evenly across multiple nodes, or you can use the “spread” strategy to place replicas of your service on different nodes. This can help ensure that your services are not running on a single node, which can help improve availability and resilience.

Additionally, you can use Docker stack to deploy multi-container applications, It simplifies the process of running multiple services together and makes it easier to manage them as a single unit.

Docker Swarm also has an inbuilt feature for monitoring and logging, that could be used to track the health and performance of your services.

Conclusion:

Docker Swarm is a powerful tool for achieving high availability for your applications. It provides features like service replication, automatic failover, and service updates, as well as advanced features like service distribution and replica placement strategies, monitoring, and logging. With Docker Swarm, you can easily create a highly available and resilient environment for your applications.