>原創文章，歡迎轉載。轉載請註明：轉載自IT人故事會，謝謝！
>原文鏈接地址：『中級篇』容器編排Docker Swarm介紹（42）

到今天這次總結，如果跟著我一起學一起練的老鐵，完全入門docker了。在日常的開發和測試，絕對是沒有問題的。不管是我們自己和docker公司，他們的初心都是想用在生產環境下，但是生產環境和測試環境完全是兩種環境條件。

之前的學習實踐環境

在用學習容器編排之前，所有操作本地進行的，docker cli 連接是一臺的docker host，不管是docker run 還是docker container 都是在一臺機器上，但是實際的生產環境下，一個應用很復雜他部署在一臺機器上滿足不了我們的需求，都是通過集群的方式來解決問題的。

到處都使用容器帶來的困擾

1. 怎麽去管理這麽多容器？
2. 怎麽能方便的橫向擴展？
3. 如果容器down了，怎麽能自動恢復？
4. 如何去更新融起而不影響業務？
5. 怎麽去調度容器的創建？
6. 保護隱私數據？

Swarm的架構

1. swarm集群的架構
2. 節點下面有角色：Worker Manager
3. Manager 是整個warm集群的大腦，為了避免單點的故障，我們的大腦至少有2個，狀態的同步通過raft協議進行同步。raft協議可以確保多個Manager之前是同步的。

   　分布式系統之於單機系統，優勢之一就是有更好的容錯性。

   • 比如，一臺機器上的磁盤損壞，數據丟失，可以從另一臺機器上的磁盤>恢復（分布式系統會對數據做備份）
   • 比如，集群中某些機器宕機，整個集群還可以對外提供服務
     這是如何做到的？比較容易的一個想法就是備份（backup）。一個系統的工作模是：接受客戶端的command，系統進行處理，將處理的結果返回給客戶端。由此可見，系統裏的數據可能會因為command而變化。
     實現備份的做法之一就是復制狀態機（Repilcated State Machine，RSM），它有一個很重要的性質——確定性（deterministic）：
   • 如果兩個相同的、確定性的狀態從同一狀態開始，並且以相同的順序獲得相同的輸入，那麽這兩個狀態機將會生成相同的輸出，並且結束在相同的狀態
     也就是說，如果我們能按順序將command作用於狀態機，它就可以產生相同的狀態和相同的輸出
     
     那麽一個狀態機如何實現呢？如下圖所示（來自raft協議）：

上圖中，每個RSM都有一個replicated log，存儲的是來自客戶端的commands。每個RSM中replicate log中commads的順序都是相同的，狀態機按順序處理replicate log中的command,並將處理的結果返回給客戶端。由於狀態機具有確定性，因此每個狀態機的輸出和狀態都是相同的。
上圖中有一個模塊——Consensus Module剛剛沒有提及。這個模塊用於保證每個server上Log的一致性！

• 如果不做任何保障，直接將commad暴力寫入，一旦服務器宕機或者出現什麽其他故障，就會導致這個Log丟失，並且無法恢復。而出現故障的可能性是很高的，這就導致系統不可用
• raft就是Consensus Module的一個實現
  因此，raft是一致性協議，是用來保障servers上副本一致性的一種算法。

4. worker是通過gossip的網絡結構進行同步
5. Service 和Replicas，這裏的Service在docker compose中的Service是一樣的。
   

命令合集

個人主頁：IT人故事會

PS：之後通過很多很多的實踐操作一起來學習Swarm。

『中級篇』容器編排Docker Swarm介紹（42）