When developing an application, have you ever had to go through many bugs that only appeared after deployment to the server? And did you have to stop yourself from saying the magic phrase “weird, it works for me”?
Or, when implementing a patch, did you have to shut down the service for a while, which had a negative impact on the user experience?
Perhaps several people in the company asked you to install incompatible applications on the server, which suddenly started cannibalising each other?
When looking for a solution, you could have used virtual machines, separating the different applications from each other, but you may have chosen another option – containers. These are the ones we will look at today in more detail.
Are Docker and containers the same thing?
A container is a virtual tray with which we can easily and quickly deploy, move and replicate applications in different environments; in other words, it is a software package. Running and creating containers has become convenient with the introduction of a runtime platform such as Docker.
Its popularity is such that some people use the term ‘Docker’ interchangeably with containerisation, which is not quite correct. Containerisation is a much broader term known even before Docker. Still, since it is accepted to refer to facial tissues as “kleenex”, this lack of programmatic purism in naming can be forgiven.
Docker has done much good by spreading containerisation. It allows us to download a container image from the registry and create containers ourselves, which are isolated from each other, so changing one does not affect the other and the next container. If we do not need to install different operating systems, then Docker may be a better solution than virtual machines – you will gain less CPU and disk memory usage.
From Docker to Docker Swarm
However, Docker alone, installed on a single device, will not work when the key is to ensure uninterrupted availability. If a device fails or a container is updated, the application will not work. If a device fails or a container is updated, the application will not work. Another challenge is scalability. To ensure smooth load balancing, it is necessary to run a replica of the container on a second or subsequent device. This is where Docker Swarm comes in.
What is Docker Swarm?
It is an open-source platform provided under the Apache 2.0 licence. Dockers Swarm is maintained by Mirantis (Mirantis acquired the platform from Docker in 2020).
Docker Swarm is used to managing individual components and entire clusters (groups of physical or virtual machines) using the Docker Engine. In doing so, it simplifies the application management process, speeds up new deployments and takes a lot of DevOps work off the developers’ hands, such as tailoring the software for specific infrastructure requirements. It works flawlessly with all applications using Docker for containerisation.
How does Docker Swarm work?
Docker Swarm is entirely decentralised, making access much easier for the various teams managing the environment. The communication provides a high level of security, and the built-in auto load balancing makes it easy to scale the infrastructure and apply rollback to revert to an earlier version of the environment seamlessly.
Containers are pushed and controlled through services, which can be defined as a group of containers containing the same image. Services allow for scaling, and to deploy them, a minimum of one node is needed. In Docker Swarm, we have two types of nodes: a manager, which handles cluster management tasks, and a worker, which receives and executes these tasks.
The manager node knows the status of all worker nodes with which it communicates bilaterally. The worker node has an agent that reports to the manager the status of a handled task that had been previously accepted from that node.
Access to Docker Swarm services and their deployment can be done via any node in the same cluster. In this case, it is necessary to indicate which container image you want to use. You can choose from the public registry (Docker Hub) or make a private registry.
Services can be either global, where the service can be operated at all times on each node or replicated only on selected worker nodes.
Delving into Docker terminology, one might get the impression that services are tasks to be performed, but there is a subtle difference. Service here describes a job, while a task is a way of executing it. The user creates a service that initiates a task, and the task itself can only be assigned to one node.
It is also possible to have multiple managers within Docker Swarm, but in this case, it is necessary to specify which one overrides the others.
Docker Swarm vs Kubernetes
Kubernetes, also known as K8s, is an open-source platform for container orchestration. It supports deployment automation, application scaling, container management, change and process monitoring. It allows the management of clusters (groups of cooperating machines) and nodes (individual machines in a cluster) at scale, thus shortening the process of adapting applications to infrastructure requirements and simplifying the process of implementing changes and adding new elements to the system.
Google developed the Kubernetes platform 20 years ago to support the company’s production workloads and run billions of containers per week. In 2014, the project was handed over to the Cloud Native Computing Foundation, which falls under the Linux Foundation, and the software licence changed to Apache 2.0. Since then, the platform has been supported by CNCF and continuously developed.
Benefit from technical support and a $300 voucher
The choice of the platform depends on the nature of the organisation and the developed application.
If the principal value is the speed of deployment (especially if the product is not very extensive and demanding), it is worth turning to Docker Swarm. Its unquestionable advantages are its ease of installation, speed of learning and compatibility with the Docker environment.
However, if the stability and predictability of development are essential, you should choose the Kubernetes platform – especially for an extensive system consisting of thousands or millions of containers. The time needed to familiarise yourself with the platform’s capabilities is longer, but it will allow you to use many tools and adapt the platform to your individual needs.
See also:
