[Editor's note] The Swarm project is one of the three Musketeers released by Docker. It is used to provide container cluster services. The purpose is to better help users manage multiple Docker Engines, make it easier for users to use, and use container cluster services like Docker Engine. . The content of this sharing introduces Swarm from three aspects: the current situation of the Swarm project, the current situation of the Swarm community and some future plans of Swarm. The purpose is to give everyone a complete understanding of Swarm and hope that more people will adopt it in the Swarm project.
Swarm background
In reality, we may have many applications, and the application itself may be very complex, and the resources provided by a single Docker Engine may not be able to meet the requirements. Moreover, the application itself will also have reliability requirements, and it is hoped to avoid a single point of failure. In this case, it must be distributed in multiple Docker Engines. In such a big context, the Docker community gave birth to the Swarm project.
what is swarm
Swarm is an aptly named project. In the Wiki explanation, Swarm behavior refers to the swarming behavior of animals. For example, our common bee swarms, fish swarms, and geese flying south in autumn can all be called Swarm behavior.
This is exactly what the Swarm project does. By gathering multiple Docker Engines together to form a large docker-engine, it provides container cluster services to the outside world. At the same time, this cluster provides Swarm API externally, and users can use the Docker cluster just like using Docker Engine.
Swarm Features
- The Docker API interface is presented to the outside world. The advantage of this is that if the existing system uses Docker Engine, the Docker Engine can be smoothly switched to Swarm without changing the existing system.
- For Swarm users, the previous experience of using Docker can be inherited. It is very easy to use, and the learning cost and secondary development cost are relatively low. At the same time, Swarm itself focuses on Docker cluster management, which is very lightweight and occupies very few resources. *"Batteries included but swappable", simply put, is the plug-in mechanism. Each module in Swarm abstracts the API, which can be customized and implemented according to some of its own characteristics.
- Swarm itself has relatively complete support for Docker command parameters, and Swarm is currently released synchronously with Docker. The new functions of Docker will be reflected in Swarm for the first time.
Swarm framework
- Swarm provides two external APIs, one is the Docker API, which is responsible for the lifecycle management of container images, and the other is the Swarm cluster management CLI, which is used for cluster management.
- The Scheduler module mainly implements the scheduling function. When creating a container through Swarm, an optimal node will be selected through the Scheduler module, which contains two sub-modules, namely Filter and Strategy. Filter is used to filter nodes and find nodes that meet the conditions (such as sufficient resources and normal nodes). etc.), Strategy is used to select an optimal node according to the strategy among the filtered nodes (such as comparing the found nodes, finding the node with the most resources, etc.), of course, Filter/Strategy users can customize.
- Swarm abstracts the cluster and abstracts the Cluster API. Swarm supports two types of clusters, one is Swarm's own cluster, and the other is Mesos-based cluster.
- The LeaderShip module is used for the HA of the Swarm Manager itself, which is implemented in the active-standby mode.
- Discovery Service Service discovery module, this module is mainly used to provide node discovery function.
- On each node, there will be an Agent to connect to the Discovery Service and report the IP port information of the Docker Daemon, and the Swarm Manager will directly read the node information from the service discovery module.
Introduction to each module of Swarm
Cluster management
The Swarm Manager CLI is used for cluster management. You can look at this picture and create a cluster in three steps.
After the Swarm container cluster is created, you can use Docker commands to create containers using the Swarm cluster just like using Docker Engine.
service discovery
Service discovery is mainly used for node discovery in Swarm. The Agent on each node will register the IP port of docker-egine to the service discovery system. Manager will read node information from service discovery module. Service discovery in Swarm supports three types of backends:
the first one is hosted discovery service, which is a service discovery service provided by Docker Hub and needs to be connected to the external network for access.
The second is the KV distributed storage system, which now supports etcd, ZooKeeper, and Consul.
The third is static IP. You can use a local file or specify the node IP directly. This method does not need to start additional components, which are generally used in debugging.
Scheduler
The scheduling module selects an optimal node when the main user container is created. In the process of selecting the optimal node, it is divided into two stages:
the first stage is filtering. Filter out the nodes that meet the requirements according to the conditions. There are the following 5 filters:
- Constraints, constraint filter, can filter according to the current operating system type, kernel version, storage type and other conditions, of course, you can also customize the constraints, when starting Daemon, use Label to specify the characteristics of the current host.
- Affnity, affinity filter, supports container affinity and image affinity, such as a web application, if I want to put the DB container and the web container together, this filter can be used to achieve it.
- Dependency, dependency filter. If --volume-from/--link/--net a container is used when creating a container, the created container will be on the same node as the dependent container.
- Health filter, which will filter according to node status and remove faulty nodes.
- Ports filter, which will filter based on port usage.
The second stage of scheduling is to select an optimal node according to the policy. There are three strategies:
- Binpack, under the same conditions, selects the node that uses the most resources. Through this strategy, containers can be aggregated.
- Spread, under the same conditions, select the node with the least resource usage. Through this strategy, the containers can be evenly distributed on each node.
- Random, randomly selects a node.
Leadership
Leadership module, this module is mainly used to provide the HA of the Swarm Manager itself.
In order to prevent the single point of failure of the Swarm Manager, the HA mechanism is introduced. The Swarm Manager itself is stateless, so it is easy to implement HA. In the implementation process, the master-standby mode is adopted. When the master node fails, the new master will be selected to provide services. In the process of master selection, distributed locks are used. Now it supports three types of distributed storage such as etcd, ZooKeeper, and Consul to provide distributed storage. Lock. When the standby node receives the message, it forwards the message to the master node.
The above is the relevant introduction of each module in the framework. Let's take a look at the integration of Swarm and surrounding projects.
First look at the integration with the Three Musketeers.
Swarm integrates with surrounding projects
The Three Musketeers are three projects released by Docker at the end of last year, and the three can work closely together. Take a look at this picture:
At the bottom is Machine, through which a host containing docker-engine can be created on different cloud platforms. Through the driver mechanism, Machine currently supports the deployment of docker-egine environments on multiple platforms, such as Amazon and OpenStack. After the Docker Engine is created, it is time for Swarm to come on stage. Swarm manages the docker-egnine on each host and provides container cluster services to the outside world. At the top is the Compose project, which is mainly used to provide orchestration of container-based applications. The user describes the application composed of multiple containers through the yml file, and then Compose parses the yml, calls the Docker API, and creates the corresponding container on the Swarm cluster.
We know that there is a big ecosystem around Docker now. Therefore, Swarm is not only integrating with its own brothers, but also actively integrating with some surrounding projects. For example, Swarm can now be integrated with Mesos. When Swarm is integrated with Mesos, it is also integrated in the form of a Framework, which implements the interfaces required by the Framework. This big feature is in the experiment stage.
The current state of the Swarm community
The Swarm project was released at the end of last year, and it has been developed for just half a year. It has reached version 0.4 and is still in the stage of rapid evolution. The Swarm release cycle is currently released together with Docker, basically a version every two months. During the development process, it is developed in an iterative manner, and an iteration is basically completed every two weeks. The method of participating in the community is basically the same as that of other communities. When you encounter a problem, you can create an issue in the community, and then describe the problem, preferably with environmental information and the steps to reproduce the problem, which is conducive to problem positioning. Of course, you can also communicate directly through IRC or email. The Swarm community welcomes everyone's participation, whether it is the problems and bugs encountered in use, or the places where the Swarm function cannot currently satisfy everyone. All are welcome to come forward and discuss together.
If you are interested in the code, you can refer to the Docker community's code submission process to submit the code. You are also very welcome to participate in the Swarm community to submit code.
Swarm future plans
- The first is to support all Docker APIs, and the support rate is now about 95%. Some of these implementations still have problems and need to be improved.
- The second part is the network part, which implements the overlay network through the Libnetwork project.
- The third block is Self healing, which can be achieved through this function. When a node fails, the containers on the failed node will be created on other nodes.
- The fourth block is the Global Scheduler. This feature is mainly used to create a container on each node. For example, if you want to create a log container on each node to record logs, you can use this feature.
- Finally, there is volume, which the community has been discussing recently.
Q&A
Q: How do you choose between Kubernetes and Swarm?
A: It is a very open topic. According to the characteristics, it is OK to choose the one that suits you. Swarm provides Docker API to the outside world. It is lightweight, has low learning costs, and low secondary development costs. It is a plug-in framework. Functionally, Swarm is a subset of Q:Kubernetes. Personally, Compose+Swarm=Kubernetes.
Q: What is the ultimate goal of Swarm? Is it just to manage containers? Have you considered improving resource utilization, will you do elastic scaling of resources, and finally increase the load of all machines to prevent some low load or empty load from wasting resources?
A: Auto-scaling capability, I personally feel that it may be achieved through Compose later. If you are interested, you can submit a proposal in the Swarm community.
Q: Is the selection of nodes by Swarm customizable, which refers to the selection of strategies. I feel that only these three are not powerful enough?
A: Yes, you can implement the corresponding API according to your own characteristics.
Q: How to call Swarm API and adjust Docker API security authentication with Swarm?
A: The security part implements communication security and authentication through the SSL protocol, and supports communication security between Swarm externally (such as with Client), and also supports communication security between Swarm and Docker Engine.
Q: How does Swarm link across nodes?
A: Cross-node support is not currently supported. If link is used, the created container and the linked container will be scheduled on the same node.
Q: Swarm's scheduling system is also in the form of plug-ins? Can Mesos' resource scheduling be used?
A: The Swarm scheduler is in the form of a plug-in. Mesos adopts a two-layer scheduling framework. In the first layer, Mesos reports resources that conform to the framework to the framework, and in the second layer, the scheduler of the framework (swarm) itself allocates resources to tasks.
Q: How is Swarm IP managed? Are each node under Swarm dynamically allocated IP?
A: The current network part is still using docker-engine's own capabilities. It will be integrated with libnetwork in the future. The specific management is under discussion.
Q: Does swarm support scheduling based on docker tags?
A: Yes, through the Constraints Filter.
Q: Are there other plans or considerations for network integration in addition to libnetwork?
A: libnetwork itself also provides a plugin mechanism, personal understanding, and good integration with other network projects.