從零開始學習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上，而後在去執行實際的一個操做就能夠了。