AboutDockerProfessional illustrations
Docker Service Create 基礎教學
好，各位想玩轉 Docker Swarm 嘅朋友，今次我哋就深入淺出講下 Docker Service Create 嘅基礎教學。呢個指令係你進入 容器編排 世界嘅鎖匙，唔單止係起個 Container 咁簡單，而係教識個 orchestrator（即係 Swarm mode 下嘅 Docker Engine）點樣去管理你嘅服務。首先你要明，Swarm mode 下嘅基本單位係 Service（服務），而唔係單一容器。一個 Service 係你定義理想中應用程式應該點樣運行嘅藍圖，例如要用咩映像、開幾多個副本、點樣配置網絡同儲存等等。當你喺 manager node 度落 docker service create 指令，Swarm 就會根據你嘅藍圖，生成指定數量嘅 Task（任務），每個 Task 最終就會喺 worker nodes 上面啟動一個容器。呢個就係 cluster management 嘅核心概念。
咁實際點樣落指令呢？最基本嘅指令格式係「docker service create --name 我嘅服務名 映像名」。例如「docker service create --name web_server nginx:alpine」，咁 Swarm 就會幫你開一個叫 web_server 嘅服務，用最新嘅 nginx alpine 映像，預設會開一個副本（replica）。但係咁樣太基本啦，實戰一定要加參數。首先係設定副本數量，用「--replicas 3」就可以指定要同時運行三個一樣嘅容器實例，Swarm 會自動幫你喺集羣內唔同節點度分配，呢個就係 服務部署 同 scale（擴展）嘅起點。如果你想做 滾動更新（rolling update），呢個 replicas 設定就好關鍵。
跟住到 網絡配置。預設情況下，新創建嘅服務會連接到一個叫「ingress」嘅 overlay network，呢種網絡跨越成個 Swarm 集羣，等唔同節點上嘅服務容器可以互相通訊。如果你想隔離服務，可以自己創建一個 overlay network，然後用「--network 我嘅網絡名」將服務接入去。至於點樣俾外界訪問，就要用到 port publishing，參數係「--publish published=8080,target=80」。咁樣代表將集羣每個節點嘅 8080 端口，映射到服務容器內部嘅 80 端口。當有請求去到任何一個節點嘅 8080，Swarm 嘅內置負載均衡器就會將請求轉發去其中一個健康嘅容器實例，對外提供服務就係咁簡單。
服務配置 仲包括點樣處理儲存同數據。Docker Service 支援幾種 掛載卷 方式，包括 volume（由 Docker 管理嘅持久化儲存）、bind mount（將主機特定目錄掛載入容器）、同 tmpfs（只存在於記憶體嘅暫存空間）。例如你想保持網站數據，可以用「--mount type=volume,source=my_volume,target=/app/data」。呢啲配置對於數據庫或者有狀態應用好重要。另外，傳遞環境變數俾容器都好常用，用「--env MYSQL_ROOT_PASSWORD=secret」就可以設定，方便你唔使改 Dockerfile 就調整應用行為。
進階啲嘅 服務配置 仲可以設定資源限制同擺放約束。你想唔想某個服務只用特定數量嘅 CPU 同記憶體？可以用「--limit-cpu 0.5 --limit-memory 512M」來限制，避免某個服務食盡成個節點資源。Placement constraints（擺放約束）就更加強大，例如你可以用「--constraint node.labels.region==hk」來指定個服務只可以運行喺標籤咗 region=hk 嘅節點上面。呢個 Label 同 Template Variable 系統好有用，你可以事先幫集羣嘅節點打標籤（例如 disk=ssd, env=prod），然後部署服務時就可以精準控制佢哋運行喺邊類硬件或環境，對於 集羣管理 同優化資源運用好有幫助。
最後提提大家，docker service create 有好多參數可以同 滾動更新 策略配合。例如你可以設定「--update-delay 10s」同「--update-parallelism 2」，咁樣當你之後更新服務映像版本時，Swarm 就會每次更新兩個副本，每個之間等十秒，確保服務唔會中斷。仲有 健康檢查 配置，可以用「--health-cmd」等參數設定，等 Swarm 知道點樣判斷你個容器係咪健康，如果唔健康就自動重啟任務，確保服務高可用性。總括來講，Docker Service Create 呢個指令係你定義一切嘅開始，由簡單嘅 alpine 測試容器到複雜多層應用，都要靠佢將你嘅配置變成 Swarm 識管理嘅 Service。記住，所有設定之後都可以用「docker service update」指令來修改，實現動態嘅 服務更新 同 服務擴展，呢個就係現代化 容器編排 嘅威力。
AboutSwarmProfessional illustrations
2026年最新指令參數詳解
講到2026年最新嘅 docker service create 指令參數詳解，我哋首先要明白，喺呢幾年 Docker Swarm 作為一個輕量級嘅 容器編排 工具，雖然面對住其他 orchestrator 嘅競爭，但佢嘅 Swarm mode 依然係好多團隊做 cluster management 嘅簡單好選擇。Docker Engine 持續更新，令到 Docker CLI 入面嘅 Docker Service 指令參數更加強大同埋精細，唔再係淨係識得開個 Container 咁簡單。今次我就同大家深入拆解下，點樣用最新嘅參數去設定一個服務，由基本部署到進階管理，一次過講清楚。
首先，最基本嘅指令結構大家都知，就係 docker service create 跟住個 image 名，例如 alpine。但係，2026年嘅玩法，重點已經放咗喺 服務配置 嘅細緻度上。例如，你想控制個服務有幾多個副本，就一定要識用 --replicas 呢個參數。呢個就係設定 replica 數量嘅核心，直接決定咗你個服務有幾多個相同嘅 Task（任務）同時喺 worker nodes 上面行緊。Swarm 嘅 manager node 就會負責呢啲 任務管理，確保數量一直保持住你設定嘅狀態。呢個就係 服務擴展 嘅基礎，你想 scale 個服務上落，就係靠調節呢個 replicas 數值，好直接。
跟住落嚟，網絡同儲存呢兩大塊係 服務部署 嘅重中之重。網絡配置 方面，--network 參數指定個服務要用邊個 overlay network，確保唔同服務之間可以安全通訊。而家仲可以好方便咁設定內部服務發現。至於 掛載卷，2026年嘅選擇依然係三大類：--mount type=volume 用嚟掛載持久化嘅 volume；--mount type=bind 用嚟做 bind mount，將宿主機嘅目錄直接掛入去；同埋 --mount type=tmpfs 用嚟掛載記憶體檔案系統，適合放啲敏感或者臨時數據。設定嘅時候記住要寫清楚 source 同 target，咁先唔會出錯。
資源限制同埋擺放策略，就係確保 集羣管理 穩定嘅關鍵。--limit-cpu 同 --limit-memory 呢兩個參數，用嚟設定每個 Container 實例最多可以用幾多資源，防止某個服務食晒成個 node 嘅資源。而 placement constraints（擺放約束）就更加犀利，你可以用 --constraint 參數，指定個服務嘅 Task 必須運行喺有特定 Label 嘅節點上面。例如，你喺某啲 worker nodes 打咗 disk=ssd 嘅 label，咁你就可以設定約束，將需要高速 I/O 嘅服務只部署喺呢啲節點，資源分配就更加精準。
仲有啲進階參數，對於實現自動化同埋高可用性好重要。例如 環境變數，可以用 --env 直接設定，或者用 --env-file 讀取成個檔案。健康檢查 參數 --health-cmd、--health-interval 等，就係等 Docker Engine 定期檢查個容器係咪仲健康，唔健康嘅話就會自動重啟或者重新調度個 Task，呢個對於維持服務持續可用係不可或缺嘅。另外，port publishing 用 --publish 參數，格式愈嚟愈靈活，可以指定將服務嘅端口映射到宿主機嘅特定端口，甚至指定協議（TCP/UDP）。
最後不得不提 滾動更新 策略，呢個係 服務更新 時唔可以停機嘅法寶。--update-delay、--update-parallelism、--update-failure-action 等參數，讓你可以精確控制點樣分批、有延遲地更新容器實例。例如，你可以設定每次只更新一個副本，等佢健康檢查通過後，隔10秒先更新下一個，咁樣就可以做到零停機時間嘅 rolling update。另外，--restart-condition、--restart-delay 等參數，就控制住當任務失敗時，Swarm 應該點樣嘗試重啟佢。
總括嚟講，2026年嘅 docker service create 指令，已經係一個集 服務配置、資源管理、網絡規劃、儲存掛載、健康監控同滾動更新於一身嘅強大工具。要玩得轉 Docker Swarm 呢個 容器編排 系統，就一定要熟練掌握呢一大堆參數，根據你實際嘅應用場景，好似係需要幾多個 replicas、要用咩類型嘅 volume、有冇特別嘅 placement constraints、點樣設定 resource limits 等等，去組合出最適合嘅指令。咁樣先可以確保你部署嘅服務係穩定、高效同埋容易管理嘅。
AboutmanagerProfessional illustrations
設定服務副本數量技巧
講到喺 Docker Swarm 入面設定服務副本數量技巧，呢個真係容器編排嘅核心操作，直接影響到你個服務嘅可用性同埋效能。好多朋友一開始用 Docker service create 指令時，可能淨係識得用 --replicas 參數指定一個固定數量，例如 --replicas 3，但其實喺實際嘅集羣管理入面，有好多進階技巧同埋考慮因素，可以令你嘅服務部署更加靈活同穩陣。
首先，你要清楚理解幾個關鍵概念：當你喺 Swarm mode 下用 Docker CLI 建立一個 Docker Service，你其實係向 manager node 下達指令。個 manager node 作為orchestrator，就會根據你指定嘅副本數量（replicas），去創建相應數量嘅 Task。每個 Task 就係一個指令，最終會喺 worker nodes 上面啟動一個 Container。所以，設定副本數量唔單止係一個數字遊戲，仲要考慮到任務管理同埋資源分配。例如，你個集羣有5個 worker nodes，但你設定 --replicas 10，咁 Docker Engine 就會嘗試喺每個 node 上面平均分配，可能每個 node 跑2個 container，達到你要求嘅規模。
一個好實用嘅技巧，就係點樣配合滾動更新（rolling update）嚟設定副本數。假設你有一個運行緊嘅服務，有5個副本。當你需要更新映像版本時，如果你就咁更新，可能會令服務能力短暫下降。聰明嘅做法係，你可以喺更新指令入面，透過 --update-parallelism 同埋 --update-delay 等參數，控制每次更新幾個副本，同埋隔幾耐先更新下一批。咁樣，Swarm 就會確保喺更新過程中，始終有足夠數量嘅舊版本副本維持服務，新版本副本逐個逐個上線，做到無縫服務更新。呢個過程入面，你設定嘅總副本數量就係一個基準，orchestrator 會確保任何時候都唔會少過呢個數（除非更新失敗要 rollback）。
另一個必須要識嘅技巧，就係點樣根據資源同埋條件，去動態調整副本嘅分佈，即係所謂嘅placement constraints。淨係識得設定 --replicas 5 係唔夠嘅，如果5個副本全部被調度去同一個 worker node，咁萬一嗰個 node 死機，成個服務就癱瘓啦。所以，你可以透過 --constraint 參數，利用 Label 去控制副本應該喺邊啲 node 上面運行。例如，你可以喺某啲性能強勁嘅 node 上面打上 label=high_performance，然後喺建立服務時指定 --constraint node.labels.high_performance==true。咁樣，你就可以精準控制副本運行喺指定嘅硬件上，對於需要大量運算嘅服務特別有用。同時，你亦可以配合 --reserve-memory 或 --reserve-cpu 呢類 resource limits 參數，確保每個 container 都有足夠資源，避免因為資源爭奪而影響表現。
仲有，設定副本數量唔係一次過嘅事，要識得服務擴展（scale）。喺 Swarm 入面，你可以隨時用 docker service scale
最後，分享一個進階但好實用嘅場景：點樣確保副本數量喺各種故障下都能維持。除咗上面講到嘅placement constraints，你可以善用 Docker Engine 嘅健康檢查功能。喺建立服務時，透過 --health-cmd 等參數定義點樣先算一個健康嘅 container。當 Swarm 偵測到某個副本嘅 container 健康檢查失敗，佢就會自動喺其他 node 上面啟動一個新嘅副本去替代，直到滿足你設定嘅 --replicas 數量為止。呢個就係真正嘅高可用性設定。另外，如果你嘅服務需要存取持久數據，就要諗埋掛載卷（volume）或者 bind mount 嘅問題。如果你簡單用 --replicas 3 但係用咗本地volume，咁三個副本嘅數據就可能唔同步。正確做法係配合 overlay network 同埋共享嘅儲存方案（例如 NFS volume 或者雲端儲存），確保每個副本存取到嘅數據都係一致嘅。
總而言之，設定服務副本數量，遠唔止一個數字咁簡單。你要綜合考慮滾動更新策略、資源限制（resource limits）、節點標籤（Label）、健康檢查機制，同埋數據儲存方式（volume, bind mount, tmpfs）。例如，你可以構建一個服務，用 --replicas 4，加上placement constraints確保分散喺唔同嘅機櫃，設定resource limits防止食盡資源，再配置好健康檢查同共享 volume。咁樣，無論係日常運作、服務更新定係遇到 node 故障，你嘅服務都能夠保持穩定同高性能。記住，所有呢啲設定，都可以喺一條 docker service create 指令裡面，或者後續嘅 docker service update 指令裡面完成，Docker Swarm 嘅容器編排能力就係咁強大同埋細緻。
AboutserviceProfessional illustrations
安全整合Secret管理
好，講到喺 Docker Swarm 入面部署服務，安全整合 Secret 管理真係一個重中之重嘅環節。喺 2026 年嘅今日，無論你係用緊最新版嘅 Docker Engine 定係其他容器編排工具，對於敏感資料嘅處理都絕對唔可以馬虎。喺 Swarm mode 之下，Docker 提供嘅 Secret 管理功能，就係專為呢個安全問題而設。同以往就咁用 environment variables 或者寫死喺 Dockerfile 入面完全唔同，Secret 係一套由 Swarm 本身管理嘅安全機制。
簡單嚟講，當你用 Docker CLI 嘅 docker service create 指令去部署一個服務時，你可以將密碼、API金鑰、TLS證書呢啲敏感資料，以 Secret 嘅形式掛載入去個 Container 裏面。呢個過程點解安全呢？第一，Secret 只會喺 manager node 同需要用到佢嘅 worker nodes 之間以加密形式傳輸同儲存。第二，Secret 係儲存喺 Swarm 自己個 overlay network 同埋 Raft 數據庫裏面，唔會好似普通檔案咁容易暴露。第三，喺 Container 裏面，Secret 係以臨時檔案系統（類似 tmpfs）嘅形式掛載，即係話佢只會存在喺記憶體，唔會寫入容器嘅可寫層，亦唔會留低喺磁碟度，就算你用 bind mount 或者持久化 volume 都唔會影響到 Secret 嘅安全性。
咁實際點用呢？假設我哋要部署一個需要連資料庫嘅應用。以前啲人可能貪方便，直接將個資料庫密碼設做環境變數，例如 -e DB_PASSWORD=mysecretpass，但咁樣喺服務列表或者日誌度好容易會睇到。而家正確做法係，首先用 docker secret create 指令，將個密碼建立成一個 Secret 物件喺 Swarm 入面。跟住，當你進行 服務部署 時，喺 docker service create 指令度加入 --secret 參數。例如，你個 Secret 名叫 db_password，你就可以咁樣掛載佢入去服務嘅 Task 度。個 Secret 檔案預設會出現喺容器內嘅 /run/secrets/db_password 呢個路徑，你嘅應用程式就直接去讀呢個檔案拎密碼，而唔係從環境變數拎。
呢種方法對於 滾動更新 同 服務配置 管理特別有利。當你需要更新個密碼時，你唔使重新 build 過個 image，亦唔使將新密碼周圍傳。你只需要喺 Swarm manager node 度建立一個新版本嘅 Secret（例如叫 db_password_v2），然後用 docker service update 指令，將服務嘅 Secret 來源指向新嘅一個，再進行一次 rolling update，Swarm orchestrator 就會逐個 Task 咁更新，新嘅容器就會讀取新密碼，而舊嘅 Secret 可以喺確保所有服務都更新完之後先至刪除，過程平滑又安全。
另外，進階一啲嘅用法仲可以配合 Label 同 Template Variable 嚟增加靈活性。例如，你可以為唔同嘅環境（開發、測試、生產）設定唔同嘅 Secret，然後透過服務嘅 placement constraints 或者標籤，去決定邊個服務用邊一組 Secret。又或者，你可以利用模板變數，將 Secret 嘅名稱動態化，令到同一個服務 stack 檔可以更容易咁適應唔同部署環境。
最後都要提一提，Secret 管理雖然安全，但都要配合良好嘅 集羣管理 習慣。例如，一定要確保你嘅 manager node 有足夠嘅保安，因為 Secret 嘅加密金鑰係由 manager 管理。另外，雖然 Secret 喺磁碟上係加密，但都要定期審查邊個服務有權限存取邊個 Secret，避免 Secret 被過度授權。總括嚟講，將 Secret 管理整合到 docker service create 同日常嘅 服務更新 流程入面，係現代 容器編排 不可或缺嘅一環，唔單止令你嘅應用更安全，亦令成個部署同 scale 嘅過程更加專業同可靠。
AboutContainerProfessional illustrations
Config配置實戰應用
好啦，講完基本概念，我哋直接跳入去 Config配置實戰應用 嘅環節。呢個部份係真正將 Docker Swarm 嘅威力發揮出嚟嘅關鍵，唔單止係打句 docker service create 咁簡單，而係要識得點樣透過一堆配置選項，去精準控制你個服務點樣喺集羣管理 入面運行。好多師兄一開始可能只係識得指定 image 同 replicas 數量，但其實 Docker Service 嘅配置選項多到呢，可以話係一個完整嘅 容器編排 藍圖。
首先，我哋由最核心嘅服務定義講起。當你用 Docker CLI 去建立一個服務嘅時候，你其實係向個 manager node 發出指令，然後個 orchestrator 就會根據你嘅配置，去 worker nodes 度分派任務。最基本嘅，梗係要設定個服務有幾多個 replica 啦。例如 --replicas 5 就係話要同時運行五個一樣嘅容器。但係，如果你唔想用固定數量，而係想根據節點資源自動調節，咁你就可以用 --mode global，佢會喺每個符合條件嘅 worker nodes 上面都運行一個任務，對於要收集日誌或者監控嘅 agent 嚟講就非常好用。
跟住落嚟，網絡配置 係另一個重中之重。喺 Swarm mode 底下，預設會自動幫你創建一個 overlay network，等唔同節點上面嘅 Container 可以互相通訊。你可以用 --network my-overlay-net 去指定個服務接入邊個網絡。如果你想將服務嘅端口公開俾外界訪問，就要用到 port publishing，例如 --publish published=8080,target=80，咁樣就會將集羣內任何節點嘅 8080 端口，映射到服務容器內部嘅 80 端口。Swarm 嘅內置負載均衡器會自動將流量分派去唔同嘅 Task，呢個就係服務部署 嘅精髓。
講到儲存，即係 掛載卷，Swarm 都提供咗幾種方式。最簡單係 --mount type=volume,source=mydata,target=/app/data，用一個共享嘅 volume。如果你要掛載主機嘅特定目錄，就要用 bind mount，例如 --mount type=bind,source=/host/path,target=/container/path。不過要留意，bind mount 係跟死咗某部主機嘅路徑，對於需要流動性嘅任務管理 未必係最好選擇。至於一啲只需要暫存數據嘅情況，可以考慮用 type=tmpfs，將資料放喺記憶體，又快又唔會留低痕跡。
資源限制同 健康檢查 係確保服務穩定嘅守護神。你可以用 --limit-cpu 同 --limit-memory 去防止某個容器食晒成部機嘅資源，影響其他服務。而 --health-cmd 同 --health-interval 就係設定點樣檢查個容器係咪健康運作緊，如果檢查失敗，Swarm 嘅 orchestrator 會自動殺死個唔健康嘅容器，然後重新啟動一個新嘅，呢個過程對於實現 滾動更新 同服務高可用性好重要。
進階啲嘅配置，就一定要提 Placement constraints 同 Label。呢個功能超強大，可以讓你精準控制個服務嘅 Task 運行喺邊啲節點上面。例如，你嘅 worker nodes 有啲係 GPU 伺服器，有啲係普通嘅，你就可以喺 GPU 節點上面打個 Label，例如 docker node update --label-add gpu=true node-1。然後喺建立服務嘅時候，就可以指定 --constraint node.labels.gpu==true，咁樣個服務就只會喺有 GPU 嘅節點上面運行。同樣道理，你可以根據節點主機名、引擎版本等等去約束，對於複雜嘅 集羣管理 環境係必不可少。
最後，環境變數同配置注入都係實戰常用。你可以用 --env VAR=value 直接設定，又或者用 --env-file 讀取一個檔案。但係對於一啲敏感資料，好似密碼咁，就強烈建議用 Docker 嘅 secret 功能，而唔好直接寫死喺命令或者 image 入面。至於點樣將配置檔案掛入容器，你可以用 config 物件，事先將一個配置文件存入 Swarm，然後服務建立時用 --config source=my_config,target=/app/config.yaml 掛入去，咁樣就可以好方便咁做 服務更新，改咗 config 之後，更新服務就會自動將新配置滾動式部署到所有容器。
總而言之，docker service create 呢個命令嘅配置選項，就係你將一個簡單容器，變成一個具備彈性、高可用、易於管理嘅 雲原生服務 嘅魔法陣。由決定服務規模、網絡點樣連、數據點樣存、資源點樣分、到個容器要放喺邊部機運行，全部都可以透過參數定義好。熟練掌握呢啲配置，你先算係真正玩得轉 Docker Swarm 呢套 容器編排 系統，能夠自信地處理 服務擴展、滾動更新 同日常嘅 服務配置 工作。記住，實戰唔係死記硬背命令，而係理解每個選項背後解決緊咩問題，然後按自己個 集羣管理 嘅實際需要去組合運用。
AboutTaskProfessional illustrations
滾動更新策略設定
講到喺 Docker Swarm 入面做滾動更新，其實就係確保你嘅服務可以無縫升級，唔會因為更新而令服務停擺，對用戶零影響。呢個功能對於要維持高可用性嘅線上服務嚟講，真係救星嚟。當你用 Docker CLI 嘅 docker service create 或者 docker service update 指令時，就可以透過一堆參數去精細控制個滾動更新點樣進行。最基本嘅概念就係，Swarm 嘅 orchestrator 會逐個逐個Task（即係容器）去更新，等新版本嘅 Container 啟動好同通過健康檢查之後，先至將舊嘅容器停掉，一路慢慢滾動過去，直到成個 service 所有replica都更新完為止。
咁點樣設定呢？主要係靠幾個核心參數。首先係 --update-delay，呢個設定控制緊每個Task更新之間要隔幾耐。例如你 set --update-delay 30s，咁 Docker Engine 就會完成一個容器更新後，等30秒先至開始更新下一個。呢個 delay 好有用，尤其係你個應用程式需要時間 warm up 或者連接數據庫，俾多少少緩衝時間可以避免成個集羣管理一下子負荷過重。跟住係 --update-parallelism，默認係1，意思係一次只更新一個副本。如果你好有信心，想快啲，可以 set 做2或者更多，咁 manager node 就會同時更新多個 Container，但就要小心資源夠唔夠同服務頂唔頂得順。仲有 --update-failure-action，可以設定如果更新失敗咗要點做，係 pause 咗個更新過程等你排查，定係自動 rollback 返去上一個版本，呢個對於自動化服務部署好關鍵。
舉個實際例子啦，假設我哋有個用 alpine 做基礎鏡像嘅 web 服務，行緊5個 replicas。我想更新到新版本嘅鏡像，同時想設定一個穩陣嘅滾動更新策略。我哋可以用類似呢個指令去更新個服務：docker service update --image myapp:2026-v2 --update-delay 20s --update-parallelism 1 --update-monitor 30s my_web_service。呢度我 set 咗每次更新隔20秒，一次只更新一個副本，而且每個新 Task 啟動後，會監察30秒睇下佢健唔健康，如果呢段時間內個容器冇崩潰，先算更新成功，然後先至繼續下一個。咁樣就算新版本有暗病，都只會影響緊一個副本，其他四個仲係行緊舊穩定版，成個服務依然運作到。
另外，滾動更新同你點樣配置個服務係息息相關嘅。例如，如果你個服務用緊 overlay network 做跨主機通訊，或者用緊 volume、bind mount 嚟持久化數據，更新時都要確保新版本嘅容器能夠順利連接返同一個網絡同儲存。又或者，如果你用 Label 同 placement constraints 將某啲 Task 固定喺特定嘅 worker nodes 上行，更新時 orchestrator 都會尊重返呢啲設定，喺符合條件嘅節點上啟動新容器。仲有 resource limits 同 environment variables，呢啲設定都會喺更新過程中被繼承或者按新指令更新，所以喺規劃服務配置時，就要一併考慮埋更新策略。
最後都要提下健康檢查喺滾動更新入面嘅角色，佢真係把關大將軍。如果你喺 Dockerfile 或者服務設定入面定義咗 HEALTHCHECK，Swarm mode 就會靠佢嚟判斷一個新啟動嘅容器係咪 ready。配合 --update-monitor 參數，就可以確保新容器唔只係啟動咗，仲要係真正健康先算數。如果健康檢查失敗，根據你設定嘅 --update-failure-action，個更新過程就會暫停或者回滾，防止有問題嘅版本擴散到成個集羣。所以話，設定一個準確反映你應用程式狀態嘅健康檢查，係實現安全滾動更新不可或缺嘅一環。
總括嚟講，設定滾動更新策略唔係求其 set 兩下就算，要根據你應用程式嘅特性、集羣嘅規模同業務嘅要求，去微調 --update-delay、--update-parallelism 呢啲參數。目標係喺更新速度同服務穩定性之間取得平衡。好好利用 Docker Service 提供嘅呢啲容器編排工具，就可以好優雅咁管理你嘅服務生命週期，做到真正嘅無停機部署，對於維護現代化、高可用嘅系統嚟講，係一個必須要掌握嘅技能。
AboutDockerProfessional illustrations
環境變數最佳實踐
講到用 Docker Service Create 部署服務，點樣設定環境變數（Environment Variables）先至係最佳實踐？呢個問題好多 DevOps 同 SRE 都會遇到，尤其係當你用緊 Swarm mode 做容器編排嘅時候。環境變數唔單止係傳遞配置咁簡單，佢直接影響到你個服務嘅安全性、可維護性同埋跨環境嘅一致性。喺 Docker Swarm 嘅環境入面，你係透過 Docker CLI 向 manager node 發出指令，然後個 orchestrator 就會將任務（Task）分配到唔同嘅 worker nodes 上執行。如果你將敏感資料，例如數據庫密碼或者 API Key，直接寫死喺 docker service create 嘅指令入面，咁就大鑊啦！因為呢啲指令好可能會留喺 Shell 嘅歷史記錄度，或者被其他人睇到，造成安全漏洞。
所以，第一個最佳實踐就係：千祈唔好將敏感嘅環境變數明文寫喺指令或者 Dockerfile 入面。咁應該點做呢？Docker 同 Swarm 有提供更好嘅方法。你可以用 --env 參數去傳遞普通變數，但對於敏感資料，強烈建議使用 Docker Secret。雖然我哋呢段集中講環境變數，但都要提一提，Secret 會喺 Swarm 嘅 overlay network 入面被安全地傳遞同管理，佢會以加密嘅形式存在，並且只會喺需要嘅時候掛載到服務嘅容器（Container）內部，通常係一個檔案。對於非敏感但需要因環境而異嘅配置，例如 LOG_LEVEL=DEBUG 或者 APP_ENV=staging，用環境變數就非常適合。你可以好似咁樣部署一個服務：用 docker service create --name my_app --replicas 3 --env LOG_LEVEL=INFO --env APP_ENV=production alpine:latest。咁樣，每一個由 Task 啟動嘅容器，都會有齊呢兩個環境變數。
第二個實踐係關於點樣有系統地管理大量環境變數。當你個服務有十幾廿個環境變數要設定，仲要喺唔同環境（開發、測試、生產）用唔同嘅值，仲要喺 Swarm 入面做滾動更新（rolling update），咁點算好？將成串 --env VAR1=value1 --env VAR2=value2 ... 寫喺指令度係非常之唔現實同難維護嘅。更好嘅做法係用 --env-file 參數。你可以事先準備好一個 .env 檔案，入面一行行咁定義好所有環境變數，然後喺建立服務嘅時候引用佢。例如，你有一個叫 prod.env 嘅檔案，入面定義咗 DB_HOST、CACHE_URL 等等。咁你嘅指令就會變成 docker service create --name api_service --env-file prod.env --replicas 5 my_image:tag。咁樣做嘅好處係，你可以將呢個 .env 檔案用版本控制工具（例如 Git）管理起嚟，針對唔同嘅環境分支（branch）有唔同嘅版本，部署嘅時候就清晰同安全好多。而且，當你需要更新某個配置值嘅時候，你只需要修改個 .env 檔案，然後用 docker service update --env-file updated_prod.env api_service 嚟進行服務更新，Swarm 嘅 orchestrator 就會幫你執行滾動更新，逐個 Task 咁替換，確保服務唔會中斷。
跟住落嚟要講嘅係點樣善用 Docker Swarm 嘅內置變數同埋 Label。呢個係好多進階用家都會用到嘅技巧，可以令你嘅服務配置更加動態同有彈性。喺 Swarm mode 底下，Docker Engine 提供咗一啲好有用嘅 Template Variable（模板變數）。例如，你可以喺設定環境變數或者掛載卷（volume / bind mount）嘅時候，用到 --env NODE_ID={{.Node.ID}}。咁樣，當個容器喺唔同嘅 worker nodes 上運行時，佢就會自動獲得所喺節點嘅 ID 作為環境變數嘅值。呢個對於需要知曉自己運行位置嘅應用程式好有用。同樣地，你可以用 {{.Service.Name}}、{{.Task.Slot}} 等等。呢啲變數係由 Swarm 嘅 cluster management 系統喺任務創建時實時注入嘅，唔需要你手動設定。另外，結合 Placement Constraints（放置約束）同環境變數，你可以做到更精細嘅控制。例如，你可以喺某啲特定 Label 嘅節點上運行需要特殊配置嘅服務副本（replica），然後透過環境變數將呢個「特殊性」傳遞俾容器。
最後，我哋要討論下環境變數同其他配置方式嘅協同。環境變數雖然方便，但唔係萬能。對於非常複雜嘅配置檔案（例如一個幾百行嘅 JSON 或者 YAML），你唔應該將佢拆散成幾十個環境變數。相反，你可以考慮用 Config 或者 Volume（例如 bind mount 或者 tmpfs）嘅方式，將成個配置檔案掛載入容器。環境變數喺呢度可以扮演一個「開關」或者「指引」嘅角色。例如，你可以設定一個環境變數叫 CONFIG_FILE_PATH=/config/app_settings.yaml，然後你個應用程式啟動時，就讀取呢個變數所指明嘅路徑去拎完整配置。同時，你亦要考慮資源限制（resource limits）同健康檢查（health check）嘅設定，佢哋同環境變數一樣，都係服務配置（service configuration）嘅重要一環，共同確保你嘅服務喺 Swarm 集羣管理下穩定、高效同安全地運行。總而言之，設定環境變數嘅最佳實踐，核心思想就係：安全地管理敏感資料、有系統地組織變數以方便維護、善用編排系統提供嘅動態資訊，以及揀選最合適嘅配置傳遞方式。
AboutSwarmProfessional illustrations
自訂主機名稱設定
好，等我哋深入講下喺 Docker Swarm 入面點樣做「自訂主機名稱設定」。呢個功能其實好實用，尤其當你喺 Swarm mode 用 docker service create 去部署服務嗰陣，預設嘅主機名就係個 Container ID，睇落一嚿嚿數字同字母，對於日常嘅 cluster management 同埋 健康檢查 嚟講，真係好唔方便。咁點樣可以將個主機名改成我哋一眼就睇得明嘅名呢？關鍵就係要用 --hostname 呢個參數。
不過，喺 Swarm 嘅 orchestrator 環境下，直接用 --hostname 其實有啲陷阱。如果你就咁喺 Docker CLI 打 docker service create --hostname my-web alpine，你會發現呢個設定只會喺個別嘅 Task 入面生效，而且效果唔係你諗咁。因為 Swarm 嘅設計理念係「服務」同「任務」嘅抽象，佢會為每個運行中嘅容器實例（即係任務）分配一個獨立嘅主機名，如果你硬性設定一個固定主機名，當你個服務有好多個 replicas（副本）嗰陣，就會撞名，引致網絡或者服務發現上嘅混亂。所以，喺 容器編排 嘅場景，我哋更需要嘅係一個有規律、可以識別到個別任務嘅主機名方案。
咁點算好？其中一個最常用同埋推薦嘅方法，就係利用 Docker Engine 提供嘅 Template Variable（模板變量）嚟動態生成主機名。呢個就勁啦，可以令到每個 Task 都有自己獨一無二但又容易理解嘅主機名。例如，你可以咁樣設定：
當你創建服務嗰陣，喺 --hostname 參數入面加入模板變量。最常用嘅變量就係 {{.Service.Name}}、{{.Task.Slot}} 或者 {{.Node.Hostname}}。舉個實際例子，假如你個服務名叫做 web-api，你可以用 docker service create --name web-api --hostname "{{.Service.Name}}-{{.Task.Slot}}" alpine。咁樣一嚟，第一個任務（slot 1）嘅容器主機名就會係 web-api-1，第二個就係 web-api-2，如此類推。呢種命名方式對於做 服務配置、日誌追蹤同埋 網絡配置 排查都極之有用，你一睇個主機名就知佢係屬於邊個服務、第幾個副本，做 滾動更新 或者 服務擴展 嗰陣就清清楚楚。
除咗用任務槽位（Task Slot），你亦都可以結合 Node 嘅資訊。例如 --hostname "svc-{{.Service.Name}}-on-{{.Node.Hostname}}"。不過要留意，如果節點主機名本身有特殊字符或者太長，可能會引起問題。呢種方式適合喺你需要精確知道個容器運行喺邊部物理機或虛擬機（即係 worker nodes）上嘅時候用，對於資源監控同埋 placement constraints（放置約束）嘅後續分析好有幫助。
另外，有一點好重要嘅提醒：呢個自訂嘅主機名，主要係喺容器內部同埋喺 Swarm 嘅 overlay network 入面先至有效。對於從外部網絡（例如公司內網）嚟訪問嘅客戶端，佢哋通常係透過服務名或者公開嘅 port publishing 埠口嚟連接，而唔係直接靠容器主機名。所以設定主機名，更多係為咗我哋自己管理同埋容器之間嘅通訊方便。
最後，講多一個進階貼士。如果你嘅服務有使用 volume（例如 bind mount 或者 tmpfs）或者複雜嘅 環境變數，配合一個清晰嘅主機名，可以令到日誌文件嘅存放路徑更加有條理。例如，你可以喺應用程式入面，將日誌文件以主機名作為文件名嘅一部分嚟保存，噉樣當你收集同分析日誌嗰陣，就可以好容易咁將日誌同具體嘅容器實例對應返。總括嚟講，喺 Docker Swarm 入面自訂主機名，唔係為咗炫技，而係實實在在提升你個 集羣管理 嘅可觀測性同埋運維效率嘅一個小技巧，記得善用模板變量嚟達到動態同清晰嘅命名效果。
AboutDockerProfessional illustrations
標籤管理與元數據
好啦，講到用 Docker Swarm 部署服務，好多師兄可能覺得 docker service create 最緊要係設定 replicas、掛載 volume 或者配置 overlay network 就算。但係，真正要將成個 cluster management 玩得精，尤其係當你個集羣有成幾十甚至幾百個 worker nodes 嘅時候，標籤管理與元數據呢個功能就絕對係你嘅神兵利器。簡單啲講，Labels 同埋 Docker Service 入面嘅 metadata，就係你貼喺唔同資源（例如 node、service、container）上面嘅「便利貼」，用嚟標明佢嘅身份、用途、或者係一啲特別指示，等個 orchestrator（即係 Swarm 個 manager node）可以更加聰明咁去做 容器編排 同 任務管理。
首先，我哋要分清楚兩種唔同嘅 Label：一種係 Node Labels，另一種係 Service Labels。Node Labels 係你直接貼喺 Swarm 集羣入面每一部主機（node）上面嘅。點樣貼呢？你要登入去 manager node，用 Docker CLI 打指令，例如 docker node update --label-add role=db node-1，咁你就幫 hostname 叫 node-1 嘅呢部機，貼咗一個 key 係 role，value 係 db 嘅 label。咁做有咩用？用途就大啦！之後當你進行 服務部署 或者設定 placement constraints 嘅時候，你就可以指定個服務一定要 run 喺有 role=db 呢個 label 嘅 node 上面。例如你公司有幾部機係用咗 SSD 嘅，你就可以貼個 disk=ssd 嘅 label，然後一啲對 I/O 要求好高嘅 database 服務，就可以用 constraint 限制死只可以喺呢幾部機度行，咁樣對於 服務配置 同資源分配就精準好多。
至於 Service Labels 同埋 Container 嘅 metadata，就係你喺建立服務嗰陣，用 --label 參數直接附加喺個服務定義入面嘅。呢啲 label 唔會影響個服務行去邊部機，但係佢嘅作用更加偏向於管理同協作。例如，你可以為個服務加上 department=finance、project=ledger_system_v2 或者 maintainer=alex_chan 呢類 label。喺 2026 年嘅今日，好多監控工具（例如 Grafana、Prometheus 嘅自動發現功能）或者係第三方 orchestrator 工具，都會識得讀取呢啲 metadata 嚟做自動分組、告警規則設定或者係成本核算。換句話說，你幫服務打嘅 label，就等於俾佢一個清晰嘅「工作證」，無論個 Container 飄去邊個 worker nodes 度行，佢嘅身份同所屬項目都一目了然，對於自動化 集羣管理 嚟講係不可或缺嘅。
另外，一個好實用但又容易被忽略嘅功能，就係點樣利用 metadata 入面嘅 Template Variable 嚟做動態配置。當你用 docker service create 去建立服務時，喺某啲參數位，你可以插入一啲預設嘅 template variable。舉個具體例子，當你設定個服務嘅 container hostname 或者係掛載 volume 嘅時候，你可以咁樣用：--hostname="{{.Service.Name}}.{{.Task.Slot}}"。呢度嘅 {{.Service.Name}} 同 {{.Task.Slot}} 就係 template variable。當 Docker Engine 喺 Swarm mode 下啟動每一個 Task（即係具體嘅容器實例）時，就會自動將呢個模板替換成真實值。例如你個服務名叫 web_api，咁第一個 replica 嘅 container hostname 就會係 web_api.1，第二個就係 web_api.2，如此類推。呢個方法對於統一命名規範、或者係當你個應用程式需要知道自己嘅實例編號去做一啲內部協調嘅時候，就非常之方便，唔使下下要靠寫死嘅 environment variables。
最後，我哋要講下點樣將 Labels 同日常維運嘅 服務更新、健康檢查 同 服務擴展 結合埋一齊。假設你為一組背景處理任務嘅服務打咗個 label 叫 tier=background。當你需要做 滾動更新 嘅時候，你可以好靈活咁用 label selector 嚟做分批更新。雖然 Docker CLI 本身無直接嘅指令係按 label 來更新，但你可以透過將有相同 label 嘅服務，用相同嘅 Docker Service 配置模板去重新部署，或者用一啲外部編排腳本來實現。再者，當你設定 健康檢查 指令時，你可以因應唔同 label 所代表嘅角色（例如 role=api 同 role=cache），去設定唔同嘅檢查間隔同超時時間，令到監控更加貼身。至於 scale（擴展），雖然直接係按服務名去做，但當你配合埋 placement constraints 同 node label 一齊用，你就可以做到「將帶有 type=stateful label 嘅服務，擴展到所有帶有 region=hk-east-1 label 嘅節點上」呢類非常精細嘅調度策略。
總括嚟講，喺 Swarm 嘅世界入面，標籤同元數據絕對唔係啲「得個擺字」嘅裝飾。佢係一套輕量但極之強大嘅分類同描述系統，將你成個集羣嘅資源（node）同服務（service）有條理地管理起嚟。由最簡單嘅資源分配（constraints），到進階嘅動態配置（template variables），再到同外部生態系統嘅整合（監控、告警），都離唔開佢。所以，下次你打 docker service create 嗰陣，除咗諗住 --replicas 5、--publish 80:80 或者係用 --mount type=bind 去設定 bind mount，不妨停多一秒，諗下可以加啲咩 Label 落去，咁樣你成個 容器編排 嘅策略即刻會變得更加有彈性同埋專業。
AboutServiceProfessional illustrations
儲存掛載全面指南
好喇，而家我哋就深入講下喺 Docker Swarm 模式入面，點樣處理儲存掛載呢個重要課題。喺 Swarm 呢個分散式嘅 容器編排 環境度，service 嘅 Task 可能會被個 orchestrator 調度去任何一個 worker nodes 度運行，呢個時候，點樣確保每個 Container 都有穩定、一致嘅數據存取，就係一大挑戰。同單機玩 Docker 唔同，Swarm mode 嘅儲存掛載要考慮到跨節點嘅數據一致性同可用性，唔係就咁用 -v 咁簡單。
首先，我哋要搞清楚三種主要嘅掛載類型：volume、bind mount 同 tmpfs。喺 Swarm service 部署時，最常用同推薦嘅就係 Docker 管理嘅 volume。點解？因為佢天生就為 cluster management 設計。當你用 docker service create 命令時，可以透過 --mount 參數去定義。例如，你想建立一個服務，用一個叫 web_data 嘅 volume 掛載到容器嘅 /var/www/html 路徑，個命令會係咁樣：docker service create --name webapp --mount type=volume,source=web_data,target=/var/www/html nginx:alpine。呢個 volume 會喺每個運行該服務任務嘅節點上自動創建（如果唔存在嘅話），但緊記，呢啲 volume 係本地嘅，即係話 Node A 嘅 web_data 同 Node B 嘅 web_data 並唔會自動同步數據，佢哋係獨立嘅。所以，呢種方式適合掛載啲每個容器實例可以擁有自己一份數據嘅場景，例如暫存檔案或者日誌。
如果你需要跨節點共享同一份數據，咁就要諗計仔喇。一個常見做法係用支援多節點存取嘅外部儲存方案，例如 NFS、Ceph 或者雲供應商提供嘅塊儲存。咁樣，你就可以用 bind mount 嘅方式，將每個節點上面掛載好嘅同一個網絡儲存路徑，綁定到容器入面。例如，你嘅所有 worker nodes 都已經將一個 NFS 分享掛載喺 /mnt/nfs/shared_data，咁你嘅 service 配置就可以係：--mount type=bind,source=/mnt/nfs/shared_data,target=/app/data。咁樣，無論個 Task 被調度去邊個節點，個 Container 存取到嘅都係網絡上同一份數據。呢個方法對於需要共享配置、上傳檔案或者數據庫文件嘅應用好有用，但就要事先設定好所有節點嘅網絡儲存掛載，屬於基礎設施層面嘅準備。
至於 tmpfs 掛載，就係將數據只儲存喺容器嘅記憶體入面，唔會寫入磁碟。喺 Swarm 度，你可以用 --mount type=tmpfs,target=/tmp 咁樣來設定。呢個好適合放啲敏感或者只需要暫時存在嘅數據，因為服務任務一停止，數據就會消失，而且速度快。不過，就要小心唔好放太多嘢，搞到爆記憶體。
講到進階設定，Docker Service 嘅掛載功能好靈活。你可以設定 volume 係唯讀 (readonly) 來保護數據，例如掛載一個配置文件：type=volume,source=config_vol,target=/etc/app,readonly。又或者，你可以利用 Label 同 placement constraints 來做更精細嘅控制。例如，你只有某啲有高速 SSD 嘅節點先有特定嘅本地 volume，你可以喺嗰啲節點嘅 Docker Engine 上打個標籤，比如 storage=ssd。然後喺創建服務時，就可以指定個 volume 必須喺有呢個標籤嘅節點上先創建同使用：--mount type=volume,source=ssd_volume,target=/fastcache,volume-label="storage=ssd" 再配合 --constraint node.labels.storage==ssd。咁樣，個服務嘅任務就只會運行喺有 SSD 嘅節點，並且使用該節點上嘅高速 volume，對於數據庫或者緩存服務呢類對 I/O 要求高嘅應用好有幫助。
另外，喺 服務更新 或者 滾動更新 嘅時候，掛載點嘅配置會點樣處理呢？當你用 docker service update 去修改一個服務嘅掛載配置時，Docker Swarm 會按照你設定嘅更新策略，逐個任務咁停止舊任務、用新配置啟動新任務。新任務會使用新嘅掛載定義。但係，舊嘅 volume 唔會自動被刪除，呢點要特別注意，避免留下大量無用嘅 volume 喺磁碟度，要定期清理。如果你係更新一個用 bind mount 指向新路徑嘅配置，咁新啟動嘅容器就會讀取新路徑嘅數據，呢個可以用嚟做配置檔案嘅熱更新。
最後，提一提 Template Variable 呢個好用功能。喺掛載路徑入面，你可以用一啲模板變量來動態生成路徑，令到每個服務實例都有自己獨立嘅儲存空間，避免衝突。例如，--mount type=volume,source=app_logs,target=/logs/{{.Service.Name}}/{{.Task.Slot}}。咁樣，一個叫 myapp 嘅服務，第一個副本任務 (replica 1) 就會將日誌寫入到 /logs/myapp/1 對應嘅 volume 度。呢個對於日誌收集、或者需要按任務 ID 分隔數據嘅場景非常之實用。
總括來講，喺 Swarm 度搞 儲存掛載，核心思想就係要諗清楚你嘅數據特性：係需要跨節點共享，定係可以本地獨立；係需要持久
AboutoverlayProfessional illustrations
綁定掛載進階選項
好啦，講完基本嘅綁定掛載（bind mount），係時候要深入啲，講下喺 Docker Swarm mode 底下用 docker service create 嘅進階玩法。好多香港嘅開發同 DevOps 團隊，當要將服務正式部署上生產環境嘅 cluster management 集羣時，就會發現簡單嘅 --mount type=bind,source=/path,target=/path 未必夠用，尤其係當你嘅服務要喺唔同嘅 worker nodes 上面跑嘅時候。點解？因為綁定掛載係依賴主機（host）嘅特定檔案系統路徑，如果你個 service 有 5 個 replicas，而佢哋被個 orchestrator 調度到 5 部唔同嘅機上面，咁你點確保每一部機嘅 /path 都有齊需要嘅檔案？呢個就係 Swarm 環境下用綁定掛載嘅核心挑戰。
所以，我哋要識得用一啲進階選項同策略。首先，一個好實際嘅做法係配合 Label 同 placement constraints 一齊用。你可以為某啲有特定資料嘅 worker nodes 打上標籤，例如 docker node update --label-add storage=ssd node-01。然後，當你創建服務時，就可以指定個服務嘅任務（Task）只可以運行喺有呢個標籤嘅節點上，例如 --constraint node.labels.storage==ssd。咁樣，你就可以放心用綁定掛載去指向呢部特定主機上面嘅路徑，確保服務實例只會喺有正確檔案嘅機器上啟動。呢種做法好適合啲需要讀取本地配置文件、license file 或者特殊驅動程式嘅場景，係一種精準嘅 服務配置 手段。
另外，關於 bind mount 嘅權限同傳播設定（propagation），喺 Swarm 度設定要小心。你可以用 ,readonly 參數將掛載設為唯讀，防止容器改到你主機嘅檔案，加強安全。至於傳播模式，例如 rshared、rslave 呢啲，喺複雜嘅掛載嵌套場景下會影響到檔案變更嘅可見性。不過要提提你，喺 Swarm 嘅 service 度設定呢啲進階選項，最好先喺單機嘅 Docker Engine 度測試清楚效果，因為佢同 Linux 核心版本同檔案系統類型好有關聯，唔好假設所有集羣節點嘅行為 100% 一致。
仲有一招進階用法，就係利用 Template Variable。呢個功能好強大，可以令你嘅綁定掛載路徑動態化。舉個例，當你創建服務時，可以喺 --mount 嘅 source 路徑度用模板變量。例如：--mount type=bind,source=/data/{{.Service.Name}},target=/app/data。咁樣，個 Docker Engine 喺每個節點上執行任務時，就會自動將 {{.Service.Name}} 替換成你服務嘅實際名稱。咁做有咩好處？就係即使你同一個服務定義部署多次（例如唔同環境），或者多個服務都需要綁定掛載，佢哋都可以自動隔離到自己專屬嘅主機目錄，避免撞路徑。你可以用嘅變量仲有 {{.Task.Name}}、{{.Node.Hostname}} 等等，呢啲對於日誌收集或者需要按任務隔離數據嘅情況非常有用。
最後，一定要有風險意識。綁定掛載雖然直接高效，但係佢將容器同主機檔案系統緊密耦合，某程度上違背咗容器追求可移植性同一致性的初衷。喺 Swarm 呢類 容器編排 環境，除非必要，否則都係建議優先考慮用 volume（尤其係由 volume driver 管理嘅共享存儲）或者 tmpfs 嚟處理記憶體內嘅臨時文件。如果你真係要用綁定掛載，記住要將佢視為你 服務部署 藍圖嘅一部分，詳細記錄喺文檔，並且要確保你嘅 集羣管理 流程（例如用 Ansible、Chef 等工具）能夠事先將所需檔案同步或創建喺所有相關節點嘅正確路徑上，否則滾動更新（rolling update）或者服務擴展（scale）嘅時候就好易出問題，導致新任務啟動失敗。
總括嚟講，喺 Docker Swarm 玩綁定掛載進階選項，關鍵在於「規劃」同「約束」。你要好清楚自己嘅數據依賴性，然後運用 Label、placement constraints 同 Template Variable 呢啲工具，將服務任務精準地釘去合適嘅節點，並動態生成所需路徑。同時，要明白佢帶來嘅管理成本同可移植性限制，權衡利弊。咁樣先可以喺享受到綁定掛載高性能嘅同時，又能保持到你個 Swarm 集羣嘅運作穩定同可預測性。
AboutvolumeProfessional illustrations
服務監控與除錯
好啦，講完部署同配置，我哋要深入睇下點樣監控同除錯你喺 Docker Swarm 入面運行緊嘅服務。呢個步驟好關鍵，因為你個 service 唔係單機運行，而係由 orchestrator 喺成個 cluster management 架構下分派 task 去唔同嘅 worker nodes，唔識點樣監察同搵問題，出起事上嚟真係會一頭煙。首先，你要識得用 Docker CLI 嘅基本指令去睇清個狀態。最常用嘅就係 docker service ps
當你發現有 task 失敗，就要深入啲睇 Container 嘅日誌。雖然個服務係分散式，但你好彩嘅話，可以用 docker service logs
除咗睇日誌，Docker Engine 本身亦提供咗強勁嘅 健康檢查 功能。當你用 docker service create 嗰陣，一定要識得設定 --health-cmd 同埋 --health-interval 呢類參數。咁樣，Swarm mode 底下嘅 orchestrator 就會定期幫你檢查每個 Container 嘅健康狀態。如果個健康檢查失敗，Swarm 會自動殺死唔健康嘅容器，然後根據你設定嘅 replicas 數量，重新啟動一個新嘅任務去替代。呢個機制對於維持服務高可用性好重要。你可以用 docker inspect --format='{{json .State.Health}}'
網絡同儲存方面嘅除錯亦都係一大課題。如果你個服務要用到 overlay network 去做跨節點通訊，有時可能會有網絡分割問題。你可以用 docker network inspect
另外，滾動更新 過程亦係一個需要密切監控嘅環節。當你執行 docker service update 去做 滾動更新 嗰陣，可以用 docker service ps 實時睇住舊嘅 task 點樣一個個被 Shutdown，新嘅 task 點樣被建立同進入 Running 狀態。如果更新中途出錯，例如新版本個 alpine 基礎映像有問題，或者 環境變數 設錯，你可能會見到個更新過程卡住咗，新任務不斷噉 Starting -> Failed 咁循環。呢個時候，就要果斷用 docker service rollback 去翻轉頭，然後即刻去查日誌搵原因。記住，設定好 --update-failure-action pause 呢類參數，可以防止錯誤更新一瞬間拖垮成個服務，俾你時間去 除錯。
最後，進階啲嘅監控就要用到 Label 同埋 Template Variable 呢啲工具。你可以喺建立服務時，幫唔同嘅 task 或者 Container 打上特定 Label，然後利用第三方監控工具（例如 Prometheus）去收集指標時，就可以根據呢啲標籤去做更精細嘅分組同警報。而 Template Variable 就喺設定日誌驅動或者掛載卷時好有用，可以動態噉將節點主機名、服務ID呢類資訊插入去，令到你喺集中式日誌系統裏面，更容易追蹤到每一條日誌係來自邊個節點、邊個服務副本，大大提升 除錯 效率。總而言之，服務監控與除錯 喺 Docker Swarm 世界入面，係一個結合咗 Docker CLI 指令熟練度、對 集羣管理 架構嘅理解，以及對應用程式本身運作認知嘅綜合技能，一定要花時間摸熟。
AboutmountProfessional illustrations
網絡配置優化技巧
好喇，而家我哋集中火力講下點樣喺 Docker Swarm mode 裡面，幫你嘅 service 做網絡配置優化。好多師兄以為用 Docker CLI 行條 docker service create 指令，開個 overlay network 俾啲 Container 互通就搞掂，但其實要喺生產環境玩得順，特別係管理緊成個 cluster 嘅時候，有好多細節位可以 tune 到盡，直接影響到服務嘅穩定同效能。
首先，你一定要識得善用 overlay network 嘅進階設定。當你喺 Swarm mode 底下，個 manager node 會幫你管理晒所有 worker nodes 之間嘅網絡通訊。默認情況下，個 overlay network 用嘅係 VXLAN 封裝，如果你啲 task 喺同一個物理主機上面，其實可以慳返啲 overhead。點做？你可以喺創建網絡時，設定個 --opt encrypted=true 確保節點間通訊加密，但係要留意，如果所有 task 都喺同一個宿主機，或者你個內網已經好安全，加密可能會增加少少 CPU 負擔，你要自己取捨。另外，記得為唔同類型嘅 service 分開唔同嘅 overlay network，例如將你個 database 服務同 web backend 服務放喺兩個獨立網絡，咁樣唔單止可以做到邏輯隔離，提升安全，當你要做 rolling update 或者 服務擴展 時，網絡流量都會清晰好多，唔會亂晒龍。
跟住要講嘅係點樣聰明地設定 port publishing。好多新手會慣性用 -p 80:80 呢種模式，將宿主機端口直接映射去 service。喺 Swarm 裡面，咁樣做會令到個端口喺 cluster 每一部機（包括 manager 同 worker）都打開，然後靠 routing mesh 將請求路由去正確嘅 task。但係，如果你某個 service（例如一個內部管理後台）只係想俾內部存取，唔想暴露俾外網，或者想減輕 routing mesh 嘅負擔，你可以考慮用 ingress mode 嘅 published 模式。更進階嘅做法係，為一啲需要高效能、低延遲嘅服務（例如 cache 服務），直接設定用 --endpoint-mode dnsrr 而唔用 VIP（虛擬IP），再配合外部負載均衡器去做 服務配置，咁樣可以 bypass 咗 Docker 嘅 routing mesh，減少一層網絡轉發，對於流量好大嘅服務嚟講，效能提升會好明顯。
另一個好關鍵嘅優化技巧，就係點樣安排 task 嘅位置，即係 placement constraints 同埋 Label 嘅運用。呢個雖然唔係純網絡設定，但同網絡效能息息相關。想像一下，如果你有兩個 service，例如一個係 web app，另一個係佢要用嘅 Redis cache，佢哋之間嘅網絡呼叫非常頻密。如果你由得個 orchestrator 隨機將 replica 分佈去唔同嘅 worker nodes，咁佢哋之間嘅通訊就要行翻 overlay network，跨宿主機網絡點都會有少少延遲。點樣可以令佢哋行得快啲？你可以透過 Label 去標記你嘅節點。例如，你喺某幾部機嘅 Docker Engine 設定入面，加上類似 storage=ssd 或者 zone=zone-a 嘅 Label。然後，當你創建服務時，就可以用 --constraint 參數，將個 web app 同 Redis cache 服務，都指定去有相同 zone 標籤嘅節點上面。咁樣，好大機會佢哋嘅 Container 會喺同一部物理機上面一齊運行，佢哋之間嘅通訊就可以行翻宿主機內部網絡，速度會快好多，同時亦可以減少 overlay network 嘅流量壓力。呢種 cluster management 策略，對於數據庫同應用程式呢類需要緊密溝通嘅服務組合，效果尤其顯著。
最後，唔好忽略咗 服務更新 同 擴展 時對網絡嘅影響。當你進行 滾動更新 時，新版本嘅 task 會逐個起，舊嘅會逐個落。呢個時候，個 overlay network 入面嘅服務發現（Service Discovery）機制就好重要。你要確保你嘅應用程式有處理好 graceful shutdown，同埋能夠應付短暫嘅連接斷開。另外，當你用 docker service scale 去即時增加 replicas 數量時，大量新 Container 同時啟動並加入網絡，可能會對網絡造成一啲衝擊。一個好習慣係，為你嘅 service 設定合理嘅 resource limits，特別係網絡緩衝區嘅記憶體限制，避免單一服務耗盡節點資源，影響到其他服務嘅網絡連通性。同時，善用 健康檢查 功能，等 Docker Engine 可以準確判斷新 task 係咪已經準備好接收流量，避免將請求派去一個未完全 ready 嘅容器，造成錯誤。
總括嚟講，網絡配置唔係 set 完就算，而係要配合你嘅 服務部署 策略、資源規劃同埋 集羣管理 方針一齊考慮。由選擇正確嘅網絡驅動程式、精心設計端口發布策略、運用 Label 同 placement constraints 去優化 task 擺位，到管理更新與擴展時嘅流量，每一步都係學問。做得好，你個 Swarm cluster 入面嘅服務就會又穩又快，容器編排 嘅威力先至可以真正發揮出嚟。
AbouttmpfsProfessional illustrations
資源限制與分配
講到喺 Docker Swarm 入面做服務部署，最重要嘅一環就係點樣設定資源限制與分配。好多 DevOps 工程師初初用 docker service create 嗰陣，可能淨係掛住點樣配置個 overlay network 或者點樣掛載個 volume，但就好容易忽略咗為每個 Container 設定合理嘅 CPU 同記憶體限制，結果搞到成個 cluster management 失衡，某啲 worker nodes 負荷過重，甚至拖垮成個服務。咁樣唔單止影響效能，仲可能令到成個 Swarm mode 嘅容器編排優勢蕩然無存。所以，今日我哋就深入傾下，點樣喺建立 Docker Service 嗰陣，精明地分配同限制資源。
首先，你一定要明白，喺 Swarm 呢個集羣管理架構下，當你發出一個 docker service create 指令，Docker Engine 裡面嘅 orchestrator 就會負責生成指定數量嘅 Task，然後將呢啲任務調度到唔同嘅節點上執行。如果你冇明確設定資源限制，每個 Container 就會好似一個「大食客」咁，可以任意蠶食宿主機嘅資源，直到食爆為止。呢個情況喺服務擴展 (scale) 或者進行滾動更新 (rolling update) 嗰陣特別危險，好容易引發骨牌效應，令多個服務一齊崩潰。因此，資源限制唔單止係為咗公平，更加係為咗穩定性同可預測性。
具體點樣做呢？喺 Docker CLI 入面，你可以用 --limit-cpu 同 --limit-memory 呢兩個關鍵參數。例如，你想建立一個用 alpine 做基礎鏡像嘅服務，並且確保每個 replica 唔會用超過 0.5 個 CPU 核心同 512MB RAM，你就可以咁樣寫指令：docker service create --name my_app --replicas 3 --limit-cpu 0.5 --limit-memory 512m my_image:tag。咁樣一來，Swarm 嘅調度器就會知道每個任務嘅資源需求上限，從而做出更聰明嘅任務管理，避免將太多重負載嘅容器塞去同一部 worker nodes 度。同樣地，你亦可以用 --reserve-cpu 同 --reserve-memory 嚟預留資源，確保個服務一定有足夠嘅資源起步，唔會因為其他服務搶資源而啟動失敗。
除咗 CPU 同記憶體，另一個經常被忽略嘅資源就係 I/O（磁盤讀寫）。雖然 Docker Service 本身冇直接喺 service create 提供 I/O 限制參數，但你可以透過配置 volume 嘅方式間接管理。例如，你使用 bind mount 或者 tmpfs 嘅時候，就要考慮到磁盤空間同讀寫速度。尤其係 tmpfs，佢係將資料寫入記憶體，速度快但空間有限，好適合放暫存檔，但如果你唔設定大小限制 (--mount type=tmpfs,tmpfs-size=10000000)，一樣有機會耗盡資源。所以，資源分配係一個全方位嘅考慮。
講到分配，就不得不提 placement constraints 同 Label。資源限制係講緊每個容器「食幾多」，而放置約束就係決定「邊個食得好啲」。例如，你有一批標記咗 disk=ssd 嘅節點，你可以透過 --constraint node.labels.disk==ssd 呢個參數，將需要高速 I/O 嘅服務指定去嗰啲節點度運行。又或者，你想將 manager node 專門用嚟做管理，唔好運行普通服務任務，你就可以設定約束，避免服務被調度過去。呢種精細化嘅控制，結合資源限制，先至係真正嘅高效集羣管理。
另外，環境變數 (environment variables) 同健康檢查嘅設定，其實都間接影響資源分配。一個設定得唔好嘅健康檢查，可能令到容器不斷重啟，無謂地消耗 CPU 周期。而透過環境變數或者 Template Variable，你可以動態調整容器內應用程式嘅資源使用行為，例如 JVM 嘅堆記憶體大小，令到應用層面嘅限制同容器層面嘅限制保持一致，避免衝突。
最後，我哋要記住，資源限制與分配並唔係「Set完就算」。當你進行服務更新或者調整 replicas 數量時，都要重新評估資源配置係咪仍然合理。例如，你將一個服務從 3 個副本擴展到 10 個副本，原本每個容器分配 1GB 記憶體可能就好快會令到集羣記憶體不足。所以，持續監控同調整先係王道。總而言之，善用 docker service create 提供嘅資源相關參數，配合 Label 同約束，你先可以喺 Docker Swarm 嘅世界入面，真正做到資源嘅公平、高效同穩定分配，確保你嘅服務配置能夠支撐得起業務需求，同時又唔會浪費任何一丁點寶貴嘅硬件資源。
AboutalpineProfessional illustrations
實戰部署案例解析
好啦，講咗咁多理論同指令，係時候睇個實戰部署案例解析，等我哋用一個具體嘅例子，由頭到尾行一次點樣用Docker Swarm去建立一個穩定嘅服務。假設我哋要部署一個簡單嘅Web API服務，用alpine做基礎鏡像，但會加入一啲實際運作一定會遇到嘅配置，例如掛載卷、環境變數同埋健康檢查。
首先，我哋個Swarm mode已經啟用咗，有一個manager node同幾個worker nodes。我哋嘅目標係建立一個服務，要求有3個replica（複本），確保佢高可用性，仲要將內部嘅80埠公開（publish） 出主機嘅8080埠。呢個時候，我哋就會用Docker CLI打指令：docker service create。最基本嘅指令可能係 docker service create --name my-web-api --replicas 3 -p 8080:80 alpine，但咁樣太簡單，實戰唔夠用。
我哋要考慮埋數據持久性。假如個服務需要讀取一啲設定檔，或者記錄日誌（log），我哋就需要用到volume。例如，我哋可以預先建立一個Docker Volume，或者直接用bind mount將主機上某個目錄（例如 /opt/config）掛載入Container裡面嘅 /app/config 路徑。喺 docker service create 指令度，我哋就可以加入 --mount type=bind,source=/opt/config,destination=/app/config。咁樣，即使個Container因為更新或者故障重新啟動，啲設定檔都仲喺主機度，唔會唔見。如果係一啲好敏感、暫時性嘅數據，你甚至可以用 tmpfs 類型嘅掛載，將資料只放喺記憶體，速度超快但Container一停就無。
跟住到網絡配置。Swarm 嘅服務預設會連接到一個叫 ingress 嘅 overlay network，呢個網絡跨成個集羣管理，令到唔同主機上嘅Container都可以互相通訊。如果我哋個服務需要內部同另一個數據庫服務溝通，我哋可以自訂一個 overlay network，例如 docker network create -d overlay my-private-net，然後喺建立服務時用 --network my-private-net 參數加入去。咁樣就做好咗網絡隔離，安全好多。
環境變數同Label喺實戰部署都好重要。例如，我哋可以用 --env "LOG_LEVEL=debug" 去設定運行時環境。而 Label 就可以用嚟標記啲節點，配合 placement constraints（放置約束）去精準控制個服務運行喺邊啲 worker nodes 上面。譬如，我哋有啲節點係SSD硬碟，我哋可以俾佢哋打上 label disk=ssd，然後喺建立服務時加入 --constraint 'node.labels.disk == ssd'。咁樣，orchestrator（即係Swarm個編排引擎）就只會將Task（任務）分配去呢啲有標籤嘅節點，對於有特殊硬件需求嘅服務嚟講係必須嘅。
仲有一樣嘢唔少得，就係健康檢查。Swarm可以靠監察Container內嘅健康檢查指令，去判斷個服務實例係咪真係健康運作中。我哋可以喺Dockerfile度定義好，或者直接喺 docker service create 時用 --health-cmd 參數指定。例如，加個 --health-cmd "curl -f http://localhost/health || exit 1"，咁 Docker Engine 就會定期執行呢個檢查。如果個Container連續幾次健康檢查失敗，Swarm就會自動殺咗呢個唔健康嘅實例，然後喺另一個節點度重新啟動一個新嘅Task，呢個就係容器編排強大嘅自我修復能力。
最後，我哋要諗埋服務更新策略。實戰上，我哋唔會一次過將所有replica停機更新。Swarm提供滾動更新功能。我哋可以喺建立服務時，或者之後用 docker service update 指令，設定 --update-delay 同 --update-parallelism。例如，我哋可以設定每次平行更新2個Container，每更新完一組就等10秒，確保服務唔會中斷。呢個過程完全自動化，係現代服務部署同服務配置嘅核心。
所以，一個完整嘅實戰指令可能會係咁樣：我哋要部署一個有3個複本、有配置掛載、有環境變數、有健康檢查、並且限制咗CPU同記憶體使用量嘅服務。指令會包含多個參數，例如 --replicas 3、--mount、--env、--health-cmd、--limit-cpu 同 --limit-memory。透過呢個案例，你可以見到 docker service create 呢個指令嘅威力，佢將服務擴展、資源限制、網絡配置、儲存管理同任務管理全部整合喺一個指令入面，只要規劃得好，就可以好輕鬆咁管理一個分散式系統。記住，所有設定都可以事後用 docker service update 去修改，Swarm 會幫你處理好滾動更新，呢個就係用 Docker Service 做集羣管理嘅方便之處。