Docker Stack配置文件詳解

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

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

網(wǎng)絡(luò)

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

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

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

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

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

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

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

密鑰

密鑰屬于頂級(jí)對(duì)象，在當(dāng)前 Stack 文件中定義了 4 個(gè)。

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

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

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

服務(wù)

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

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

⒈ reverse_proxy 服務(wù)

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

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)鍵字是服務(wù)對(duì)象中唯一的必填項(xiàng)。顧名思義，該關(guān)鍵字定義了將要用于構(gòu)建服務(wù)副本的 Docker 鏡像。

Docker 是可選項(xiàng)，除非指定其他值，否則鏡像會(huì)從 Docker Hub 拉取。可以通過(guò)在鏡像前添加對(duì)應(yīng)第三方鏡像倉(cāng)庫(kù)服務(wù) API 的 DNS 名稱的方式，來(lái)指定某個(gè)鏡像從第三方服務(wù)拉取。例如 Google 的容器服務(wù)的 DNS 名稱為 gcr.io。

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

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

? 80:80 將 Swarm 節(jié)點(diǎn)的 80 端口映射到每個(gè)服務(wù)副本的 80 端口。

? 443:443 將 Swarm 節(jié)點(diǎn)的 443 端口映射到每個(gè)服務(wù)副本的 443 端口。

默認(rèn)情況下，所有端口映射都采用 Ingress 模式。這意味著 Swarm 集群中每個(gè)節(jié)點(diǎn)的對(duì)應(yīng)端口都會(huì)映射并且是可訪問(wèn)的，即使是那些沒有運(yùn)行副本的節(jié)點(diǎn)。

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

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

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

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

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

本服務(wù)密鑰中定義的內(nèi)容會(huì)在每個(gè)服務(wù)副本中被掛載，具體路徑為 /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)鍵字確保服務(wù)所有副本都會(huì)連接到 front-tier 網(wǎng)絡(luò)。網(wǎng)絡(luò)相關(guān)定義必須位于頂級(jí)關(guān)鍵字 networks 之下，如果定義的網(wǎng)絡(luò)不存在，Docker 會(huì)以 Overlay 網(wǎng)絡(luò)方式新建一個(gè)網(wǎng)絡(luò)。

⒉ database 服務(wù)

數(shù)據(jù)庫(kù)服務(wù)也在 Stack 文件中定義了，包括鏡像、網(wǎng)絡(luò)以及密鑰。除上述內(nèi)容之外，數(shù)據(jù)庫(kù)服務(wù)還引入了環(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)鍵字允許在服務(wù)副本中注入環(huán)境變量。在該服務(wù)中，使用了 3 個(gè)環(huán)境變量來(lái)定義數(shù)據(jù)庫(kù)用戶、數(shù)據(jù)庫(kù)密碼的位置(掛載到每個(gè)服務(wù)副本中的密鑰)以及數(shù)據(jù)庫(kù)服務(wù)的名稱。

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

將三者作為密鑰傳遞會(huì)更安全，因?yàn)檫@樣可以避免將數(shù)據(jù)庫(kù)名稱和數(shù)據(jù)庫(kù)用戶以明文變量的方式記錄在文件當(dāng)中。

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

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

部署約束是一種拓?fù)涓兄〞r(shí)任務(wù)，是一種很好的優(yōu)化調(diào)度選擇的方式。Swarm 目前允許通過(guò)如下幾種方式進(jìn)行調(diào)度。

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

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

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

? 節(jié)點(diǎn)引擎標(biāo)簽，如 engine.labels.operatingsystem==ubuntu16.04。

? 節(jié)點(diǎn)自定義標(biāo)簽，如 node.labels.zone==prod1。

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

⒊ appserver 服務(wù)

appserver使用了一個(gè)鏡像，連接到 3 個(gè)網(wǎng)絡(luò)，并且掛載了一個(gè)密鑰。此外 appserver 服務(wù)還在 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

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

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

services.appserver.deploy.update_config 定義了 Docker 在服務(wù)滾動(dòng)升級(jí)的時(shí)候具體如何操作。對(duì)于當(dāng)前服務(wù)，Docker 每次會(huì)更新兩個(gè)副本(parallelism)，并且在升級(jí)失敗后自動(dòng)回滾。

回滾會(huì)基于之前的服務(wù)定義啟動(dòng)新的副本。failure_action 的默認(rèn)操作是 pause，會(huì)在服務(wù)升級(jí)失敗后阻止其他副本的升級(jí)。failure_action 還支持 continue。

update_config:
parallelism: 2
failure_action: rollback

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

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

⒋ visualizer 服務(wù)

visualizer 服務(wù)中指定了鏡像，定義了端口映射規(guī)則、更新配置以及部署約束。此外還掛載了一個(gè)指定卷，并且定義了容器的優(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'

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

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

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

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

⒌ payment_gateway 服務(wù)

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

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 之外，其余配置項(xiàng)在前面都已經(jīng)出現(xiàn)過(guò)了。通過(guò) docker node update 命令可以自定義節(jié)點(diǎn)標(biāo)簽，并添加到 Swarm 集群的指定節(jié)點(diǎn)。

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

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

因?yàn)楫?dāng)前服務(wù)定義了兩個(gè)部署約束，所以服務(wù)副本只會(huì)部署在兩個(gè)約束條件均滿足的節(jié)點(diǎn)之上，即具備 pcidss=yes 節(jié)點(diǎn)標(biāo)簽的 worker 節(jié)點(diǎn)。

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