docker集羣——初識Swarm

       爲Docker構建原生的集羣管理工具的計劃早在2014年初就開始了，當時做爲一個通訊協議項目，稱爲Beam。以後，它被實現爲一種後臺程序，使用Docker API來控制異構化的分佈式系統。項目從新命名爲libswarm，Swarmd是其後臺程序。項目保持了以前的理念，容許任何Docker客戶端鏈接到Docker Engine池裏。該項目的第三代被從新進行設計，使用相同的Docker Remote API集，而且在2014年11月份重命名爲「Swarm」。基本上，Swarm最重要的部分就是其遠程API；維護人員經過努力工做，讓這些API和Docker Engine的全部版本100%兼容。咱們稱Swarm第一代爲「Swarm v1」。

　　2016年2月份，核心團隊發現中央服務的擴展被限制以後，Swarm在內部被再次從新設計爲swarm.v2。此次，使用了去中心化的集羣設計。2016年6月份，發佈了SwarmKit，能夠做爲任意規模的分佈式服務的編排工具包。在DockerCon 2016大會上，Docker宣佈SwarmKit合併入Docker Engine。這一版本的Swarm稱爲「Swarm v2」或者「Swarm Mode」。

 

　　以後咱們會一步步體會到，三劍客（Docker Swarm、Docker Machine和Docker Compose）一塊兒使用時表現最佳，它們之間無縫集成在一塊兒，幾乎已經沒法將某一個當成單獨的部分。

• 使用Docker Machine，用戶能夠預配機器，能夠是虛擬機器也能夠是物理機器，並能夠在若干雲平臺以及純物理機器上運行docker容器。
• 使用Docker Compose，用戶能夠快速定義Dockerfile，經過簡單可是強大的YAML語法描述行爲，而且只須要將這些文件「組合」起來就能夠啓動應用程序。

集羣工具和容器管理

       集羣工具是一種軟件， 容許運維人員和單個終端溝通，其能夠向一系列資源發送命令前編排這些資源。取代在集羣上手動分發工做負載（容器）的方式，集羣工具用來自動化這些任務以及其餘不少任務。集羣工具用來自動化這些任務以及其餘不少任務。集羣工具決定在哪裏啓動job（容器），如何存儲job，何時最終重啓job等。運維人員僅僅須要配置一些行爲，據頂集羣的拓撲和規模、調優設置，而且啓用或者停用高級特性。Docker Swarm就是這樣一種容器的集羣工具。

        除了集羣工具，咱們還能夠選擇容器管理器平臺。它們不提供容器託管，可是它們和一個或者多個已有系統交互；這樣類型的軟件一般都是提供了很好的web接口、監控工具，以及其餘可視化或者高層級功能。Rancher和Tutum就是這樣的容器管理平臺。

Docker Swarm的基礎和架構

Docker自身對Swarm的描述以下：

　　Docker Swarm是Docker的原生集羣。它將Docker宿主機池轉變成單個虛擬的Docker宿主機。

Swarm是一種工具，讓用戶覺得本身管理的是單個巨大的Docker宿主機，而這個宿主機是由不少Docker宿主機組成的。這些主機看上去是一體的，而且使用一個命令行入口點。Swarm讓用戶在這些主機上編排而且操做必定數量的容器，使用常規的Docker工具、Docker原生工具或者python-docker客戶端，甚至能夠選擇直接curl到Docker Remote API上。

爲何使用Swarm

使用容器集羣解決方案有不少緣由。隨着應用程序的壯大成熟，咱們會遇到不少全新的需求，好比可擴展性、可管理性以及高可用性。市場上有不少可用的工具，使用Docker Swarm能夠帶來以下優點：

• 原生集羣：Swarm是Docker原生的，由Docker團隊和社區開發。不須要任何額外的需求，Swarm就能夠和Machine、Compose以及生態系統裏的其餘工具集成。
• 生產環境可用：Swarm v1在2015年11月份成熟，而且能夠在生產環境裏使用。研發團隊已經證實Swarm可以擴展到控制1000個節點的Engine。Swarm v2由於使用了去中心化的發現機制，容許構建數千個節點的集羣。
• 開箱即用：Swarm不要求用戶從新構建本身的應用程序來適配其餘的編排工具。用戶可使用本身的Docker鏡像和配置，不須要任何改動，就能夠實現大規模部署。
• 易於搭建和使用：Swarm很容易操做。僅僅經過在Machine命令裏添加一些參數，或者使用Docker1.12版本後的Docker命令，就能夠實現高效部署。將發現服務集成到Swarm Mode裏，使其能夠快速安裝——不須要搭建外部的Consul、Etcd或者Zookeeper集羣。
• 活躍的社區：Swarm是一個有活力的項目，有很是積極的社區支撐，開發很快速。
• Hub上可用：用戶不須要安裝Swarm，它是一個Docker鏡像（Swarm v1），所以用戶僅僅須要從Hub里拉去這個鏡像就能夠運行，或者它已經集成進Docker Engine。Swarm Mode已經集成進Docker1.12+版本了。

寵物模型  VS 牛羣模型

在建立而且利用基礎架構時有兩種對立的方案：寵物模型 VS 牛羣模型

• 寵物模型：管理員部署服務器或者虛擬機，而且對其持續進行維護。登陸機器或容器，安裝軟件，完成配置，而且確保一切運行正常。所以，這些機器或者容器是管理員的寵物。
• 牛羣模型：管理員把基礎架構當成牛羣模型時，他們並不關心基礎架構某個組件的命運。管理員不會登陸到任何單元裏，也不會作手動處理。相反，他們使用批量方案，藉助自動化工具完成部署、配置以及管理。若是某個服務器或者容器死機了，它會被自動復活，或者生成另外一個服務器或者容器來替代有問題的組件。所以，在這種場景下，運維人員管理的是牛羣模型。

Swarm特性

Swarm核心特性以下：

• Swarm v1支持1.6.0版本或更新版本的Docker Engine。從1.12版本開始，Swarm v2內嵌到了Docker Engine裏。
• Swarm每一個版本的API都和同版本的Docker API兼容。API能夠向後兼容一個版本。
• 在Swarm v1裏，爲多個Swarm主節點的實現，選主機制使用的是主庫（僅僅在使用發現服務，如Etcd、Consul或者Zookeeper部署Swarm時才支持）。
• 在Swarm v2裏，使用去中心化的機制來構建選主機制。Swarm v2再也不須要特定的發現服務，由於他集成了Etcd，這是Raft公式算法的一種實現。
• 在Swarm v1的術語裏，主Swarm master節點被稱爲primary（主節點），其餘master節點被稱爲replica（副本）。在Swarm v2裏，有Master和Worker節點的概念。集羣使用Raft自動管理主節點。
• 基礎和高級調度選項。schedule（調度器）是一種決定容器物理上放置於哪臺主機的算法。Swarm使用一系列內置的調度器。
• Constraint（約束條件）和affinity（共同關係）輔助運維人員作出調度決策。好比，某個用戶想要讓數據庫容器物理上接近，就能夠通知調度器去這麼作。約束條件和共同關係使用Docker Swarm label（標籤）。
• 在Swarm v2裏，使用內建DNS Round-Robin實現集羣內的負載均衡，也支持外部負載均衡，經過路由網絡機制，由IPVS實現。
• 高可用和故障恢復機制意味着用戶能夠建立超過一個master的Swarm。所以，若是某個master服務宕機了，還有其餘master能夠繼續控制。當構建至少3個節點的集羣時，默承認用Swarm v2。全部節點均可以做爲master節點。另外，Swarm v2包括健康指標信息。

其餘開源編排工具的不一樣之處:

能夠參考：巔峯對決之Swarm、Kubernetes、Mesos

Swarm v1架構

 

先從管理器部分開始介紹，圖片的左側有一個標爲Docker Swarm API 的長方形。Swarm暴露出一系列和Docker相似的遠程API，用戶可使用任意Docker客戶端鏈接到Swarm上。可是，Swarm API和標準的Docker遠程API略有不一樣，由於Swarm API還包含集羣相關的信息。好比，在Docker Engine上運行docker info能夠獲得單個Engine的信息，可是若是在Swarm集羣上調用docker info，則會獲得集羣裏的節點數量以及每一個節點的信息和健康情況。

Docker Swarm API 旁邊的長方形是集羣抽象。這是一個抽象層，容許不一樣類型的集羣實現爲Swarm的後端，而且共享同一組Docker遠程API。目前有兩種集羣后端實現：內建Swarm集羣實現和Mesos集羣實現。Swarm集羣和內建調度器的長方形表示內建的Swarm集羣實現，而標識爲Mesos集羣的長方形則表示Mesos的集羣實現。

Swarm後端的內建調度器包含一些調度策略。兩種策略分別是Spread和BinPack，若是對Swarm策略比較熟悉，就會注意到這裏缺失了Random策略。Random策略沒有包含在這裏是由於其僅做爲測試用途。

和調度策略並排，Swarm仍是用了一系列調度過濾器，過濾掉不知足條件的節點。這裏有六種類型的過濾器：Health、Port、Container Slots、Dependency、Affinity和Constraint。當調度新建的容器時，它們就以這個順序應用到過濾器上。

在代理部分，Swarm代理嘗試將其Engine的地址註冊到發現服務裏。

最後，中間的部分——發現服務，在代理和管理之間協調Engine的地址。目前使用的基於代理的發現服務是LibKV，它將發現功能委派給用戶所選擇的鍵值存儲，Consul、Etcd或者Zookeeper。相對比而言，咱們還能夠不使用任何鍵值存儲，僅僅使用Docker Swarm管理器。該模式稱爲無代理髮現，包括File和Node（在命令行指定地址）。

術語

• Docker Engine是運行在宿主機上的Docker daemon。
• Docker Compose是一個工具，以YAML的格式描述多容器服務的架構方式。
• Docker stack是建立多容器的應用程序（由Compose描述），而不是單個容器的二進制結果。
• Docker daemon和 Docker Engine 這兩個術語意思同樣，能夠互相替換。
• Docker客戶端是打包在同一個docker可執行文件裏的客戶端程序。好比，當運行docker run時，使用的就是Docker客戶端。
• Docker網絡是軟件定義的網絡，將一系列容器連接到同一個網絡裏。默認使用Docker Engine自帶的libnetwork（https://github.com/docker/libnetwork）實現。可是用戶可使用插件選擇部署第三方的網絡驅動。
• Docker Machine是一個工具，用來建立可以運行Docker Engine的稱爲機器的主機。
• Swarm v1裏的Swarm節點是預先安裝了Docker Engine的機器，而且同時運行着Swarm的代理程序。Swarm節點會將其自身註冊到發現服務裏。
• Swarm v1裏的Swarm master是運行Swarm管理器程序的機器。Swarm master從其發現服務裏讀取Swarm節點的地址。
• 發現服務是Docker提供的基於令牌的服務或者自託管的服務。對於自託管的服務，用戶能夠運行HashiCorp Consul、CoreOS Etcd，或者Apache Zookeeper做爲鍵值存儲來提供發現服務。
• 選主是Swarm Master所實現的機制，用來肯定主節點。在主節點下線以前，其餘Master節點都做爲副本角色存在，主節點下線後，就會再次啓動選主程序。Swarm Master的數量必定是奇數。
• SwarmKit是由Docker發佈的全新Kit，用來抽象編排。理論上，它應該可以運行任何類型的服務，可是實際目前它僅僅編排容器或者容器集。
• Swarm Mode是全新的Swarm，自Docker 1.12版本後能夠用，它將SwarmKit集成到了Docker Engine裏。
• Swarm Master（在Swarm Mode裏）是一個管理集羣的節點：它調度服務，維護集羣的配置（節點、角色和標籤），而且確保僅僅存在一個集羣領導者。
• Swarm Worker（在Swarm Mode裏）是一個運行任務的節點，運行如託管服務器任務。
• 服務是工做負載的抽象。好比，用戶可讓服務「nginx」複製10次，意味着用戶將有10個任務（10個nginx容器）分佈在集羣上，而且由Swarm自身作負載均衡。
• 任務是Swarm的工做單元。一個任務就是一個容器。