Docker Swarm容器管理 規畫部署一次傾囊相授

目前主要的容器管理技術是以Docker為主流,其中Google Kubernetes雖是最盛行的容器調度平台,但另一方面,Docker Swarm卻占有Docker原生與組態設定較為簡單的優勢,所以也受到不少使用者的支持。本文將介紹Docker Swarm容器調度管理平台的特色,並實際示範如何部署及設定。

根據知名市調機構RightScale在最新一期的「2018 State of the Cloud Report」調查報告中指出,目前在企業和組織當中使用的容器技術,主要是以Docker做為主要的容器管理技術。

至於在容器「調度」(Orchestration)方面,調查報告則顯示是以Kubernetes(K8S)為首要,同時K8S也是成長最快速的容器調度平台,如圖1所示。



▲圖1 RightScale市調統計結果,企業用於管理容器技術的優先順序。(圖片來源:RightScale - 2018 State of the Cloud Report)

什麼是Docker Swarm

簡單來說,當企業和組織的IT管理人員要使用容器技術時,只要透過Docker容器管理技術即可使用。然而,隨著企業和組織使用容器的數量逐漸變多時,便需要有一個能夠管理及調度眾多容器的平台,而Docker Swarm就是Docker公司所推出原生的容器調度管理平台。

Docker Swarm特色功能介紹

雖然在目前市場上主流的容器調度平台為Google推出的K8S(Kubernetes),但是Docker Swarm擁有Docker原生與組態設定較為簡單的優勢,所以在市場上的容器調度管理平台中仍占有一席之地,下列便是Docker Swarm容器調度管理平台的特色功能:

原生內建

從Docker 1.12版本之後,在Docker Engine中便直接原生內建Docker Swarm Mode(免費使用的Docker CE社群版本也支援)。只要透過Docker Engine CLI/API即可建立及管理Docker Swarm叢集,無須額外安裝及組態設定。

分散式設計

在小架構規模中,可以在1台Docker Host上同時運作Docker Swarm Services和Standalone Container角色。在中大型架構和規模內,可在Docker Swarm叢集中規劃Manager/Worker角色,即便運作環境中沒有共享儲存資源也沒有問題。

宣告式服務模組

在Docker Swarm叢集運作架構中,Docker Engine將會透過此種方式來定義應用程式堆疊。

容器規模縮放機制

管理人員可透過Swarm Managers管理機制,視容器的工作負載需求,隨時調整容器的運作規模大小(增加或減少運作中的容器數量)。

預期狀態調節

在Docker Swarm叢集運作架構內,會透過Docker Host的Swarm Managers管理機制,持續監控叢集的運作狀態並調度容器。舉例來說,在Swarm Worker角色中總共運作10個容器,但其中有2個容器因為Swarm Worker主機發生故障而停止服務,此時Swarm Managers管理機制就會在其他「存活」的Swarm Worker主機上再啟動2個容器。

跨主機網路環境

透過內建的Docker Overlay Network網路機制,在Docker Swarm叢集運作架構中,達成跨多台Docker Host主機互相溝通的網路機制。

自動探索服務機制

在Docker Swarm叢集運作架構中,會為「每項服務」分配唯一的Unique DNS Name,以便將使用者的服務請求工作負載平均分配至每個容器。管理人員也可視工作負載需求,搭配外部負載平衡機制,將服務請求工作負載平均分配給每個容器。

預設啟用TLS安全機制

在預設情況下,每台Docker Swarm節點主機之間會採用TLS相互認證與加密,如圖2所示,管理人員也可以搭配「--external-ca」參數指定採用公開Root CA或自簽CA。同時,當Docker Swarm叢集初始化完成後,系統會自動產生Manager Token和Worker Token,以便後續新加入的Docker Swarm節點主機使用。

值得注意的是,採用預設的TLS憑證,將會「每3個月」更新憑證,管理人員可透過參數「docker swarm update --cert-expiry


▲圖2 Docker Swarm叢集架構中Manager/Worker透過TLS加密機制通訊示意圖。(圖片來源:Docker Documentation - Manage swarm security with public key infrastructure (PKI))

滾動式更新

透過滾動式更新機制,管理人員可以輕鬆地更新容器映像檔版本,並且在發生問題時恢復到先前運作良好的版本。

Docker Swarm叢集運作架構簡介

在Docker Swarm容器叢集運作架構中將有兩種角色,分別是「Manager」和「Worker」,如圖3所示,其中擔任Manager角色的Docker Swarm節點主機,會透過Raft Consensus Algorithm機制在節點主機之間互相通訊,同時負責維護Orchestration Service、Cluster Management、Service Swarm Mode HTTP API Endpoints等等資源調度服務。


▲圖3 Docker Swarm叢集運作架構示意圖。(圖片來源:Docker Documentation - How nodes work)

至於擔任Worker角色的Docker Swarm節點主機,最主要的工作任務就是負責「運作容器」,而不會參與上述Manager角色所負責的資源調度工作任務。


值得注意的是,當企業和組織在規劃建置Docker Swarm容器叢集環境時,在Docker Swarm節點主機之間,必須開啟相關防火牆連接埠和通訊協定,如下列所示,否則屆時Docker Swarm節點主機之間會因為無法順利通訊而導致Docker Swarm容器叢集環境發生不可預期的錯誤:

TCP Port 2377:用於Docker Swarm叢集管理服務。

UDP Port 4789: 用於Docker Swarm叢集Overlay Network跨主機網路流量。

TCP/UDP Port 7946:用於Docker Swarm叢集節點主機互相通訊。

IP Protocol 50(ESP):用於Docker Swarm叢集Overlay Network跨主機網路流量進行加密時使用。

Docker Swarm叢集最佳建議做法

當企業和組織的IT管理人員在規劃Docker Swarm叢集架構時該如何規劃呢?應該要有多少台Docker Swarm節點主機擔任Manager和Worker角色呢?

原則上,在Docker Swarm叢集架構中,對於Manager與Worker角色的Docker Swarm節點主機數量並沒有限制。那麼到底要建立多少台數量的Docker Swarm節點主機才是適當?這便是接下來所要討論的重點。


追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!