1.Swarm簡介

Docker自誕生以來，其容器特性以及映象特性給DevOps愛好者帶來了諸多方便。然而在很長的一段時間內，Docker只能在單host上執行，其跨host的部署、執行與管理能力頗受外界詬病。跨host能力的薄弱，直接導致Docker容器與host的緊耦合，這種情況下，Docker容器的靈活性很難令人滿意，容器的遷移、分組等都成為很難實現的功能點。

Swarm是Docker公司在2014年12月初新發布的容器管理工具。和Swarm一起釋出的Docker管理工具還有Machine以及Compose。

Swarm是一套較為簡單的工具，用以管理Docker叢集，使得Docker叢集暴露給使用者時相當於一個虛擬的整體。Swarm使用標準的Docker API介面作為其前端訪問入口，換言之，各種形式的Docker Client(dockerclient in go, docker_py, docker等)均可以直接與Swarm通訊。Swarm幾乎全部用Go語言來完成開發，並且還處於Alpha版本，目前在github上釋出的版本僅有v0.1.0-rc1。然而Swarm的發展十分快速，功能和特性的變更迭代還非常頻繁。因此，可以說Swarm還不推薦被用於生產環境中，但可以肯定的是Swarm是一項很有前途的技術。

Swarm的設計和其他Docker專案一樣，遵循“batteries included but removable”原則。筆者對該原則的理解是：batteries included代表設計Swarm時，為了完全體現分散式容器叢集部署、執行與管理功能的完整性，Swarm和Docker協同工作，以達到效果;“but removable”意味著Swarm與Docker並非緊耦合，這套管理引擎並未侵入Docker的使用，同時這套機制也可以用以其他容器技術的叢集部署、執行與管理。

本文將從以下兩點分析Swarm：Swarm架構  Swarm命令

2.Swarm架構

Swarm作為一個管理Docker叢集的工具，首先需要將其部署起來，可以單獨將Swarm部署於一個節點。另外，自然需要一個Docker叢集，叢集上每一個節點均安裝有Docker。具體的Swarm架構圖可以參照下圖：

Swarm架構圖

Swarm架構中最主要的處理部分自然是Swarm節點，Swarm管理的物件自然是Docker Cluster，Docker Cluster由多個Docker Node組成，而負責給Swarm傳送請求的是Docker Client。

3.Swarm命令

Swarm架構圖可以讓大家對Swarm有一個初步的認識，比如Swarm的具體工作流程：Docker Client傳送請求給Swarm;Swarm處理請求併發送至相應的Docker Node;Docker Node執行相應的操作並返回響應。除此之外，Swarm的工作原理依然還不夠明瞭。

深入理解Swarm的工作原理，可以先從Swarm提供的命令入手。Swarm支援的命令主要有4個：swarm create、swarm manage、swarm join、swarm list。當然還有一個swarm help命令，該命令用於指導大家如何正確使用swarm命令，本文不再贅述。

3.1 swarm create

Swarm中swarm create命令用於建立一個叢集標誌，用於Swarm管理Docker叢集時，Docker Node的節點發現功能。

發起該命令之後，Swarm會前往Docker Hub上內建的發現服務中獲取一個全球唯一的token，用以唯一的標識Swarm管理的Docker叢集。

注：Swarm的執行需要使用服務發現，目前該服務內建與Docker Hub，該服務發現機制目前還在alpha版本，站點為：http://discovery-stage.hub/docker.com 。

3.2 swarm manage

Swarm中swarm manage是最為重要的管理命令。一旦swarm manage命令在Swarm節點上被觸發，則說明使用者需要swarm開始管理Docker叢集。從執行流程的角度來講，swarm經歷的階段主要有兩點：啟動swarm、接收並處理Docker叢集管理請求。

Swarm啟動的過程包含三個步驟：

► 發現Docker叢集中的各個節點，收集節點狀態、角色資訊，並監視節點狀態的變化;
► 初始化內部排程(scheduler)模組;
► 建立並啟動API監聽服務模組;

第一個步驟，Swarm發現Docker叢集中的節點。發現(discovery)是Swarm中用於維護Docker叢集狀態的機制。既然涉及到發現(discovery)，那在這之前必須先有註冊(register)。Swarm中有專門負責發現(discovery)的模組，而關於註冊(register)部分，不同的discovery模式下，註冊(register)也會有不同的形式。

目前，Swarm中提供了5種不同的發現(discovery)機制：Node Discovery、File Discovery、Consul Discovery、EtcD Discovery和Zookeeper Discovery。

第二個步驟，Swarm內部的排程(scheduler)模組被初始化。swarm通過發現機制發現所有註冊的Docker Node，並收集到所有Docker Node的狀態以及具體資訊。此後，一旦Swarm接收到具體的Docker管理請求，Swarm需要對請求進行處理，並通過所有Docker Node的狀態以及具體資訊，來篩選(filter)決策到底哪些Docker Node滿足要求，並通過一定的策略(strategy)將請求轉發至具體的一個Docker Node。

第三個步驟，Swarm建立並初始化API監聽服務模組。從功能的角度來講，可以將該模組抽象為Swarm Server。需要說明的是：雖然Swarm Server完全相容Docker的API，但是有不少Docker的命令目前是不支援的，畢竟管理Docker叢集與管理單獨的Docker會有一些區別。當Swarm Server被初始化並完成監聽之後，使用者即可以通過Docker Client向Swarm傳送Docker叢集的管理請求。

Swarm的swarm manage接收並處理Docker叢集的管理請求，即是Swarm內部多個模組協同合作的結果。請求入口為Swarm Server，處理引擎為Scheduler，節點資訊依靠Disocovery。

3.3 swarm join

Swarm的swarm join命令用於將Docker Node新增至Swarm管理的Docker叢集中。從這點也可以看出swarm join命令的執行位於Docker Node，因此在Docker Node上執行該命令，首先需要在Docker Node上安裝Swarm，由於該Swarm只會執行swarm join命令，故可以將其當成Docker Node上用於註冊的agent模組。

功能而言，swarm join可以認為是完成Docker Node在Swarm節點處的註冊(register)工作，以便Swarm在執行swarm manage時可以發現該Docker Node。然而，上文提及的5種discovery模式中，並非每種模式都支援swarm join命令。不支援的discovery的模式有Node Discovery與File Discovery。

Docker Node上swarm join執行之後，標誌著Docker Node向Swarm註冊，請求加入Swarm管理的Docker叢集中。Swarm通過註冊資訊，發現Docker Node，並獲取Docker Node的狀態以及具體資訊，以便處理Docker請求時作為排程依據。

3.4 swarm list

Swarm中的swarm list命令用以列舉Docker叢集中的Docker Node。

Docker Node的資訊均來源於Swarm節點上註冊的Docker Node。而一個Docker Node在Swarm節點上註冊，僅僅是註冊了Docker Node的IP地址以及Docker監聽的埠號。

使用swarm list命令時，需要指定discovery的型別，型別包括：token、etcd、file、zk以及。而swarm list並未羅列Docker叢集的動態資訊，比如Docker Node真實的執行狀態，或者Docker Node在Docker叢集中扮演的角色資訊。

4.總結

Swarm的架構以及命令並沒有很複雜，同時也為希望管理Docker叢集的Docker愛好者降低了學習和使用門檻。

俗話說得好，沒有一種一勞永逸的工具，有效的管理Docker叢集同樣也是如此。缺乏場景來談論Swarm的價值，意義並不會很大。相反，探索和挖掘Swarm的特點與功能，併為Docker叢集的管理提供一種可選的方案，是Docker愛好者更應該參與的事。

本文初步介紹Swarm，並涉及架構與命令，下期將帶來Swarm的具體使用，以及Swarm的架構剖析。