Docker Stack配置文件詳解

Stack 文件就是 Docker Compose 文件。唯一的要求就是 version：一項需要是“3.0”或者更高的值。具體可以關(guān)注 Docker 文檔中關(guān)于 Compose 文件的最新版本信息。

在 Docker 根據(jù)某個 Stack 文件部署應用的時候，首先會檢查并創(chuàng)建 networks：關(guān)鍵字對應的網(wǎng)絡。如果對應網(wǎng)絡不存在，Docker 會進行創(chuàng)建。

網(wǎng)絡

networks:
front-tier:
back-tier:
payment:
driver: overlay
driver_opts:
encrypted: 'yes'

該文件中定義了 3 個網(wǎng)絡：front-tier、back-tier 以及 payment。默認情況下，這些網(wǎng)絡都會采用 overlay 驅(qū)動，新建對應的覆蓋類型的網(wǎng)絡。但是 payment 網(wǎng)絡比較特殊，需要數(shù)據(jù)層加密。

默認情況下，覆蓋網(wǎng)絡的所有控制層都是加密的。如果需要加密數(shù)據(jù)層，有兩種選擇。

? 在 docker network create 命令中指定 -o encrypted 參數(shù)。

? 在 Stack 文件中的 driver_opts 之下指定 encrypted:'yes'。

數(shù)據(jù)層加密會導致額外開銷，而影響額外開銷大小的因素有很多，比如流量的類型和流量的多少。但是，通常額外開銷會在 10% 的范圍之內(nèi)。

正如前面提到的，全部的 3 個網(wǎng)絡均會先于密鑰和服務被創(chuàng)建。

密鑰

密鑰屬于頂級對象，在當前 Stack 文件中定義了 4 個。

secrets:
postgres_password:
external: true
staging_token:
external: true
revprox_key:
external: true
revprox_cert:
external: true

注意，4 個密鑰都被定義為 external。這意味著在 Stack 部署之前，這些密鑰必須存在。

當然在應用部署時按需創(chuàng)建密鑰也是可以的，只需要將 file: 替換為 external: true。但該方式生效的前提是，需要在主機文件系統(tǒng)的對應路徑下有一個文本文件，其中包含密鑰所需的值，并且是未加密的。這種方式存在明顯的安全隱患。

服務

部署中的主要操作都在服務這個環(huán)節(jié)。

每個服務都是一個 JSON 集合(字典)，其中包含了一系列關(guān)鍵字。我們會依次介紹每個關(guān)鍵字，并解釋操作的具體內(nèi)容。

⒈ reverse_proxy 服務

正如讀者所見，reverse_proxy 服務定義了鏡像、端口、密鑰以及網(wǎng)絡。

reverse_proxy:
image: dockersamples/atseasampleshopapp_reverse_proxy
ports:
- "80:80"
- "443:443"
secrets:
- source: revprox_cert
target: revprox_cert
- source: revprox_key
target: revprox_key
networks:
- front-tier

image 關(guān)鍵字是服務對象中唯一的必填項。顧名思義，該關(guān)鍵字定義了將要用于構(gòu)建服務副本的 Docker 鏡像。

Docker 是可選項，除非指定其他值，否則鏡像會從 Docker Hub 拉取?？梢酝ㄟ^在鏡像前添加對應第三方鏡像倉庫服務 API 的 DNS 名稱的方式，來指定某個鏡像從第三方服務拉取。例如 Google 的容器服務的 DNS 名稱為 gcr.io。

Docker Stack 和 Docker Compose 的一個區(qū)別是，Stack 不支持構(gòu)建。這意味著在部署 Stack 之前，所有鏡像必須提前構(gòu)建完成。

ports 關(guān)鍵字定義了兩個映射。

? 80:80 將 Swarm 節(jié)點的 80 端口映射到每個服務副本的 80 端口。

? 443:443 將 Swarm 節(jié)點的 443 端口映射到每個服務副本的 443 端口。

默認情況下，所有端口映射都采用 Ingress 模式。這意味著 Swarm 集群中每個節(jié)點的對應端口都會映射并且是可訪問的，即使是那些沒有運行副本的節(jié)點。

另一種方式是 Host 模式，端口只映射到了運行副本的 Swarm 節(jié)點上。但是，Host 模式需要使用完整格式的配置。例如，在 Host 模式下將端口映射到 80 端口的語法如下所示。

ports:
- target: 80
published: 80
mode: host

推薦使用完整語法格式，這樣可以提高易讀性，并且更靈活(完整語法格式支持 Ingress 模式和 Host 模式)。但是，完整格式要求 Compose 文件格式的版本至少是 3.2。

secret 關(guān)鍵字中定義了兩個密鑰：revprox_cert 以及 revprox_key。這兩個密鑰必須在頂級關(guān)鍵字 secrets 下定義，并且必須在系統(tǒng)上已經(jīng)存在。

密鑰以普通文件的形式被掛載到服務副本當中。文件的名稱就是 stack 文件中定義的 target 屬性的值，其在 Linux 下的路徑為 /run/secrets，在 Windows 下的路徑為 C:\ProgramData\Docker\secrets。Linux 將 /run/secrets 作為內(nèi)存文件系統(tǒng)掛載，但是 Windows 并不會這樣。

本服務密鑰中定義的內(nèi)容會在每個服務副本中被掛載，具體路徑為 /run/secrets/revprox_cert 和 /run/secrets/revprox_key。若將其中之一掛載為 /run/secrets/uber_secret，需要在 stack 文件中定義如下內(nèi)容。

secrets:
- source: revprox_cert
target: uber_secret

networks 關(guān)鍵字確保服務所有副本都會連接到 front-tier 網(wǎng)絡。網(wǎng)絡相關(guān)定義必須位于頂級關(guān)鍵字 networks 之下，如果定義的網(wǎng)絡不存在，Docker 會以 Overlay 網(wǎng)絡方式新建一個網(wǎng)絡。

⒉ database 服務

數(shù)據(jù)庫服務也在 Stack 文件中定義了，包括鏡像、網(wǎng)絡以及密鑰。除上述內(nèi)容之外，數(shù)據(jù)庫服務還引入了環(huán)境變量和部署約束。

database:
image: dockersamples/atsea_db
environment:
POSTGRES_USER: gordonuser
POSTGRES_DB_PASSWORD_FILE: /run/secrets/postgres_password
POSTGRES_DB: atsea
networks:
- back-tier
secrets:
- postgres_password
deploy:
placement:
constraints:
- 'node.role == worker'

environment 關(guān)鍵字允許在服務副本中注入環(huán)境變量。在該服務中，使用了 3 個環(huán)境變量來定義數(shù)據(jù)庫用戶、數(shù)據(jù)庫密碼的位置(掛載到每個服務副本中的密鑰)以及數(shù)據(jù)庫服務的名稱。

environment:
POSTGRES_USER: gordonuser
POSTGRES_DB_PASSWORD_FILE: /run/secrets/postgres_password
POSTGRES_DB: atsea

將三者作為密鑰傳遞會更安全，因為這樣可以避免將數(shù)據(jù)庫名稱和數(shù)據(jù)庫用戶以明文變量的方式記錄在文件當中。

該服務還在 deploy 關(guān)鍵字下定義了部署約束。這樣保證了當前服務只會運行在 Swarm 集群的 worker 節(jié)點之上。

deploy:
placement:
constraints:
- 'node.role == worker'

部署約束是一種拓撲感知定時任務，是一種很好的優(yōu)化調(diào)度選擇的方式。Swarm 目前允許通過如下幾種方式進行調(diào)度。

? 節(jié)點ID，如 node.id==o2p4kw2uuw2a。

? 節(jié)點名稱，如 node.hostname==wrk-12。

? 節(jié)點角色，如 node.role!=manager。

? 節(jié)點引擎標簽，如 engine.labels.operatingsystem==ubuntu16.04。

? 節(jié)點自定義標簽，如 node.labels.zone==prod1。

注意： == 和 != 操作符均支持。

⒊ appserver 服務

appserver使用了一個鏡像，連接到 3 個網(wǎng)絡，并且掛載了一個密鑰。此外 appserver 服務還在 deploy 關(guān)鍵字下引入了一些額外的特性。

appserver:
image: dockersamples/atsea_app
networks:
- front-tier
- back-tier
- payment
deploy:
replicas: 2
update_config:
parallelism: 2
failure_action: rollback
placement:
constraints:
- 'node.role == worker'
restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 120s
secrets:
- postgres_password

接下來進一步了解 deploy 關(guān)鍵字中新增的內(nèi)容。

首先，services.appserver.deploy.replicas = 2 設置期望服務的副本數(shù)量為 2。缺省情況下，默認值為 1。如果服務正在運行，并且需要修改副本數(shù)，則需要顯示聲明該值。這意味著需要更新 stack 文件中的 services.appserver.deploy.replicas，設置一個新值，然后重新部署當前 stack。

services.appserver.deploy.update_config 定義了 Docker 在服務滾動升級的時候具體如何操作。對于當前服務，Docker 每次會更新兩個副本(parallelism)，并且在升級失敗后自動回滾。

回滾會基于之前的服務定義啟動新的副本。failure_action 的默認操作是 pause，會在服務升級失敗后阻止其他副本的升級。failure_action 還支持 continue。

update_config:
parallelism: 2
failure_action: rollback

services.appserver.deploy.restart-policy 定義了 Swarm 針對容器異常退出的重啟策略。當前服務的重啟策略是，如果某個副本以非 0 返回值退出(condition: onfailure)，會立即重啟當前副本。重啟最多重試 3 次，每次都會等待至多 120s 來檢測是否啟動成功。每次重啟的間隔是 5s。

restart_policy:
condition: on-failure
delay: 5s
max_attempts: 3
window: 120s

⒋ visualizer 服務

visualizer 服務中指定了鏡像，定義了端口映射規(guī)則、更新配置以及部署約束。此外還掛載了一個指定卷，并且定義了容器的優(yōu)雅停止方式。

visualizer:
image: dockersamples/visualizer:stable
ports:
- "8001:8080"
stop_grace_period: 1m30s
volumes:
- "/var/run/docker.sock:/var/run/docker.sock"
deploy:
update_config:
failure_action: rollback
placement:
constraints:
- 'node.role == manager'

當 Docker 停止某個容器的時候，會給容器內(nèi)部 PID 為 1 的進程發(fā)送 SIGTERM 信號。容器內(nèi) PID 為 1 的進程會有 10s 的優(yōu)雅停止時間來執(zhí)行一些清理操作。如果進程沒有處理該信號，則 10s 后就會被 SIGKILL 信號強制結(jié)束。stop_grace_period 屬性可以調(diào)整默認為 10s 的優(yōu)雅停止時長。

volumes 關(guān)鍵字用于掛載提前創(chuàng)建的卷或者主機目錄到某個服務副本當中。在本例中，會掛載 Docker 主機的 /var/run/docker.sock 目錄到每個服務副本的 /var/run/docker.sock 路徑。這意味著在服務副本中任何對 /var/run/docker.sock 的讀寫操作都會實際指向 Docker 主機的對應目錄中。

/var/run/docker.sock 恰巧是 Docker 提供的 IPC 套接字，Docker daemon 通過該套接字對其他進程暴露其 API 終端。這意味著如果給某個容器訪問該文件的權(quán)限，就是允許該容器接收全部的 API 終端，即等價于給予了容器查詢和管理 Docker daemon 的能力。在大部分場景下這是決不允許的。但是，這是一個實驗室環(huán)境中的示例應用。

該服務需要 Docker 套接字訪問權(quán)限的原因是需要以圖形化方式展示當前 Swarm 中服務。為了實現(xiàn)這個目標，當前服務需要能訪問管理節(jié)點的 Docker daemon。為了確保能訪問管理節(jié)點 Docker daemon，當前服務通過部署約束的方式，強制服務副本只能部署在管理節(jié)點之上，同時將 Docker 套接字綁定掛載到每個服務副本中。綁定掛載如下圖所示。

⒌ payment_gateway 服務

payment_gateway 服務中指定了鏡像，掛載了一個密鑰，連接到網(wǎng)絡，定義了部分部署策略，并且使用了兩個部署約束。

payment_gateway:
image: dockersamples/atseasampleshopapp_payment_gateway
secrets:
- source: staging_token
target: payment_token
networks:
- payment
deploy:
update_config:
failure_action: rollback
placement:
constraints:
- 'node.role == worker'
- 'node.labels.pcidss == yes'

除了部署約束 node.label 之外，其余配置項在前面都已經(jīng)出現(xiàn)過了。通過 docker node update 命令可以自定義節(jié)點標簽，并添加到 Swarm 集群的指定節(jié)點。

因此，node.label 配置只適用于 Swarm 集群中指定的節(jié)點上(不能用于單獨的容器或者不屬于 Swarm 集群的容器之上)。

在本例中，payment_gateway 服務被要求只能運行在符合 PCI DSS(支付卡行業(yè)標準，譯者注)標準的節(jié)點之上。為了使其生效，可以將某個自定義節(jié)點標簽應用到 Swarm 集群中符合要求的節(jié)點之上。示例中在搭建應用部署實驗環(huán)境的時候完成了該操作。

因為當前服務定義了兩個部署約束，所以服務副本只會部署在兩個約束條件均滿足的節(jié)點之上，即具備 pcidss=yes 節(jié)點標簽的 worker 節(jié)點。

關(guān)于 Stack 文件的分析到這里就結(jié)束了，目前對于應用需求應該有了較好的理解。前文中提到，Stack 文件是應用文檔化的重要部分之一。已經(jīng)了解該應用包含 5 個服務、3 個網(wǎng)絡以及 4 個密鑰。此外還知道了每個服務都會連接到哪個網(wǎng)絡、有哪些端口需要發(fā)布、應用會使用到哪些鏡像以及哪些服務需要在特定的節(jié)點上發(fā)布。