DockerSwarm入門（二）配置選項與基本執行環境要求

本文講的是Docker Swarm入門（二）配置選項與基本執行環境要求，【編者的話】本文作者Matt Bajor熱衷Docker及相關產品的研究，本文是他寫的Docker Swarm入門系列的第二篇，主要介紹了Docker Swarm的最基本的配置選項和執行要求。作者通過實際例子介紹了Swarm的幾個基本的發現服務及其對於容器的排程策略，最後還介紹瞭如何在Swarm叢集通訊中使用安全傳輸協議。

Docker Swarm叢集執行環境的最低要求

建立基本的Docker Swarm叢集對執行環境的要求並不是很高。事實上，我們可以將Swarm守護程式執行在現有的Docker主機上，使其在不新增任何其他的硬體或虛擬資源的情況下就能夠直接執行，這種方式絕對是可行的（也許不是最好的做法）。此外，在執行最基本的Docker Swarm叢集的過程中，在基於發現機制識別檔案或節點的時候，並不需要新增其他的基礎設施（當然除了Docker本身）。

我個人認為在另一臺伺服器上執行Swarm master服務本身是一個不錯的想法。該伺服器並不需要大量的資源，但它卻需要用很多的檔案描述符來處理所有的TCP流量的輸入和輸出。在下面例子中，我會使用dockerswarm01來作為專用的Swarm master服務。

配置選項

在預設情況下Swarm有各種各樣的配置，當涉及到執行守護程式及其配套的基礎設施時，配置過程的靈活性就變得很強。下面列出了不同類別的配置選項以及它們是如何進行配置的。

發現服務

Swarm使用的發現服務是一種維護叢集狀態的機制。它可以與各種後端服務協同工作，基本的工作流程都是一致的，都涉及到以下的概念：

• 後端服務維護著Docker結點的列表，這些服務應該是叢集的一部分。
• 通過節點的列表，Swarm 會檢查每一個結點的健康狀況並且跟蹤進出叢集的節點。

節點發現

節點發現僅需要通過命令列來完成。這是最基本的發現機制型別，它並不需要對配置檔案或者其他相關內容進行維護。Swarm守護程式使用節點發現的啟動命令會是這樣：

swarm manage 
--discovery dockerhost01:2375,dockerhost02:2375,dockerhost03:2375 
-H=0.0.0.0:2375

檔案發現

檔案發現利用放置在檔案系統中 （例如：/etc/swarm/cluster_config)的配置檔案，使用<IP>:<Port>的格式來列出叢集中的Docker主機。雖然該列表是靜態的，但是通過健康檢查服務仍然可以確定健康和不健康的節點，並且可以過濾對不健康的節點請求。基於檔案發現的啟動命令和配置檔案的例子如下：

sswarm manage 
--discovery file:///etc/swarm/cluster_config 
-H=0.0.0.0:2375

#/etc/swarm/cluster_config
dockerhost01:2375
dockerhost02:2375
dockerhost03:2375

Consul發現

Docker Swarm也支援Consul發現。它的工作原理是利用Consul的鍵值儲存，來維護構成叢集的伺服器的<IP>:<Port>列表。在這種配置模式下，每個Docker主機會以join模式執行一個Swarm守護程式，並且指向Consul叢集的HTTP介面（進行服務註冊）。這樣的操作使Docker主機的配置、執行以及安全維護產生了一定的開銷，但開銷並不大。Swarm客戶端將會進行這樣的操做：

swarm join --discovery consul://consulhost01/swarm 
# This can be an internal IP as long as the other
# Docker hosts can reach it.
--addr=10.100.199.200:2375

之後Swarm master會從Consul服務中讀取主機列表，它以這樣的方式執行：

swarm manage --discovery consul://consulhost01/swarm -H=0.0.0.0:2375

這些基於鍵/值的基本配置模式會引發一個問題：Swarm叢集的健康狀況檢查服務如何與Swarm客戶端（在 join模式下）協同工作？由於通過鍵/值儲存的列表本身就是動態的，它是否需要運內部Swarm健康檢查服務呢？我對相關的功能並不熟悉，所以不妄加評論，但這個問題應該引起注意。

EtcD發現

EtcD發現的工作方式與Consul發現大致相同。叢集中的每個Docker主機會以join模式執行一個Swarm守護程式，並指向一個EtcD的終端（endpoint）。這樣EtcD可以通過心跳檢測來維護一個記錄叢集中活躍伺服器（active servers）的列表。一個執行有標準Docker守護程式的Docker主機會同時執行一個具有類似配置Swarm的客戶端：

swarm join 
--discovery etcd://etcdhost01/swarm 
--addr=10.100.199.200:2375

通過以下命令，Docker Swarm master 服務會連線EtcD，搜尋所提供的路徑資訊並且成節點列表：

swarm manage 
--discovery etcd://etcdhost01/swarm 
-H=0.0.0.0:2375

Zookeeper發現

Zookeeper發現模式與其他基於鍵/值對儲存的配置模式類似。一個ZK集合被建立之後用於儲存主機資訊列表同時還有一個與Docker一起執行的客戶端，這個客戶端可以向鍵/值儲存服務傳送心跳檢測資訊，幾乎可以實時地維護列表。Swarm master也會連線到ZK集合並使用/swarm路徑下的的資訊來維護主機列表(之後會進行健康檢測)。

Swarm客戶端（與Docker一起）：

swarm join 
# All hosts in the ensemble should be listed
--discovery zk://zkhost01,zkhost02,zkhost03/swarm 
--addr=10.100.199.200

Swarm Master：

swarm manage 
--discovery zk://zkhost01,zkhost02,zkhost03/swarm 
-H 0.0.0.0:2375

Hosted Token Based Discovery (預設)

我還沒有使用過這個功能，在這點上沒有多少可以總結的。

排程

排程機制的主要功能是選擇在哪個伺服器上建立並啟動一個容器。它是由一個裝箱演算法（packing algorithm）和過濾器（或標籤）組合而成。每個Docker守護程式啟動的時候都帶著一組標籤，像以下這樣：

docker -d 
--label storage=ssd 
--label zone=external 
--label tier=data 
-H tcp://0.0.0.0:2375

然後，當開啟一個Docker容器時，Swarm將基於過濾器選擇一組伺服器，然後根據排程機制來分配每次執行的命令。過濾器會告訴Swarm哪些伺服器上的容器是可用的或是不可用的，之後排程器會把命令分發到可用的伺服器上。以下是幾個過濾機制：

• 約束（Constraint） 這是利用了一個Docker守護程式開始的標籤。目前，它只支援`=`，（譯註：官方doc裡是`==`，請讀者遵循最新的官方doc）但在將來它可能支援`!=`。節點必須符合所有的由容器提供的約束以便能進行匹配排程。比如按照下面的例子來開啟有一些約束的容器：

docker run -d -P 
-e constraint:storage=ssd 
-e constraint:zone=external 
-t nginx

• 類同（Affinity ）
  類同可以以兩種方式工作：容器類同或映象類同。為了在同一臺主機上啟動兩個容器可以執行以下命令：

  docker run -d -P 
  --name nginx 
  -t nginx
  
  docker run -d -P 
  --name mysql 
  -e affinity:container=nginx 
  -t mysql
  

  由於Swarm並沒有對映象進行管理，設定類同映象也是可行的。這意味著一個容器僅能在已包含映象的節點上啟動。這就避免了在開啟一個容器之前需要在後臺等待拉取映象的過程。舉個例子：

  docker run -d -P 
  --name nginx 
  -e affinity:image=nginx 
  -t nginx
  

• 埠（Port） 埠過濾可以防止在同一主機上任意兩個具有相同靜態埠對映的容器啟動。這樣做的意義很大，你不能重複在Docker主機上埠對映。例如，兩個節點以-p 80:80開啟不會被允許在同一Docker主機上執行。
• 健康狀況（Healthy） 它阻止了對不健康節點進行排程。

一旦Swarm將主機列表限制在一組符合上述條件的節點上，它就會讓對容器進行排程，從以上結點中選出一個，在上面建立並啟動容器。目前以下排程是器內建的：

• 隨機分配（Random） 將容器隨機分佈在可用的結點上。
• 裝箱（Binpacking） 用容器將節點填滿（每個容器得到的資源固定），然後再移動到下一個節點。如果在執行時需要動態地給容器分配資源，採用這個策略可能會使過程變得更復雜。這意味著即使為每個容器的記憶體和CPU設定上限，也並不能保證執行期間一切正常。我個人比較喜歡讓容器彼此之間競爭，看哪個容器能得到資源。

還有一些其他的排程機制正在開發中，比如平衡策略以及新增Apache Mesos的特性。

TLS（傳輸層安全協議Transport Layer Security）

令人高興的是，Swarm可以在TLS啟用下執行。這使得客戶端、Swarm守護程式以及Docker守護程式之間的互動變更安全。這是一件好事，因為在我研究安全方面的夥伴看來，在網路中並沒有邊界。

為了實現以上目標，需要一個包含CA的完整PKI，但我有個解決辦法，在另一篇已釋出的文章裡會提到，它是如何為Docker與Swarm產生所需的TLS證書。

按照上面部落格中的內容，一旦證書生成並安裝，Docker與Swarm守護程式就可以進行如下操作：
Docker：

docker -d 
--tlsverify 
--tlscacert=/etc/pki/tls/certs/ca.pem 
--tlscert=/etc/pki/tls/certs/dockerhost01-cert.pem 
--tlskey=/etc/pki/tls/private/dockerhost01-key.pem 
-H tcp://0.0.0.0:2376

Swarm master：

swarm manage 
--tlsverify 
--tlscacert=/etc/pki/tls/certs/ca.pem 
--tlscert=/etc/pki/tls/certs/swarm-cert.pem 
--tlskey=/etc/pki/tls/private/swarm-key.pem  
--discovery file:///etc/swarm_config 
-H tcp://0.0.0.0:2376

然後客戶端必須知道連線TLS。以下是環境變數設定：

export DOCKER_HOST=tcp://dockerswarm01:2376
export DOCKER_CERT_PATH="`pwd`"
export DOCKER_TLS_VERIFY=1

這樣你就設定好了TLS。

還有更多精彩內容！

當涉及到複雜的叢集軟體的配置時，還有很多內容可以討論，但我覺得對於一個概述性的介紹來說，以上內容已經足夠，這可以讓你設定、執行並思考如何配置你的Swarm叢集。下一篇部落格中我會介紹關與Swarm叢集架構的一些例子。敬請關注，並歡迎在下面發表評論！

所有這些在博文背後的研究能成為可能歸功於我工作的公司： Rally Software in Boulder, CO.。每季度我們至少有一個駭客周，它使我們能夠研究很棒的東西，像Docker Swarm。如果您想切入正題，直接開始Vagrant 例子，這裡有一個repo，它是我在2014年Q1駭客周研究的成果：

• https://github.com/technolo-g/docker-swarm-demo

原文連結：Intro to Docker Swarm: Part 2 – Configuration Options and Requirements （翻譯：田浩浩審校：王哲）

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
田浩浩，悉尼大學USYD碩士研究生，目前在珠海從事Android應用開發工作。業餘時間專注Docker的學習與研究，希望通過DockerOne把最新最優秀的譯文貢獻給大家，與讀者一起暢遊Docker的海洋。

原文釋出時間為：2015-02-03 

本文作者：田浩浩

本文來自雲棲社群合作伙伴DockerOne，瞭解相關資訊可以關注DockerOne。

原文標題：Docker Swarm入門（二）配置選項與基本執行環境要求