1. Introduction to Swarm
Since Docker was born, its container features and mirroring features have brought a lot of convenience to DevOps enthusiasts. However, for a long time, Docker can only run on a single host, and its cross-host deployment, operation and management capabilities have been criticized by the outside world. The weak cross-host capability directly leads to the tight coupling between the Docker container and the host. In this case, the flexibility of the Docker container is unsatisfactory, and container migration and grouping have become difficult to achieve.
Swarm is a new container management tool released by Docker in early December 2014. Docker management tools released with Swarm are also Machine and Compose.
Swarm is a relatively simple set of tools for managing Docker clusters, making the Docker cluster equivalent to a virtual whole when exposed to users. Swarm uses the standard Docker API interface as its front-end access entry, in other words, various forms of Docker Client (dockerclient in go, docker_py, docker, etc.) can communicate directly with Swarm. Swarm is almost entirely developed in Go language and is still in an Alpha version. The version currently released on github is only v0.1.0-rc1. However, the development of Swarm is very fast, and the changes and iterations of functions and features are still very frequent. Therefore, it can be said that Swarm is not recommended for production environments, but it is certain that Swarm is a promising technology.
The design of Swarm, like other Docker projects, follows the principle of "batteries included but removable". The author's understanding of this principle is: Batteries included means that when designing Swarm, in order to fully reflect the integrity of the deployment, operation and management functions of distributed container clusters, Swarm and Docker work together, and Swarm includes a relatively simple scheduling module. Achieve the effect of Docker cluster scheduling management; "but removable" means that Swarm and Docker are not tightly coupled, and the scheduling module in Swarm can also be customized, and users can replace it with a more powerful scheduling module according to their own needs. , such as Mesos et al. In addition, this management engine does not invade the use of Docker, and this mechanism also provides ideas for cluster deployment, operation and management of other container technologies.
This article will analyze Swarm from the following two points:
- Swarm Architecture
- Swarm command
2. Swarm Architecture
As a tool for managing Docker clusters, Swarm needs to be deployed first. Swarm can be deployed on a single node. In addition, a Docker cluster is naturally required, and Docker is installed on each node of the cluster. The specific Swarm architecture diagram can refer to the following figure:
Figure 2.1 Swarm Architecture Diagram
The main processing part in the Swarm architecture is naturally the Swarm node. The object managed by the Swarm is naturally the Docker Cluster. The Docker Cluster consists of multiple Docker Nodes, and the Docker Client is responsible for sending requests to the Swarm.
3. Swarm command
The Swarm architecture diagram can give you a preliminary understanding of Swarm, such as the specific workflow of Swarm: Docker Client sends a request to Swarm; Swarm processes the request and sends it to the corresponding Docker Node; Docker Node executes the corresponding operation and returns the response. Beyond that, how Swarm works is still not well understood.
To deeply understand how Swarm works, you can start with the commands provided by Swarm. There are four main commands supported by Swarm: swarm create, swarm manage, swarm join, and swarm list. Of course, there is also a swarm help command, which is used to guide you how to use the swarm command correctly, which will not be repeated in this article.
3.1 swarm create
The swarm create command in Swarm is used to create a cluster flag for the node discovery function of Docker Node when Swarm manages a Docker cluster.
After issuing this command, Swarm will go to the built-in discovery service on Docker Hub to obtain a globally unique token to uniquely identify the Docker cluster managed by Swarm.
Note: The operation of Swarm requires service discovery. At present, the service is built into Docker Hub. The service discovery mechanism is still in alpha version. The site is: http://discovery-stage.hub/docker.com .
3.2 swarm manage
Swarm manage is the most important management command in Swarm. Once the swarm manage command is triggered on the Swarm node, the user needs swarm to start managing the Docker cluster. From the perspective of the running process, there are two main stages that swarm goes through: starting the swarm, and receiving and processing Docker cluster management requests.
The Swarm startup process consists of three steps:
- Discover each node in the Docker cluster, collect node status, role information, and monitor changes in node status;
- Initialize the internal scheduler module;
- Create and start the API monitoring service module;
In the first step, Swarm discovers the nodes in the Docker cluster. Discovery is the mechanism in Swarm for maintaining the state of a Docker cluster. Since discovery (discovery) is involved, there must be a registration (register) before this. There is a module dedicated to discovery (discovery) in Swarm, and about the registration (register) part, in different discovery modes, registration (register) will have different forms.
Currently, 5 different discovery mechanisms are provided in Swarm: Node Discovery, File Discovery, Consul Discovery, EtcD Discovery, and Zookeeper Discovery.
In the second step, the scheduler module inside Swarm is initialized. Swarm discovers all registered Docker Nodes through the discovery mechanism, and collects the status and specific information of all Docker Nodes. After that, once Swarm receives a specific Docker management request, Swarm needs to process the request, and use the status and specific information of all Docker Nodes to filter and decide which Docker Nodes meet the requirements, and pass a certain strategy (strategy). ) to forward the request to a specific Docker Node.
In the third step, Swarm creates and initializes the API monitoring service module. From a functional point of view, this module can be abstracted as a Swarm Server. It should be noted that although Swarm Server is fully compatible with Docker's API, there are many Docker commands that are not currently supported. After all, there are some differences between managing a Docker cluster and managing a single Docker. After the Swarm Server is initialized and monitored, users can send Docker cluster management requests to Swarm through the Docker Client.
Swarm's swarm manage receives and processes the management requests of the Docker cluster, which is the result of the cooperation of multiple modules within Swarm. The request entry is Swarm Server, the processing engine is Scheduler, and the node information relies on Disocovery.
3.3 swarm join
Swarm's swarm join command is used to add a Docker Node to a Docker cluster managed by Swarm. It can also be seen from this point that the execution of the swarm join command is located in the Docker Node, so to run this command on the Docker Node, you first need to install the Swarm on the Docker Node. Since the Swarm will only execute the swarm join command, it can be regarded as a Docker The agent module for registration on Node.
Functionally, swarm join can be considered to complete the registration of Docker Node at the Swarm node, so that Swarm can discover the Docker Node when executing swarm manage. However, not all of the five discovery modes mentioned above support the swarm join command. Unsupported discovery modes are Node Discovery and File Discovery.
After the swarm join is executed on the Docker Node, it means that the Docker Node registers with the Swarm and requests to join the Docker cluster managed by the Swarm. Swarm discovers the Docker Node through the registration information, and obtains the status and specific information of the Docker Node, so that it can be used as a scheduling basis when processing Docker requests.
3.4 swarm list
The swarm list command in Swarm is used to list the Docker Nodes in the Docker cluster.
The information of Docker Node comes from the Docker Node registered on the Swarm node. When a Docker Node is registered on the Swarm node, it only registers the IP address of the Docker Node and the port number that Docker listens to.
When using the swarm list command, you need to specify the type of discovery, including: token, etcd, file, zk, and <ip>. The swarm list does not list the dynamic information of the Docker cluster, such as the actual running status of the Docker Node, or the role of the Docker Node in the Docker cluster.
4. Summary
The architecture and commands of Swarm are not very complicated, and it also lowers the learning and use threshold for Docker enthusiasts who want to manage Docker clusters.
As the saying goes, there is no one-size-fits-all tool, and the same goes for effectively managing a Docker cluster. The lack of context to talk about the value of Swarm doesn't make much sense. On the contrary, exploring and mining the features and functions of Swarm, and providing an alternative solution for the management of Docker clusters, is something that Docker enthusiasts should participate in.
This article initially introduces Swarm, and involves architecture and commands. The next issue will bring the specific use of Swarm and the structural analysis of Swarm.
5. About the author
Sun Hongliang, member of DaoCloud start-up team, software engineer, fresh graduate student of VLIS laboratory of Zhejiang University. During his postgraduate studies, he was active in the open source community of PaaS and Docker. He has in-depth research and rich practice on Cloud Foundry. He is good at analyzing the underlying platform code. He has some experience in the architecture of distributed platforms, and has written a lot of in-depth technical blogs. At the end of 2014, he joined the DaoCloud team as a partner, and is committed to spreading the technology of Docker-based containers and promoting the containerization of Internet applications. Email: [email protected]
6. References
1.http://github.com/docker/swarm
2.http://technolo-g.com/intro-to-docker-swarm-pt1-overview/
3.http://technolo-g.com/intro-to-docker-swarm-pt2-config-options-requirements/
http://blog.daocloud.io/swarm_analysis_part1/