Original article, welcome to reprint. Reprint please specify: reprint from IT people story, thank you! Docker Swarm Docker Swarm Docker Swarm

Up to today’s summary, if you follow me to learn and practice together with the old iron, completely mastered Docker. In daily development and testing, there is absolutely no problem. Both docker and us originally intended to use it in production environment, but production environment and test environment are completely different environmental conditions.

Previous learning and practice environment

Before learning container choreography, all operations are carried out locally. Docker CLI connection is a Docker host, and both Docker run and Docker Container are on a machine. However, in the actual production environment, An application is too complex to be deployed on a single machine to meet our needs, and is solved by clustering.




The problem with using containers everywhere
  1. How do you manage so many containers?
  2. How can convenient horizontal expansion?
  3. If the container is down, how can it be automatically recovered?
  4. How to renew financing without affecting business?
  5. How to schedule container creation?
  6. Protecting private data?






Swarm of architecture
  1. Swarm cluster architecture
  2. The node has roles under it: Worker Manager
  3. Manager is the brain of the whole Warm cluster, to avoid a single point of failure, we have at least two brains, and the synchronization of states is done via RAFT protocol. The RAFT protocol ensures that multiple Managers are previously synchronized.

One of the advantages of distributed systems over stand-alone systems is better fault tolerance.

  • For example, if a disk on one machine is damaged and data is lost, it can be restored from disk > on another machine (distributed systems will make backups of data).
  • For example, if some machines in the cluster go down, the whole cluster can still provide services to the outside world. One of the easier ideas is backup. The working mode of a system is: accept the command of the client, the system performs processing, and returns the result of processing to the client. Thus, the data in the system may change depending on command. One way to implement backup is to Repilcated State Machine (RSM), which has an important property — deterministic:
  • If two identical, deterministic states start in the same state and receive the same inputs in the same order, then both state machines will produce the same output and end up in the same state. That is, if we can apply command to the state machine sequentially, It can produce the same state and the same output so how does a state machine work? This is shown below (from the RAFT protocol) :



image

In the figure above, each RSM has a replicated log, which stores commands from the client. The commads of replicate log is replicated in the same order in each RSM. The state machine processes the commands in the REPLICATE log sequentially and sends the results back to the client. Because state machines are deterministic, the output and state of each state machine are the same. There is one Module in the figure above, Consensus Module, that was not mentioned earlier. This module is used to ensure Log consistency across each server!

  • If you write commad violence without any protection, the Log will be lost and cannot be recovered if the server goes down or some other failure occurs. The potential for failure is high, which makes the system unusable
  • Raft is an implementation of Consensus Module. Therefore, RAFT is a consistency protocol and an algorithm used to ensure consistency of copies on servers.
  1. Worker is synchronized through the network structure of Gossip

  2. Docker compose: Service and Replicas are the same in docker compose.





The command set



Personal homepage: IT people’s stories

PS: I will learn Swarm by many practical operations.