What is Docker Swarm ?
Docker Swarm is a container orchestration tool offered by Docker which provides cluster management and orchestration features embedded in the Docker Engine. Docker Swarm Mode, which was released in 2016, includes enhanced container services that has been optimised for clusters. This functionality allows applications to be easily deployed and scaled across the cluster with minimal effort and provides great efficiency.
Though it is not as powerful as some of its competitors like the very popular Kubernetes, it serves to be sufficient for the deployment and scaling of relatively large apps. We will discuss some key differences between Kubernetes and Docker Swarm later in the article.
Here is the link to the official documentation for your reference.
Note: A basic knowledge of Docker is required for this article.
Docker overview
Docker is an open platform for developing, shipping and running applications. It enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in a similar way to how you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing, and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.
In simple words, Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to wrap an application with the required components like libraries and other dependencies and it ships it all out as one package.
Basic Docker terminology 🐳
Here are some basic Docker terminologies:
Docker Image -> It is Blueprint of the Docker Container. For shipping any app, the image of the application needs to be created. The Docker imange provides a convenient way to package applications and other preconfigured server environments to make development much more streamlined.
Docker Container -> A Docker container is a running instance of a Docker Image. Simply put, the Docker image is pulled from a registry and it is executed as a container.
Must know terms in Docker Swarm
A node can be understood as an individual machine or as aDocker host present in the swarm cluster. Nodes can further be classified into two types:
Manager Nodes which assign tasks and place containers on different nodes based on the requirements and can be understood as the central controlling unit of the entire swarm cluster.
Worker nodes are the ones on which the various tasks are scheduled. The worker node notifies the manager node of the current state of its assigned tasks so that the manager can maintain the desired state of each worker. By default, manager nodes also run services as worker nodes but this can be configured.
Services in Docker Swarm are the applications or programs that need to be deployed and scaled; they can be deployed as one or more replicas (the number of instances of a service that needs to be run). A replicated service is one that is placed based on constraints and with the exact specification of the number of replicas. Meanwhile, global services are those that runs one replica on each node (for example, any metric collecting agent)
A task is the individual instance of a running service that the OS has scheduled onto a swarm node with the container acting as the instantiation of the task. If an HTTP listener task subsequently fails its health check or crashes, the orchestrator creates a new replica task that spawns a new container by progressing the task through a series of states: assigned, prepared, running, etc.
Now, let us try to understand docker swarm with the help of an example. Say we have one manager node(M1) and three worker nodes(W1, W2, W3) inside the swarm cluster and two simple dockerised applications (A1, A2) which need deployment (A1 requiring 3 instances and A2 requiring 2 instances). In such cases, we will simply launch A1 and A2 as services with the required number of replicas onto the swarm. Docker Swarm is smart enough to properly load balance all the tasks in the most efficient way onto the worker nodes. Now say, W3 node becomes unhealthy, then the tasks running on it will be redistributed to the remaining healthy worker nodes.
Important Note
Placement constraints can be applied to the services so that they get scheduled only on required worker nodes.
As discussed above, Manager nodes can be delegated to run only manager related work or can also
run services like a worker node.
It is recommended to have an odd and more than two number of managers to allow the cluster to operate even in case of failure of some manger nodes. Please read this documentation to understand the effective management of manager nodes in a swarm cluster.
- The constraints, be it memory, placement etc., should be set carefully keeping in mind the system configuration of each node or a service may remain as pending indefinitely.
Now, let us get started with a basic implementation of the same -
Initialise The Cluster
Select at least one master node and few worker nodes with the same version of docker installed on them and run the following command on manager:
docker swarm init --advertise-addr <MANAGER-IP>
This will generate a result. Next, copy the token/command generated as the output of the above command and run it on all the other worker nodes.
Run the following code on the master node to see all the sub-nodes and verify that all nodes are in Ready state by running the command given below:
docker node ls
- The swarm is now setup for deployment or scaling.
Create A Private Registry To Push Local Images
Note that this an extra step if one wants to store the created images in a self hosted docker registry. It is not necessary if one is using public container registries like Docker Hub or any other existing registries.
This registry is newly created so that it can be hosted on the master and can be externally accessible on all other nodes and one can create local images and push it to this registry. This action will cause all nodes to be able to access the images. Keep in mind that your registry.domain.com should be registered for security.
Run the following code on master:
docker run -d --restart=always --name registry \
-v /root/certs:/root/certs \
-e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/root/certs/xxxxx.pem \
-e REGISTRY_HTTP_TLS_KEY=/root/certs/xxxx.key \
-e REGISTRY_HTTP_SECRET=secretstring
-p 443:443 \
registry:2
Use xxxx.key, xxxx.pem for your registered domain. If this does not work, then you can proceed with an alternative method.
- Create a
daemon.json file in /etc/docker on all the worker nodes using the code snippet given below:
{ "insecure-registries": [ "your-registry.domain.com" ] }
Save and run the following code:
systemctl daemon-reload
systemctl restart docker
Implement the code given below to tag the local images:
docker tag image:latest your-registry.domain.com/image
Implement the following cod to push local images:
docker push your-registry.domain.com
Start deploying services
Updating services is quite easy! Here, we will deploy a service with one replica and and then update the service in the next segment.
docker service create --name service-name --replicas 1 -p xxxx:xxxx your-registry.domain.com/image:latest
Docker Swarm will manage the placement of all the services over master and worker nodes. Now one can see all deployed services with replica count on master by implementing the following code on your console:
docker service ls
Notice that the last service is a global one as compared to other replicated ones as explained above.
Updating a deployed service
Use the following code and update the number of replicas:
docker service update --name service-name --replicas 2
This will update replicas along with each replica's proper placement.
Draining a node
Though draining a node is a simple service update as shown above but it is an interesting feature. Say, one of the nodes requires to go under maintenance, its availability in the cluster needs to be removed so as to avoid scheduling of tasks on it. To do this, run the following command:
docker node update --availability drain <NODE-ID>
Important and useful docker swarm commands -
docker node ls
docker service ls
docker node inspect node_name
docker node inspect node_name
docker service inspect svc_name
docker service inspect svc_name
docker node rm node_name
docker service rm svc_name
docker service update [OPTIONS] SERVICE
docker node promote node_name
docker node demote node_name
List Of Few Management UIs for Docker Swarm
Management UI is of great help when it comes to handling the entire swarm cluster without having to use the command line (My favourite being Portainer). There may be others, but here are a few tried and tested UIs:
i). Portainer - Portainer is the definitive container management GUI and dashboard for Kubernetes, Docker and Docker Swarm.
ii) Swarmpit - Swarmpit is a lightweight Docker Swarm Management UI. It provides for a nice and clean way to manage your Docker Swarm cluster.
iii) docker-swarm-visualizer - This is only a visualizer and swarm cluster cannot be managed directly from the UI.
Conclusion
Now as told before let us have a quick look over the comparison between Kubernetes and Docker Swarm.
- K8s has a strong cluster strength as compared to Docker Swarm.
- Docker Swarm is comparatively easier to setup.
- Scaling up is easier is Docker Swarm.
- K8s has auto scaling feature as compared to Docker Swarm's manual scaling.
- Docker Swarm has auto load balancing in comparison to K8's manual load balancing.
- K8s has an auto roll back feature.
- K8s has shared volume between containers of a pod. Docker Swarm has shared volume between containers of a node.
- K8s has in-built logging as compared to Docker Swarm.
Thus, any one or both may suite well depending on the use case one is working on.
Go ahead and give Docker Swarm a try and I hope this article interests you in doing the same.😊
Happy Devops!! ✌️
