• 怎麼去管理這麼多的容器？
• 怎麼能方便的橫向擴充套件？
• 如果容器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上，然後在去執行實際的一個