這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】Swarm項目是Docker公司發布三劍客中的一員，用來提供容器叢集服務，目的是更好的協助使用者管理多個Docker Engine，方便使用者使用，像使用Docker Engine一樣使用容器叢集服務。這次分享內容從Swarm項目現狀、Swarm社區現狀和Swarm未來的一些規劃三方面介紹Swarm，目的是能讓大家對Swarm有個完整的認識，並且希望更多的人採用到Swarm項目中來。
Swarm背景
現實中我們的應用可能會有很多，應用本身也可能很複雜，單個Docker Engine所能提供的資源未必能夠滿足要求。而且應用本身也會有可靠性的要求，希望避免單點故障，這樣的話勢必需要分布在多個Docker Engine。在這樣一個大背景下，Docker社區就產生了Swarm項目。
Swarm是什麼
Swarm這個項目名稱特別貼切。在Wiki的解釋中，Swarm behavior是指動物的群集行為。比如我們常見的蜂群，魚群，秋天往南飛的雁群都可以稱作Swarm behavior。
Swarm項目正是這樣，通過把多個Docker Engine聚集在一起，形成一個大的docker-engine，對外提供容器的叢集服務。同時這個叢集對外提供Swarm API，使用者可以像使用Docker Engine一樣使用Docker叢集。
Swarm 特點
- 對外以Docker API介面呈現，這樣帶來的好處是，如果現有系統使用Docker Engine，則可以平滑將Docker Engine切到Swarm上，無需改動現有系統。
- Swarm對使用者來說，之前使用Docker的經驗可以繼承過來。非常容易上手，學習成本和二次開發成本都比較低。同時Swarm本身專註於Docker叢集管理，非常輕量，佔用資源也非常少。
*“Batteries included but swappable”，簡單說，就是外掛程式化機制，Swarm中的各個模組都抽象出了API，可以根據自己一些特點進行定製實現。
- Swarm自身對Docker命令參數支援的比較完善，Swarm目前與Docker是同步發布的。Docker的新功能，都會第一時間在Swarm中體現。
Swarm架構結構
- Swarm對外提供兩種API， 一種是Docker API，用於負責容器鏡像的生命週期管理， 另外一種是Swarm叢集管理CLI，用於叢集管理。
- Scheduler模組，主要實現調度功能。在通過Swarm建立容器時，會經過Scheduler模組選擇出一個最優節點，裡麵包含了兩個子模組，分別是Filter和Strategy， Filter用來過濾節點，找出滿足條件的節點（比如資源足夠，節點正常等等），Strategy用來在過濾出的節點中根據策略選擇一個最優的節點（比如對找出的節點進行對比，找到資源最多的節點等等）, 當然Filter/Strategy使用者可以定製。
- Swarm對叢集進行了抽象，抽象出了Cluster API，Swarm支援兩種叢集，一種是Swarm自身的叢集，另外一種基於Mesos的叢集。
- LeaderShip模組用於Swarm Manager自身的HA，通過主備方式實現。
- Discovery Service 服務發現模組，這個模組主要用來提供節點發現功能。
- 在每一個節點上，都會有一個Agent，用於串連Discovery Service，上報Docker Daemon的IP連接埠資訊，Swarm Manager會直接從服務發現模組中讀取節點資訊。
Swarm各個模組介紹
叢集管理
Swarm Manager CLI用於叢集管理。大家可以看這張圖，通過三步就可以將叢集建立起來。
Swarm容器叢集建立完成後，就可以採用Docker命令，像使用Docker Engine一樣使用Swarm叢集建立容器了。
服務發現
服務發現，在Swarm中主要用於節點發現，每一個節點上的Agent會將docker-egine的IP連接埠註冊到服務發現系統中。Manager會從服務發現模組中讀取節點資訊。Swarm中服務發現支援已下3種類型的後端：
第一種，是hosted discovery service，是Docker Hub提供的服務探索服務，需要串連外網訪問。
第二種，是KV分布式儲存系統，現在已支援etcd、ZooKeeper、Consul三種。
第三種，是靜態IP。可以使用本地檔案或者直接指定節點IP，這種方式不需要啟動額外使用其他組件,一般在調試中會使用到。
Scheduler
調度模組主要使用者容器建立時，選擇一個最優節點。在選擇最優節點過程中，分為了兩個階段：
第一個階段，是過濾。根據條件過濾出符合要求的節點，過濾器有以下5種：
- Constraints，約束過濾器，可以根據當前作業系統類型、核心版本、儲存類型等條件進行過濾，當然也可以自訂約束，在啟動Daemon的時候，通過Label來指定當前主機所具有的特點。
- Affnity，親和性過濾器，支援容器親和性和鏡像親和性，比如一個web應用，我想將DB容器和Web容器放在一起，就可以通過這個過濾器來實現。
- Dependency，依賴過濾器。如果在建立容器的時候使用了--volume-from/--link/--net某個容器，則建立的容器會和依賴的容器在同一個節點上。
- Health filter，會根據節點狀態進行過濾，會去除故障節點。
- Ports filter，會根據連接埠的使用方式過濾。
調度的第二個階段是根據策略選擇一個最優節點。有以下三種策略：
- Binpack，在同等條件下，選擇資源使用最多的節點，通過這一個策略，可以將容器聚集起來。
- Spread，在同等條件下，選擇資源使用最少的節點，通過這一個策略，可以將容器均勻分布在每一個節點上。
- Random，隨機播放一個節點。
Leadership
Leadership模組，這個模組主要用來提供Swarm Manager自身的HA。
為了防止Swarm Manager單點故障，引入了HA機制，Swarm Manager自身是無狀態的，所以還是很容易實現HA的。 實現過程中採用主備方式，當主節點故障以後，會從新選主提供服務，選主過程中採用分布式鎖實現，現在支援etcd、ZooKeeper、Consul三種類型的分布式儲存，用來提供分布式鎖。 當備節點收到訊息後，會將訊息轉寄給主節點。
以上就是架構中各個模組的相關介紹，下來和大家一起再看一下，Swarm與周邊項目的整合。
首先看一下，與三劍客之間的整合。
Swarm與周邊項目整合
三劍客是Docker公司去年底發布的三個項目，這三者是可以緊密協作的。可以看一下這張圖：
最下面是Machine，通過Machine可以在不同雲平台上建立出包含docker-engine的主機。Machine通過driver機制，目前支援多個平台的docker-egine環境的部署，比如亞馬遜、OpenStack等。 Docker Engine建立完以後，就該Swarm上場了，Swarm將每一個主機上的docker-egnine管理起來，對外提供容器叢集服務。最上面是Compose項目，Compose項目主要用來提供基於容器的應用的編排。使用者通過yml檔案描述由多個容器組成的應用，然後由Compose解析yml，調用Docker API，在Swarm叢集上建立出對應的容器。
我們知道現在圍繞Docker已經產生了很大的一個生態圈。 因此Swarm不僅在和自家兄弟整合，也能積極和周邊的一些項目整合。比如，Swarm現在已經可以和Mesos進行整合。Swarm與Mesos整合時，也是以Framework方式整合，實現了Framework所需的介面。這個大特性處在experiment階段。
Swarm社區的現狀
Swarm項目去年底發布，發展了短短半年時間，已經到了0.4版本，目前還處於正在快速演化階段。 Swarm發布版本周期目前是跟著Docker一起發布，基本上兩個月一個版本，在開發過程中，採用迭代方式開發，基本上每兩個星期完成一輪迭代。參與社區的方法基本上和其他社區一致。當遇到問題時，可以在社區建立issue，然後描述問題，最好能上環境資訊以及問題重現的步驟，這樣有利於問題的定位。當然也可也直接通過IRC或者郵件直接交流。 Swarm社區很歡迎大家的參與，不論是使用中遇到的問題以及Bug，還是Swarm功能上目前無法滿足大家的地方。都歡迎大家提出來，一起討論。
如果對代碼感興趣的話，可以參考Docker社區的提交代碼流程來提交代碼，也非常歡迎大家能夠參與到Swarm社區中提交代碼。
Swarm未來規劃
- 首先是支援所有的Docker API，現在支援率大概在95%，其中一些實現還存在問題，需要改進。
- 第二塊是網路部分，通過Libnetwork項目，實現overlay network。
- 第三塊是Self healing，通過這一個功能可以實現，當一個節點故障以後，會將故障節點上的容器在另外一些節點上建立。
- 第四塊是Global Scheduler。這個特性主要用來將一個容器在每一個節點上進行建立。比如，想將一個log容器在每一個節點建立，用來記錄日誌，則可以通過這一特性實現。
- 最後是volume，這一塊社區最近在討論。
Q&A
Q：Kubernetes和Swarm 相比較來看如何選擇呢？
A：一個很Open的話題，根據特點，選擇適合自己的就OK。Swarm對外提供Docker API，自身輕量、學習成本、二次開發成本都比較低，自身是外掛程式式架構。從功能上講，Swarm是Q：Kubernetes的一個子集，個人感覺，Compose+Swarm =Kubernetes。
Q：Swarm最終目標是什麼，只是為了管理容器嗎，有沒有考慮過提升資源使用率，會把資源Auto Scaling做上來嗎，最終把所有機器負載提升，防止有些低負載或空負載浪費資源？
A：Auto-scaling能力，個人感覺後邊可能通過Compose來實現，感興趣的話，可以在Swarm社區提一個proposal。
Q：Swarm對節點的選取是否可定製化，指的是策略選擇，感覺只有這三種不夠強大？
A：可以，可以根據自己的特點實現對應API。
Q：調用Swarm API及Swarm調Docker API 安全認證是怎麼做的？
A：安全這部分是通過SSL協議實現通訊安全以及認證，支援Swarm對外（比如與Client）之間的提供通訊安全，同時Swarm與Docker Engine之間的也支援通訊安全。
Q：Swarm怎麼跨節點link？
A：目前不支援跨節點，如果使用了link，建立的容器和link的容器會被調度到同一個節點上。
Q：Swarm的調度系統也是外掛程式形式？可以使用Mesos的資源調度嗎？
A：Swarm調度器是外掛程式形式。Mesos採用兩層調度架構，第一層，由mesos將符合架構的資源上報給架構，第二層，架構（swarm）自身的調度器將資源分派給任務。
Q：Swarm IP是怎麼管理的？Swarm 下的各個節點是動態分配IP的嗎？
A：當前網路部分還是用docker-engine自身的能力，後續會和libnetwork進行整合，具體怎麼管理正在討論中。
Q: swarm支援根據docker的標籤來調度嗎？
A: 支援，通過Constraints Filter來實現。
Q：網路部分整合除了libnetwork還有其他計劃或者考慮嗎？
A：libnetwork自身也提供了plugin機制，個人理解，和其他網路項目很好整合。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上內容根據2015年9月8日晚群分享內容整理。分享人
線超博，華為IT雲端運算架構與設計部進階工程師，從事雲端運算方向的技術研究，當前主要負責Docker相關技術在雲端運算領域的技術研究和實踐。2015年初開始關注Docker Swarm項目，並積极參与社區貢獻，成為國內第一位Docker社區Maintainer。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
