Simple and Docker Swarm

1.Swarm Profile

Since the birth of Docker, its container characteristics and mirror characteristics have brought many conveniences to devops enthusiasts. However, for a long time, Docker can only run on a single host, its ability to deploy, run and manage across the host is highly criticized. The weakness of the cross host capability leads directly to the tight coupling between the Docker container and host, in which case, the flexibility of the Docker container is difficult to be satisfied, and the migration and grouping of the containers become the function points which are difficult to realize.

Swarm is a newly released container management tool by Docker company in early December 2014. The Docker management tools released with Swarm are machine and compose.

Swarm is a simpler set of tools for managing Docker clusters, making Docker clusters exposed to users as a virtual whole. Swarm uses the standard Docker API interface as its front-end access portal, in other words, all forms of Docker Client (dockerclient in Go, docker_py, Docker, etc.) can communicate directly with swarm. Swarm is almost entirely developed in the go language and is still in Alpha, and the version currently released on GitHub is only v0.1.0-rc1. However, the development of swarm is very fast, and the change generation of function and characteristic is very frequent. Therefore, it can be said that swarm is not recommended for the production environment, but it is certain that swarm is a promising technology.

Swarm's design, like other Docker projects, follows the "batteries included but removable" principle. The author's understanding of this principle is: Batteries included representative design swarm, in order to fully embody the integrity of distributed container cluster deployment, operation and management functions, swarm and Docker work together to achieve results; "but removable" means that swarm and Docker are not tightly coupled, the management engine does not invade the use of Docker, and this mechanism can also be used for cluster deployment, operation and management of other container technologies.

This article will analyze swarm from the following two points:

swarm schema Swarm command

2.Swarm Architecture

Swarm as a tool for managing Docker clusters, you first need to deploy them to deploy swarm to a single node. In addition, nature needs a docker cluster, each node on the cluster is installed with Docker. The concrete swarm frame composition may refer to the following figure:

Swarm frame composition

The main processing part of the swarm architecture is naturally the Swarm node, the object of swarm management is Docker Cluster,docker Cluster by multiple Docker node, and Swarm Client is responsible for sending the request to Docker.

3.Swarm Command

Swarm frame composition allows you to have a preliminary understanding of swarm, such as the swarm of the specific workflow: Docker client send request to Swarm;swarm processing requests and sent to the corresponding Docker Node;docker Node performs the appropriate action and returns the response. In addition, the working principle of swarm is still not clear enough.

To understand the working principle of swarm, you can start with the command provided by Swarm. Swarm supports 4 main commands: Swarm create, Swarm manage, swarm join, swarm list. And of course there's a swarm help command that instructs you on how to use the Swarm command correctly, and this article doesn't repeat it.

3.1 Swarm Create

The swarm create command in swarm is used to create a cluster flag for Swarm node discovery function when managing Docker clusters.

After the command is launched, Swarm will go to the discovery service built on the Docker hub to obtain a globally unique token to uniquely identify swarm managed Docker clusters.

Note: Swarm operation needs to use service discovery, the current service is built with Docker Hub, the service discovery mechanism is still in the 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, it means that the user needs swarm to start managing the Docker cluster. From the point of view of the running process, the Swarm experience has two main stages: starting Swarm, receiving and processing Docker cluster management requests.

The Swarm startup process consists of three steps:

discovers nodes in Docker cluster, collects node status, role information, and monitors node state changes, initializes internal scheduling (scheduler) modules, and creates and launches API listening service modules;

In the first step, Swarm discovers the nodes in the Docker cluster. Discovery (discovery) is the mechanism used in swarm to maintain the state of the Docker cluster. Since it involves discovery (discovery), there must be a registration (register) before that. There are modules in the Swarm for Discovery (discovery), and for the Registration (register) section, there are different forms of registration (register) under different discovery modes.

Currently, there are 5 different discovery (discovery) mechanisms available in swarm: Node discovery, File Discovery, Consul Discovery, Etcd discovery, and zookeeper discovery.

In the second step, the Swarm internal dispatch (scheduler) module is initialized. Swarm discovers all registered Docker node and collects all Docker node status and specific information through discovery mechanism. Thereafter, once swarm receives a specific Docker management request, Swarm needs to process the request and filter (filter) to determine which Docker node meets the requirements through all Docker node state and specific information. The request is forwarded to a specific Docker Node through a certain policy (strategy).

In the third step, Swarm creates and initializes the API listening service module. From a functional standpoint, the module can be abstracted as swarm Server. What needs to be explained is that although Swarm server is fully compatible with the Docker API, there are a number of Docker commands that are not currently supported, after all, there are some differences between managing Docker clusters and managing separate docker. After the swarm server is initialized and listening is completed, the user can send Docker cluster management requests to swarm via Docker client.

Swarm's swarm manage receive and process the management requests of the Docker cluster, which is the result of collaborative collaboration among multiple modules within swarm. The request entrance is swarm Server, the processing engine is scheduler, and the node information depends on Disocovery.

3.3 swarm Join

The Swarm swarm join command is used to add Docker node to the Swarm managed Docker cluster. From this point of view you can see that the execution of the Swarm join command is located at Docker node, so running the command on Docker node requires that swarm be installed on Docker node, because the swarm will only execute the SWARM join command. It can be used as the agent module for registration on Docker node.

In terms of functionality, swarm join can be considered as completing the registration (register) of Docker node at the swarm nodes so swarm can discover the Swarm node when executing manage Docker. However, not each of the 5 discovery modes mentioned above supports the SWARM join command. Unsupported Discovery schemas have node Discovery and file Discovery.

After swarm join execution on Docker node, it marks Docker node registering with Swarm and requesting to join Swarm-managed Docker cluster. Swarm through the registration information, discovers Docker node, and obtains Docker node's state and the concrete information, in order to process the Docker request as the dispatch basis.

3.4 Swarm List

The Swarm List command in swarm lists the Docker Node in the Docker cluster.

Docker node information is derived from Docker node registered on Swarm nodes. A docker node is registered on the Swarm node, simply registering the IP address of the Docker node and the Docker listener's port number.

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 Docker node's actual state of operation, or Docker node's role information in the Docker cluster.

4. Summary

Swarm's architecture and commands are not complicated, and they reduce the barriers to learning and use for Docker enthusiasts who want to manage Docker clusters.

As the saying goes, there is no single tool for once and for all, effective management of Docker clusters is the same. The lack of a scene to talk about the value of swarm is not very significant. On the contrary, explore and excavate the features and functions of swarm, and provide an optional scheme for the management of Docker cluster, which is a matter that Docker enthusiasts should participate in.

This paper introduces the swarm, and involves the structure and the command, the next period will bring the concrete use of swarm, as well as swarm architecture analysis.

5. The author introduces

Sun Hongliang, Daocloud start-up team member, software engineer, Zhejiang University vlis Laboratory graduate student. During the study period active in PAAs and Docker open source community, Cloud Foundry has in-depth research and rich practice, good at the underlying platform code analysis, the architecture of the distributed platform has some experience, wrote a large number of in-depth technical blog. Joined the Daocloud team as a partner at the end of 2014, dedicated to disseminating Docker-oriented container technology and promoting the container of Internet applications. Email: Allen.sun@daocloud.io

6. References

SWARM:A docker-native Clustering System

Intro to Docker Swarm:part 1-overview

Intro to Docker Swarm:part 2-configuration Options and Requirements

Original link: Simple Swarm (Zebian: Zhou Xiaolu)