『高階篇』docker之DockerSwarm的瞭解（27）
這次一起了解下docker Swarm，什麼是dockerSwarm。
什麼是docker Swarm
- 產品背景
使用docker的流程，ssh到一臺伺服器，執行docker命令來執行本機的docker服務，隨著docker發展，越來越多的服務想要執行在docker容器中，如果在這樣挨個的登入在每個ssh主機上管理容器，就非常的吃力了，而且我們的應用也需要高可用，也需要避免單點的故障，docker現有的能力已經很難滿足這樣的需求了，在這樣的背景下，docker社群就產生類的dockerSwarm專案。
- 概念
什麼是swarm，swarm這個名詞比較貼切，swarm這個單詞的意思就是動物的叢集行為，比如我們常見的蜂群，魚群，大雁南飛都可以成為swarm，swarm專案就是把多個docker 例項聚集在一起形成一個大的docker例項，對外提供叢集服務，同時這個叢集提供所有的api，使用者可以相使用docker例項一樣使用docker的叢集。
-
昨日今日
>docker swarm在1.12之前是一個獨立的專案，需要單獨下載，在1.12之後該專案就合併到了docker中，成為docker的子專案，目前docker唯一的一個原生支援docker叢集的管理工具。
docker swarm的架構圖
下面這個圖，就可以看到docker swarm管理docker的一個架構圖。以前使用docker命令列是針對docker主機的，然後到這臺機器上單獨的控制這臺機器上的主機，有了swarm之後，客戶端命令是針對docker叢集的。它的命令幾乎等同於docker的原生命令，它把命令傳送給swarm，swarm選擇傳送一個節點去真正的執行，swarm是通過docker自帶的遠端的API，來實現對docker的控制。
下面這個圖，這張圖跟上面一張圖描述的是一個事情，只不過它暴露了更多的的細節，上面的大框和下面的小框都代表了一臺伺服器，物理機或者虛擬機器，我們從上面說，上面是swarm的一個manager節點，管理這個worker節點，可以看到管理了多少個cpu，多少個記憶體，每個上面執行的服務，每個服務的狀況，比如他們的標籤，他們的健康狀態，Manager管理者每個節點的生命週期，比如加入一個節點，下線一個節點，manager還管理者每個服務的生命週期，服務的部署，更新，停止，刪除，Node節點比較單純他就運行了docker daemon，因為在1.12之後swarm已經融入了docker本身，開發一個遠端的api給manager節點排程，執行具體的服務和容器，下面咱們一起看看服務的部署流程是怎樣的，在這樣的架構上是如何體現的。
環境的搭建
想想之前學習的mesos，需要先安裝docker，Marathon，zookeeper，加入我們現在有5臺liunx伺服器，每個上面都裝有docker，選擇一臺作為manager，上面執行下圖的第一條命令， 執行完之後會打印出來一個token作為dockerSwarm的憑證，然後在每個worker節點下執行第二條命令，表示要加入叢集，只需要token和對應manager節點的ip和埠號，叢集環境就搭建完畢了
如何部署
客戶端的發起docker命令，兩種方式
- 直接ssh到manager節點，執行docker命令。
- 通過遠端訪問的方式，通過Remote API呼叫manager上的docker命令，我們這張圖畫的就是第二種方式。
docker Client 在manager節點的外邊，假如執行了docker service create，先會經過docker Deamon接受這條命令，傳給Scheduler模組，Scheduler模組主要實現排程的功能，負責選擇出來最優的節點，裡面包含了2個子模組，Fiter 和Strategy，Fiter很明顯是過濾節點，用來找出滿足條件的節點（資源足夠多，節點正常的），Strategy是過濾出來後選擇出最優的節點（對比選擇資源剩餘最多的節點，或者找到資源剩餘最少的節點），當然Fiter 和Strategy都是使用者可以單獨定製的，中間的Cluster是抽象的worker節點叢集，包含了Swarm節點裡面每個節點的資訊，右邊的Discovery是資訊維護的模組，比如Label Health。Cluster最終呼叫容器的api，完成容器啟動的劉而成。
排程模組
使用者在建立服務的時候，選擇最優的節點，選擇最優節點的管理分為2個階段。
過濾和策略
filter
- Constraints
約束過濾器，根據當前的作業系統的型別，核心版本，儲存的型別進行指標上的約束，也可以自定義約束。當前系統啟動的時候可以通過label指定當前機器所具有的特性然後通過Constraints把他們過濾出來。
- Affinity
親和性過濾器，支援容器的親和性和映象的親和性，比如一個應用，DB容器和web容器放在一起，就可以通過這個來實現，
- Dependency
依賴過濾器，link等等吧Dependency會將這些容器放在同一個節點上，有依賴管理的會將建立的容器和依賴的容器放在同一個節點上。
- Health filter
健康過濾器，根據節點的健康狀態進行過濾，把有問題的節點去掉。
- Ports filter
埠過濾器，根據埠的使用情況進行過濾，比如一個8080埠在某個主機上被佔用，某些主機未被佔用，會選用未被佔用的那些主機。
Strategy
- Binpack
在同等情況下，會使用資源最多的節點，通過這個策略可以讓容器聚集起來。
- Spread
在同等情況下，會使用資源最少的節點，通過這個策略可以讓容器均勻的分佈在每個節點上。
- Random
隨機選擇一個節點。
服務發現
稍微有點複雜，根據場景來說吧
-
>基於物理網路之上的虛擬網路，Swarm的上層應用不在依賴於物理網路，並且能夠讓下面的物理網路保持不變，老鐵就理解到這裡就可以了，網路本身涉及到的東西太多了，應該也聽過網路工程師，既然有這個職位肯定這個不是那麼容易學的，在這裡就不會深入的進行詳解了。
PS：假定運行了一個nginx服務2個例項，nginx1 和nginx2，容器內的埠是80，主機內的埠是8080， 這2個容器分別執行在node2和node3上，看到了吧node1雖然沒有執行例項但是依然有8080埠在監聽，一個叢集在所有的worker節點上都是可以訪問到的，隨便選一個節點輸入它的ip和8080埠就可以訪問到，或者搭建一個負載均衡External LB，負責輪詢的方式訪問每個上邊的8080埠，為什麼在每個節點上都可以訪問我們的服務呢？每個服務啟動後所有的節點都會更新自己的VIP LB，把新的服務埠號和服務的資訊建立一個關係，VIP LB是基於虛擬IP的負載均衡，VIP LB可以通過虛擬IP解析到真實IP，然後訪問到服務。
-
Ingress+ link
>就型別docker-compose，可以通過docker-compose.yml檔案創建出來一組容器，他們之前通過link的方式進行訪問，其實這種就型別docker-compose的link網路。
PS：也就是在Ingress之上多了一個link的場景，可以通過link的方式訪問，也不需要主機的網路，link怎麼實現的呢，如果讓一個容器link到另一個容器很容易畢竟他們在一臺主機上，一個服務link到另一個服務其實沒有那麼簡單了，可能包含一個容器，也可能包含很多個容器，可能執行在一臺機器上，也可能分佈在多臺機器上，我們如何實現可以通過名字來訪問彼此呢，這用到了容器的dns，這裡的nginx服務依賴於tomcat服務，nginx有2個例項，tomcat有一個例項，所有的nginx的容器都會對tomcat的解析，把它解析到tomcat的VIP，VIP負責做負載均衡，原理就是這樣的原理，link的方式外部是訪問不到的。link只適合swarm叢集內部的場景。
-
自定義網路
>使用自定義的網路，首先要建立網路，所有的網路都可以通過名字來連線彼此，而不需要link操作了。只要連線這個網路的彼此，都可以通過名字。底層來說它和link是型別的。通過dns來解析應用的名字。然後通過VIP LB的形式來進行負載均衡。
#建立自定義網路 docker network create --driver=overlay --attachable mynet
#建立服務 dockerservice create -p 80:80 --network=mynet --name nginx nginx
Ingress 支援外部訪問，Ingress+ link和自定義網路只能容器間進行訪問。
服務編排
- 服務部署&服務發現（上邊說到了）
- 服務更新 — docker service update
- 服務擴縮容 — docker service scale
Swarm
- 對外以Docker API 介面呈現
好處直接可以平滑的切換到docker swarm上。基本不需要改變現有的系統
- 容易上手，學習成本低
之前docker的經驗可以完成繼承過來。
- 輕量級，節省資源
專注docker叢集的管理。外掛的機制swarm的模組都抽象出來對應的API，可以根據自己的特點進行定製實現。
- 對docker命令引數支援完善
跟docker同步釋出，docker的新的特性在dockerSwarm上都可以得到體現。
PS：docker Swarm基本都瞭解的差不多了。下次開始docker swarm的環境搭建。
>>原創文章，歡迎轉載。轉載請註明：轉載自，謝謝！>>原文連結地址：上一篇:已是最新文章