从零开始学习docker（十五）Swarm mode 介绍

通常状况下，咱们都在一台机器下部署容器，但实际状况下，应用若是只在一台机器上没法知足咱们的需求，包含的容器比较多。所以在生产环境下部署咱们的应用就会涉及到很是多的容器，这样就会给咱们带来一系列的问题：

• 怎么去管理这么多的容器？
• 怎么能方便的横向扩展？
• 若是容器down了，怎么能自动恢复？
• 如何去更新容器而不影响业务？
• 如何去监控追踪这些容器?
• 怎么去调度容器的建立？
• 保护隐私数据？

这样咱们就须要容器编排技术，Swarm Mode应运而生。

Swarm 并非惟一一个能够作容器编排的工具，只不过Swarm是内置于docker的一个工具。所以咱们使用Swarm时不须要安装任何东西，Swarm已经内置到咱们系统里面了，只不过咱们没有运行在Swarm 模式下，咱们通常运行在单机模式下。所以swarm就是初学者接触容器编排的第一个工具。

Swarm 架构

Swarm是一种集群架构，既然是集群，那么必定有节点，有节点那么就有角色。在Swarm中节点node一共有两种角色，第一种角色叫Manager，第二种角色叫worker。

Manager节点比如集群的大脑，在生产环境中，为了不单点故障，“大脑”至少要有两个，所以会有状态同步，即在一个Manager产生的数据如何同步到另外的Manager节点上，这里就涉及到一个内置的分布式存储数据库，数据经过raft协议去作同步。raft协议可以确保Manager节点的信息是对称的，同步的，能够避免脑裂的状况。

Worker节点就是真正干活的节点，真正的容器部署在cluster中都会运行在Work节点中，固然Manager节点也能够运行，可是通常都运行在Worker节点中，由于Worker节点比较多。Worker节点之间也有数据须要同步，是经过Gossip网络来作信息同步。

Swarm中一个很是重要的概念是Service和Replicas。

Service在上一节中介绍docker compose的时候有介绍过，在Swarm中的service与docker compose下的service的意思基本同样。一个service就表明了一个容器。

在Replicas模式下，即咱们想作横向扩展，再部署的过程当中，一个replicas就是一个容器。

如上图所示，咱们想部署一个Nginx的service，想要给他作3个扩展，实际上部署的过程当中会产生三个容器，这三个容器会经过调度系统调度到不一样的node上面去。也就是说咱们经过Swarm Manager节点去部署一个service，实际上是不知道这个service最终会运行在哪一个节点上，这回根据Swarm的schedule根据必定的调度算法去算的，例如算法会根据节点的负载来选择。

上面这张图就是swarm算法调度的一个过程。在swarm manager上作一些决策，来决定把哪一个service部署在哪台node上，而后在去执行实际的一个操做就能够了。