AboutDockerProfessional illustrations
Docker Stack Deploy 係乜？
好，等我哋用香港人嘅口語，深入淺出噉講下 Docker Stack Deploy 係乜。簡單嚟講，佢係一個 Docker CLI 入面嘅指令，專門用嚟喺 Docker Swarm 集羣（或者叫叢集）上面，一次過部署同管理一整個由多個服務組成嘅應用程式。如果你用開 Docker Compose 喺自己部開發機度玩開 Nginx、Redis 呢類 多容器應用部署，咁 Docker Stack Deploy 就可以理解為將你個 Compose file 搬上 生產環境 嘅 Swarm 集羣去做 集羣部署 嘅「生產力工具」。
點解要咁做呢？因為而家啲應用好多都係 微服務 架構，一個應用可能由十幾個、甚至幾十個獨立嘅 容器 組成，每個容器負責唔同功能。如果你仲係用人手逐個 容器 去 set、逐部機去 deploy，真係搞到天光都未搞掂，仲好易出錯。Docker Stack Deploy 就係為咗解決呢個 容器編排 嘅煩惱而生。你只需要寫好一個 YAML 格式嘅 堆疊檔案定義（同 Docker Compose 嘅 docker-compose.yml 係 99% 相似），然後用一句 docker stack deploy -c your-file.yml your-stack-name，Docker Swarm 就會自動幫你喺整個 集羣 嘅節點上面，根據你嘅設定，拉取鏡像、建立 overlay 網路、啟動指定數量嘅 服務副本，並且持續監控住佢哋嘅狀態。呢個過程就係所謂嘅 服務編排 同 堆疊部署。
舉個實用例子啦，假設你公司有個網站應用，需要一個 Web Server（例如 Nginx）、一個應用程式伺服器同一個數據庫（例如 Redis）。喺開發階段，你可能用 Docker Compose 喺本地機將三個服務連埋一齊嚟測試。但係當你要上 生產環境，要確保服務高可用、可以承受大量流量，你就需要一個 Swarm 集羣（即係一組聯網嘅主機，可以係實體機或者 VM）。呢個時候，你唔使重新寫過套設定，基本上可以直接用返個 Compose file，喺裏面加返一啲 Swarm 先有嘅進階設定，例如 服務副本 數量、資源限制、滾動更新 策略、節點標籤（用來指定某個服務必須運行喺有特定標籤嘅主機上，例如有 GPU 嘅機器），然後就用 docker stack deploy 指令去部署。呢個指令會同 Docker Registry 溝通，拉取最新嘅鏡像，然後喺集羣內部分配工作，自動完成整個 分散式應用 嘅部署。
咁佢同直接用 docker service create 有咩分別呢？最大分別就係「堆疊」呢個概念。Docker Stack 係一個管理單位，將一組相關聯嘅 服務、網路、Volume 同 Docker 密鑰 打包埋一齊。用 stack deploy 嘅好處係，你可以用一個指令就管理成個應用嘅生命週期。當你需要更新個應用嘅時候，例如想將 Nginx 升級去新版本，你只需要修改 YAML 檔案裏面嘅鏡像標籤，然後再行一次同一個 docker stack deploy 指令。Swarm 就會自動執行 滾動更新，逐個逐個 容器 咁換上新版本，確保服務 零停機部署，用戶完全唔會感覺到更新緊。呢個對於維護網站同 API 服務嘅可用性，真係非常重要。
另外，docker stack deploy 亦處理咗服務之間嘅網絡連接。佢會自動建立一個 overlay 網路，等同一個堆疊內嘅唔同服務可以透過服務名互相溝通，而唔使理對方實際運行喺集羣邊部機上面。呢種 服務部署 模式，令到開發同運維（DevOps）團隊可以好清晰噉用代碼（即係個 YAML 檔案）去定義成個 生產環境 嘅狀態，版本控制同重現部署都變得非常容易。總括嚟講，Docker Stack Deploy 就係將 Docker Compose 嘅簡便性，帶到 Docker Swarm 嘅 叢集管理 世界入面，係實踐 容器化 同 微服務 架構時，一個不可或缺嘅 服務擴展與更新 同 集羣管理 工具。
AboutDockerProfessional illustrations
2026年最新部署攻略
好啦，各位IT老友記，而家就同大家深入拆解下2026年最新嘅 Docker Stack deploy 部署攻略。喺呢個年頭，容器編排 已經係部署 分散式應用 嘅基本動作，而 Docker Stack 依然係喺 Docker Swarm 集羣上管理 多服務應用 嘅利器。同以前淨係用 Docker Compose 喺單機玩唔同，堆疊部署 係直接面向成個 生產環境 嘅 Swarm 集羣，講求嘅係服務嘅高可用性、易擴展同埋 零停機部署。
首先，你要準備好你嘅 Compose file，即係嗰個 YAML 檔案。但係要記住，用嚟做 docker stack deploy 嘅檔案，雖然語法同 Docker Compose 相似，但係有啲指令係專門為 Swarm 模式而設嘅。例如，你唔可以再用 build 呢個指令叫集羣現場幫你建構映像，2026年嘅最佳實踐係一定要預先將映像推送到 Docker Registry，無論係公開嘅 Docker Hub 定係自己公司搭建嘅私有倉庫。咁樣每個 Swarm 節點先可以順利拉取到相同版本嘅映像，確保部署一致性。另外，你要好好定義 服務副本 嘅數量，例如 replicas: 3，咁樣 Swarm 嘅調度器就會自動喺唔同嘅工作節點上幫你運行指定數量嘅容器實例，即使某個節點跪低咗，服務都唔會受影響，呢個就係 集羣管理 帶來嘅好處。
講到網路設定，overlay 網路 係 Swarm 集羣入面嘅重中之重。你需要喺堆疊檔案度明確定義一個 overlay 類型嘅網路，咁樣先可以確保唔同節點上運行嘅 容器 能夠跨主機互相通訊。例如你個應用入面有個 Nginx 服務要同後端嘅 Redis 服務講嘢，只要大家連接到同一個 overlay 網路，就算佢哋分別被調度到地球兩端嘅節點上，都一樣可以透過服務名直接發現同連接，完全唔使擔心複雜嘅網絡配置，呢個對於部署 微服務 架構應用係不可或缺嘅。
部署嘅時候，Docker CLI 嘅指令好簡單，就係 docker stack deploy -c docker-compose.yml my_app_stack。但係魔鬼在細節，我哋要深入啲講下 滾動更新 同 服務擴展與更新 嘅策略。喺你個 YAML 檔案度，你可以用 deploy.update_config 呢個段落去設定更新策略。例如，你可以設定 parallelism: 2（每次更新2個副本）、delay: 10s（每次更新間隔10秒）、同埋 failure_action: rollback（更新失敗自動回滾）。咁樣當你需要更新應用版本時，Swarm 就會自動執行一個 零停機部署：逐批逐批咁用新映像替換舊容器，期間服務一直保持可用，用戶完全感受唔到停頓，對於需要7x24小時運作嘅 生產環境部署 嚟講簡直係救星。
另外，2026年嘅部署攻略亦都更加重視安全性同配置管理。Docker 密鑰 呢個功能一定要識用。好似資料庫密碼、API金鑰呢類敏感資訊，千祈唔好直接寫死喺 Compose file 或者鏡像入面。你應該先用 docker secret create 命令將密鑰存入 Swarm 集羣，然後喺堆疊檔案嘅 secrets 部分引用佢。咁樣，密鑰就會以加密形式存儲同傳輸，並且只會掛載到指定服務嘅容器內部嘅記憶體檔案系統中，大大減低洩露風險。
最後，善用 節點標籤 可以幫你實現更精細嘅 容器編排。假設你個集羣入面有啲節點配備咗高性能GPU，有啲就有超大容量嘅SSD。你可以透過 Docker CLI 幫呢啲節點打上標籤，例如 node.role==gpu 或者 storage==ssd。然後，喺你嘅堆疊檔案入面，喺某個服務嘅 deploy.placement.constraints 下面指定呢個服務必須運行喺有某個標籤嘅節點上。咁樣，你個AI運算服務就會自動被調度到GPU節點，而個高速緩存服務就會去咗SSD節點，真正做到資源最優化配置，呢個就係進階 集羣部署 同 叢集管理 嘅技巧。
總而言之，2026年用 docker stack deploy 做 多容器應用部署，已經唔再係單純咁將服務跑起身就算。而係要綜合考慮映像管理、網路互通、滾動更新策略、安全密鑰管理同埋資源調度約束。掌握呢套 服務編排 嘅完整攻略，你先可以自信咁將任何複雜嘅 微服務 應用，穩定、安全、高效咁部署到 Docker Swarm 生產集羣之中，輕鬆應對業務流量嘅變化同持續交付嘅需求。
AboutComposeProfessional illustrations
點解要用 Stack Deploy？
好啦，咁究竟點解要用 Stack Deploy呢？好多朋友玩開Docker Compose，覺得喺單機上定義幾個容器，一個 docker-compose up 就搞掂個多容器應用部署，好似好方便。但當你要將呢個應用搬上生產環境，面對嘅就係一個分散式應用嘅世界，可能涉及幾部甚至幾十部伺服器（即係節點）。喺呢個時候，單純用 Compose file 就唔夠力水啦。Docker Stack 同 Docker Swarm 呢對組合，就係為咗解決生產環境部署同叢集管理而生嘅容器編排利器。
簡單嚟講，Stack Deploy 嘅核心價值，就係將你喺開發時用慣嘅 Compose file (通常係個 YAML 檔案) 昇華，變成一個可以喺整個 Swarm 集羣入面聲明式咁管理多服務應用嘅單位。你唔使再逐部機 SSH 入去手動執行指令，或者寫一堆複雜嘅腳本。你只需要一個定義好晒所有微服務、網路（例如 overlay 網路，等服務可以跨節點互相溝通）、Docker 密鑰同配置嘅 Stack 檔案，然後用 Docker CLI 執行 docker stack deploy，成個集羣部署就會自動搞掂。Swarm 會根據你嘅定義，自動將服務副本分配到合適嘅節點上，並且持續監控住，如果有容器死咗，會自動重新拉翻個新嘅出嚟，確保服務高可用性。
舉個實用例子，假設你有一個網站應用，需要 Nginx 做 Web 伺服器、Redis 做快取、同埋自己寫嘅應用程式。用 Docker Compose，你喺本機可以完美運行。但上到生產環境，你想 Nginx 有 3 個副本分散喺唔同機度做負載平衡，Redis 要有主從複製，而你個應用程式可能要根據流量自動擴展。呢啲服務編排同服務部署嘅複雜需求，就係 Stack Deploy 大顯身手嘅時候。你喺 Stack 檔案（本質上係一個支援更多 Swarm 特定指令嘅 Compose file）入面，可以直接定義每個服務要有幾多個 replicas，設定滾動更新策略（例如逐個容器更新，確保零停機部署），甚至用節點標籤去指定某類服務（例如資料庫）必須運行喺有 SSD 硬碟嘅節點上。呢種聲明式嘅管理方法，令到集羣管理變得極之清晰同可預測。
另一個一定要用 Stack Deploy 嘅重要原因，就係對生產環境至關重要嘅服務擴展與更新流程。想像下你要更新網站入面嘅 Nginx 鏡像版本。如果手動操作，風險高又易出錯。但用 docker stack deploy，你只需要更新 Stack 檔案入面嘅鏡像標籤（例如從 nginx:1.23 改成 nginx:1.24），然後重新部署同一個 Stack。Swarm 就會根據你預先設定好嘅更新策略，自動進行滾動更新——先起一個新版本嘅容器，等佢健康檢查通過後，先停一個舊嘅，如此類推，直到所有副本都更新完畢。呢個過程用家完全感受唔到服務中斷，真正做到平滑升級。同樣地，要擴展某個服務嘅實例數量，都係改一個數字（replicas: 5）再重新部署就得，全自動化，大大減輕運維負擔。
最後，從團隊協作同配置管理嘅角度睇，Stack 檔案就係你整個應用架構嘅「單一真相來源」。呢個 YAML 檔案可以放入版本控制（如 Git），任何變更都有記錄。新同事加入，或者要重建整個叢集，只需要攞到呢個 Stack 檔案同相關嘅 Docker Registry 鏡像，一條指令就可以重建出成個完整嘅、可擴展嘅分散式應用環境。比起一堆散落喺唔同伺服器、唔同腳本入面嘅配置，呢種以 Stack 為中心嘅管理方式，無論對容器編排嘅清晰度、可維護性，定係對生產環境嘅穩定性，都係一個巨大嘅飛躍。所以話，當你個應用要走出單機，面向集羣，Docker Stack Deploy 就幾乎係一個必然嘅、更專業嘅進階選擇。
AboutDockerProfessional illustrations
YAML 設定檔入門教學
好啦，而家我哋就嚟深入講下點樣寫呢個 YAML 設定檔，即係個 Compose file。呢個檔案就係 docker stack deploy 嘅靈魂，你話俾 Docker Swarm 知你要部署啲乜嘢 服務、點樣配置、點樣互相連接。如果你以前玩過單機版嘅 Docker Compose，你會覺得好面善，因為 Docker Stack 用嘅 YAML 檔案格式同佢高度兼容，但係為咗 容器編排 同 生產環境部署，佢多咗一啲專門俾 Swarm 模式用嘅指令，功能更加強大。
首先，你要知道一個最基本嘅概念：呢個 YAML 檔案定義嘅係一個「堆疊」，即係一個完整嘅、由多個 容器 組成嘅 分散式應用。唔好再當佢只係喺一部機上面行嘅嘢，而係要預佢會喺成個 Swarm 集羣 裏面嘅多個 節點 上運行。所以，你寫嘅每一行設定，都要有「集羣管理」嘅思維。檔案嘅開頭通常係 version: '3.8' 或更高版本，呢個版本號唔係指 Docker 嘅版本，而係 Compose 檔案格式嘅版本，用 3.x 以上先可以支援大部分 Swarm 專屬嘅配置。
跟住落嚟就係 services: 部分，呢度就係你定義各個 微服務 嘅地方。例如，我哋想部署一個簡單嘅網站，用 Nginx 做 Web Server，後面連住一個 Redis 做 Cache。咁你就要定義兩個 service。每個 service 下面嘅配置就好關鍵啦： image:：指定用邊個 容器 映像，可以係從 Docker Registry（例如 Docker Hub）拉取，亦可以係你私有 Registry 裏面嘅映像。 deploy:：呢個就係 Swarm 模式嘅精髓所在，單機 Compose 係冇嘅！喺 deploy 底下，你可以設定 服務編排 嘅細節： replicas:：呢個係指定你要幾多個 服務副本。例如設為 5，Swarm 就會自動喺 集羣 裏面搵合適嘅節點，啟動 5 個完全一樣嘅 容器 實例，實現高可用同負載均衡。 update_config:：設定 滾動更新 策略。呢個對於實現 零停機部署 超級重要！你可以設定 parallelism（一次更新幾個副本）、delay（每次更新隔幾耐）、同埋 failure_action（失敗時點做）。咁樣你更新映像版本時，服務就唔會斷啦。 restart_policy:：設定容器失敗時點樣重啟。 placement:：用 節點標籤 嚟控制個服務要部署去邊啲特定節點。例如，你可以標記某啲節點為 disk=ssd，然後喺設定檔指定將個 Redis 服務只放喺有 SSD 嘅節點上，優化性能。
另一個重要部分係 networks:。喺 Swarm 裏面，預設會為每個堆疊創建一個獨立嘅 overlay 網路。呢種網路可以跨越 集羣 裏面唔同嘅主機，令到所有屬於同一個堆疊嘅 容器，就算唔同主機，都可以直接用 service 名稱互相通訊，好似喺同一個區域網路一樣，好方便。你喺 service 配置入面用 networks: 關鍵字將個服務接入去就得。
仲有 configs: 同 secrets: 呢兩個高級功能。喺 生產環境，你唔應該將設定檔或者密碼直接寫死喺映像或者 YAML 入面。Docker Swarm 提供咗 Docker 密鑰 同配置管理功能。你可以事先用 Docker CLI（docker config create / docker secret create）將一個設定檔或者密鑰存入 Swarm 管理層，然後喺 YAML 檔案入面引用。當個 容器 啟動時，Swarm 會自動將呢啲配置以檔案形式掛載入容器內部指定路徑，又安全又方便統一管理。
舉個實啲嘅例子啦，假設我哋個 docker-stack.yml 檔案部分內容係咁樣（記住，我哋而家係用文字描述，唔係寫出嚟當代碼）。我哋定義一個叫 web 嘅服務，用最新版 Nginx 映像，要求部署 3 個副本，更新時一次更新 1 個，等 10 秒。另一個叫 cache 嘅服務，用 Redis 映像，只要 1 個副本，並且限制佢只可以部署喺有 role=cache 呢個 節點標籤 嘅主機上。然後兩個服務都連接到一個叫 app-network 嘅 overlay 網路。最後，我哋仲可以定義一個 secrets，將個資料庫密碼用安全嘅方式傳俾個服務。
總而言之，寫呢個 YAML 設定檔就好似為你嘅 多容器應用部署 撰寫一份詳細嘅「編排劇本」。你要由 集羣部署 嘅角度出發，考慮服務點樣擴展、點樣更新、點樣擺位、點樣互通同點樣保護敏感資料。掌握好 deploy: 段落裏面嘅各種參數，你就已經掌握咗 Docker Stack 進行 服務擴展與更新 同 叢集管理 嘅核心能力。寫好之後，用一句 docker stack deploy -c docker-stack.yml my_app_stack，成個 分散式應用 就會按照你嘅藍圖，喺 Swarm 集羣 裏面自動化地運行起嚟，非常之有效率。
AboutSwarmProfessional illustrations
一次過部署多個服務
好啦，講到 Docker Stack 嘅精髓，就係佢可以幫你一次過部署多個服務，呢個真係管理生產環境嘅神器。想像下，你個分散式應用有成十個八個微服務，每個服務仲要起幾個服務副本，如果逐個逐個用 Docker CLI 去搞，手都軟啦，仲好易出錯。Docker Stack 就係為咗解決呢個痛點而生，佢係 Docker Swarm 模式嘅高階指令，專門用嚟處理多服務應用嘅集羣部署。你只需要準備好一個 Compose file（通常係 docker-compose.yml 格式嘅 YAML 檔案），入面定義晒所有服務（例如 Nginx 做反向代理、Redis 做緩存、再加幾個後端 API 服務），然後一條指令 docker stack deploy -c docker-compose.yml my_app_stack，成個堆疊就會喺 Swarm 叢集裏面自動化咁部署出嚟，所有服務嘅容器、overlay 網路、Docker 密鑰配置，一次過搞掂，效率高到不得了。
咁點解要用 Stack 而唔係就咁用 Docker Compose 呢？呢度就要分清楚場景。Docker Compose 喺單機開發環境好方便，但當你要上生產環境，面對多個節點嘅 Swarm 集羣，Stack 先係正路。Stack 嘅部署係原生為 Swarm 設計，佢會將你個 Compose file 入面嘅定義，轉化成 Swarm 可以管理嘅服務對象，並且支援節點標籤呢類進階編排功能。例如，你可以指定某個需要高效能運算嘅服務，只部署喺貼有 gpu=true 標籤嘅節點上；又或者將資料庫服務固定喺某幾個有 SSD 嘅節點。呢啲細緻嘅容器編排策略，正正係構建穩定生產環境嘅關鍵。而且，所有配置同狀態都由 Swarm 集中管理，你唔使驚某部機死咗會點，Swarm 會自動喺其他符合條件嘅節點上重新調度容器，確保你指定嘅服務副本數量。
講到實際操作，個 Compose file 嘅寫法同平時差唔多，但為咗配合 Swarm，有啲地方要特別留意。首先，服務嘅鏡像最好推送到一個私有 Docker Registry，確保集羣裏面所有節點都能夠拉取到。其次，關於網絡，一定要用 overlay 驅動程式去定義網絡，咁樣先可以讓唔同節點上嘅容器互相通訊，好似喺同一個網絡入面一樣。另外，敏感資料如密碼，就唔好寫死喺 YAML 檔案啦，應該用 Docker 密鑰（Docker Secrets）或者配置檔案（Configs）嚟管理，Stack 部署時會幫你安全地分發到相關服務嘅容器入面。呢啲都係實踐多容器應用部署時，邁向企業級生產環境部署嘅重要步驟。
部署完之後，服務擴展與更新就變得非常輕鬆。如果你想將某個服務嘅副本由 3 個增加到 5 個，只需要修改 Compose file 裏面該服務嘅 replicas 數值，然後重新執行同一條 docker stack deploy 指令。Swarm 會識別到配置變更，並執行滾動更新，逐步用新配置替換舊容器，過程中服務唔會停頓，實現零停機部署。同樣道理，如果你想更新某個服務嘅鏡像版本，只需改咗 image 標籤，再部署一次，Swarm 就會自動幫你逐個副本更新，仲可以設定更新間隔同失敗時嘅回滾策略，管理多服務應用嘅生命週期就係咁順暢。所以話，掌握 docker stack deploy 呢個堆疊部署技巧，對於任何要管理複雜微服務架構嘅團隊嚟講，都係提升集羣管理效率同系統可靠性嘅必修課。
AboutDockerProfessional illustrations
生產環境必學設定
講到生產環境必學設定，我哋就唔可以再好似開發環境咁求其喇。用 Docker Stack 去部署你嘅 微服務 應用，喺 生產環境 就一定要識得點樣設定到佢穩陣、安全同埋可以自動復原。首先，你份 Compose file（即係 YAML 檔案）就係一切嘅核心，佢唔單止定義咗 Nginx、Redis 呢啲服務，更重要係要為每個服務設定好 服務副本 嘅數量。喺 生產環境部署，我哋通常唔會只係 set 一個副本，因為一死機就全停，所以一定要設定多個副本，等 Docker Swarm 可以幫你自動分派同維持服務嘅可用性。另外，記得要善用 節點標籤，呢個係好多新手會忽略嘅 集羣管理 技巧。例如你可以將有 GPU 嘅機器標記做 “gpu=true”，然後喺 Compose file 入面指定某個需要 GPU 運算嘅服務，只可以部署喺有呢個標籤嘅 節點 上面，咁樣資源分配就會精準好多，唔會浪費亦唔會出錯。
跟住落嚟一定要講 滾動更新 策略，呢個係實現 零停機部署 嘅關鍵。喺你份 堆疊檔案定義 入面，你可以詳細設定 update_config。例如，你可以設定每次更新只係替換 25% 嘅 容器，並且要等新版本嘅容器健康檢查通過之後，先至繼續更新下一批。仲可以設定如果更新失敗，就自動回滾到上一個版本。呢啲設定對於確保你嘅 分散式應用 可以平穩過渡，用戶完全感受唔到停機，係極之重要。另外，關於 服務擴展與更新，唔好只係識得用 docker service scale，其實喺 Compose file 入面預先定義好，再用 docker stack deploy 去更新個堆疊，係更一致同埋可追溯嘅做法。
安全設定絕對係 生產環境 嘅重中之重。第一，唔好將密碼或者 API Key 直接寫死喺 Compose file 或者鏡像入面。一定要用 Docker 密鑰（Docker Secrets）功能。無論係資料庫密碼定係第三方服務嘅令牌，都應該透過 docker secret create 建立，然後喺 堆疊檔案定義 入面以檔案形式掛載入容器。咁樣，敏感資料就唔會出現喺日誌或者環境變數入面，大大減低洩漏風險。第二，關於鏡像來源，強烈建議建立自己公司內部嘅 Docker Registry。咁樣做唔單止可以加快 集羣部署 時拉取鏡像嘅速度，更重要係你可以嚴格控制鏡像嘅來源同安全性，唔會用到來歷不明嘅公共鏡像。
網絡設定亦係穩定嘅基礎。對於一個 多服務應用，各個服務之間需要通訊，但係又要同外界隔離。呢個時候就要靠 overlay 網路。喺 Docker Stack 部署時，佢會自動為你個堆疊建立一個獨立嘅 overlay 網路，等堆疊內嘅服務可以透過服務名稱互相發現同連接，而呢個網絡對外係隔離嘅。你需要確保你嘅 Compose file 有明確定義使用呢種網絡，而唔係依賴默認設定。對於好似 Nginx 呢類需要對外開放端口嘅服務，就喺服務定義入面公開端口，但係內部嘅 Redis 或者資料庫服務，就千祈唔好對外暴露，只係俾佢喺 overlay 網路 內都可見，咁先至安全。
最後，監控同日誌呢啲 生產環境必學設定 都唔少得。雖然 Docker Swarm 本身有基本嘅狀態管理，但係你要知道服務嘅健康狀況、資源使用率，就一定要整合第三方監控工具。你可以透過設定，將所有 容器 嘅日誌統一收集到一個中央日誌系統，例如 ELK Stack 或者 Loki。同樣地，監控數據都可以匯出俾 Prometheus。呢啲設定通常需要喺 Compose file 入面定義額外嘅日誌驅動程式或者監控代理 sidecar 容器。記住，容器編排 嘅目的唔單止係將服務行起嚟，而係要確保佢喺 生產環境 下可觀察、可管理、可快速故障排除。將以上所有設定——由副本策略、滾動更新、密鑰管理、私人 Registry、網絡隔離到監控整合——都妥善寫入你份 YAML 檔案，然後用 Docker CLI 執行 docker stack deploy，你先算係真正掌握到 生產環境部署 Docker Stack 嘅精髓。
AboutRegistryProfessional illustrations
Swarm 集羣整合秘訣
講到 Swarm 集羣整合秘訣，其實核心就係點樣將你手上嘅 Docker Compose file，透過 Docker Stack 嘅威力，順利部署到 Docker Swarm 呢個 容器編排 平台上面，並且確保成個 多服務應用 可以穩定、高效咁運行。好多 DevOps 新手以為寫好個 Compose file 就大功告成，但實際喺 生產環境部署 時，就會遇到各種網絡、配置同管理上嘅問題。所以，以下嘅秘訣就係幫你避開地雷，令你嘅 堆疊部署 過程更加順暢。
首先，你一定要理解 Docker Swarm 同 Docker Compose 嘅定位唔同。Compose 主要係用嚟定義同運行本地多容器應用，而 Swarm 就係為咗管理一個 集羣 入面嘅 服務編排。當你用 docker stack deploy 指令時，你其實係將個 Compose file（通常係 YAML 格式）提交俾 Swarm 管理器，由佢負責喺整個 集羣 入面調度同管理你定義嘅 微服務。呢個過程就係 容器編排 嘅精髓。一個好重要嘅秘訣係，你嘅 Compose file 必須要係 Swarm mode 兼容嘅版本（通常係 3.0 或以上），入面嘅指令先會被 Swarm 完全理解同執行。例如，你可以喺 file 入面定義 服務副本 嘅數量，Swarm 就會自動幫你喺唔同嘅 節點 上面起夠指定數量嘅容器，仲會自動監控住，如果有容器死咗，會立即重新啟動一個，確保服務高可用性。
網絡配置係 Swarm 集羣整合 入面最容易出錯嘅一環。喺本地用 Docker Compose，容器之間通訊好簡單，但喺 Swarm 集羣入面，容器可能分散喺唔同嘅物理機或虛擬機（即係唔同嘅 節點）上面運行。咁點樣令到屬於同一個 堆疊 嘅服務（例如一個 Nginx 前端同一個 Redis 緩存）可以互相發現同通訊呢？答案就係要識得用 overlay 網路。當你部署一個 stack 時，Swarm 會自動為呢個 stack 創建一個專屬嘅 overlay 網絡，所有喺同一個 stack 入面定義嘅服務，都會自動接入呢個網絡，並且可以透過服務名稱嚟互相訪問，完全唔使理會佢哋實際運行喺邊個 節點 上。呢個就係實現 分散式應用 通訊嘅基礎。記住，喺你嘅 Compose file 入面，最好明確指定一個自定義嘅 overlay 網絡，而唔好依賴默認嗰個，咁樣對於之後嘅網絡排查同管理都會方便好多。
另一個實用秘訣係善用 節點標籤 同 部署約束。喺一個真實嘅 生產環境，你嘅集羣節點硬件配置可能唔一樣。例如，有啲節點有 SSD 硬碟適合運行數據庫，有啲就記憶體大好適合運行 Redis 呢類緩存服務。你可以透過 Docker CLI 為集羣入面嘅節點打上標籤，然後喺 Compose file 嘅服務定義底下，用 placement.constraints 去指定呢個服務必須運行喺有某個標籤嘅節點上面。咁樣你就可以精準控制每個 容器 嘅運行位置，實現資源嘅最優化分配，對於 集羣管理 嚟講係非常重要嘅一環。
仲有，敏感資料嘅管理絕對唔可以忽視。你唔會想將數據庫密碼或者 API 金鑰直接寫死喺 Compose file 入面然後提交去版本控制吧？Docker Swarm 提供咗一個非常好用嘅功能叫 Docker 密鑰。你可以先將敏感資料創建成為一個 secret，然後喺部署 stack 嘅時候，將呢個 secret 掛載到容器內部成為一個文件或者環境變量。例如，你嘅應用需要連接一個外部數據庫，你就可以將連接字串存為一個 secret，然後喺服務定義入面引用佢。咁樣做既安全，又方便你喺唔同環境（開發、測試、生產）之間切換配置，係 生產環境部署 嘅必備實踐。
講到 服務擴展與更新，docker stack deploy 本身就支援 滾動更新 同 零停機部署，呢個係 Swarm 嘅殺手鐧之一。當你需要更新一個服務嘅鏡像版本時，你只需要修改 Compose file 入面嘅鏡像標籤，然後重新運行一次 docker stack deploy 指令。Swarm 會自動按照你預先設定嘅策略（例如一次更新幾個副本、更新之間等待幾多秒、允許幾多個任務失敗等）逐步用新版本容器替換舊版本。呢個過程入面，服務始終保持可訪問，用戶完全感受唔到停機。呢種能力對於需要持續交付同快速迭代嘅 微服務 架構嚟講，簡直係不可或缺。你仲可以隨時用 docker service scale 指令去動態調整某個服務嘅 副本 數量，嚟應付突然增加嘅流量，實現彈性伸縮。
最後，一定要提提 Docker Registry 嘅整合。喺 Swarm 集羣入面，所有節點都需要能夠拉取到你應用程式嘅鏡像。通常，公司內部會搭建一個私有嘅 Docker Registry。你要確保集羣入面每一個 節點 都已經登錄咗呢個私有 Registry，咁當 Swarm 調度器決定喺某個節點運行一個容器時，佢先可以順利拉到鏡像。如果因為權限問題拉唔到鏡像，個服務部署就會失敗。呢個雖然係基礎，但好多時喺設定新集羣時都會被人忽略，導致部署卡住。
總括嚟講，成功嘅 Swarm 集羣整合 唔單止係識得打條 docker stack deploy 指令咁簡單。由準備一個 Swarm 兼容嘅 Compose file、規劃好 overlay 網路、利用 節點標籤 做精細調度、用 Docker 密鑰 管理配置、到善用內置嘅 滾動更新 機制，每一個環節都有啲竅門要掌握。當你熟練呢啲秘訣之後，部署同管理一個複雜嘅 多容器應用部署 就會變得得心應手，真正發揮 Docker Swarm 作為一個成熟 容器編排 工具嘅威力，讓你嘅 分散式應用 可以穩定、高效咁喺 生產環境 中運行。
AboutDocker 密鑰Professional illustrations
服務網絡點樣配置？
講到用 Docker Stack 部署多服務應用，點樣配置服務網絡真係成個容器編排嘅核心。喺 Docker Swarm 嘅環境入面，網絡配置唔單止關乎容器之間點樣溝通，仲直接影響到服務部署嘅可靠性、安全性同效能。簡單嚟講，如果你冇搞掂個網絡，成個分散式應用就好似啲樓冇鋪好水管同電線一樣，服務之間會「斷纜」，完全行唔通。
首先，你要明基本概念。當你用 docker stack deploy 去執行一個 Compose file（通常係 YAML 格式）時，入面定義嘅網絡會直接影響服務點樣互聯。最常用同推薦嘅就係 overlay 網路。呢種網絡嘅好處係，佢可以跨越 Swarm 集羣入面唔同嘅節點，等啲服務副本無論被調度到邊個物理機或者虛擬機上，都可以用同一個虛擬網絡互相發現同通訊。呢點對於微服務架構尤其重要，因為前端的 Nginx 服務可能要搵後端嘅 Redis 或者應用服務，如果大家唔喺同一個網絡層面，根本連唔到。
咁點樣喺 Docker Compose 檔案（即係 stack file）入面實際定義呢？好簡單，你喺檔案頂層嘅 networks 部分，就可以定義一個 overlay 網絡。例如，你可以定義一個叫 myapp-overlay-net 嘅網絡，並且指明佢嘅驅動程式係 overlay。跟住，喺每個服務（service）嘅配置底下，用 networks 關鍵字將個服務接入去呢個自定義網絡。咁樣，所有接入咗嘅容器，就可以直接用服務名（service name）作為主機名（hostname）嚟互相訪問，呢個係 Docker 內置嘅 DNS 服務提供嘅功能，對於服務編排嚟講超級方便。
但係，淨係識得開個 overlay 網絡唔夠㗎，仲要諗埋網絡嘅細緻設定。例如，網絡嘅子網（subnet）、網關（gateway）呢啲 IP 設定，你可以喺 YAML 檔案入面明確指定，避免同你公司內部網絡或者其他 Docker 網絡撞 IP。另外，網絡嘅附屬選項（driver options）都好有用，例如你可以設定加密選項，等 overlay 網絡入面嘅數據傳輸自動加密，提升生產環境嘅安全性。尤其係當你個 Swarm 集羣嘅節點分佈喺唔同嘅數據中心或者雲端區域時，加密就更加重要。
另一個實戰中常見嘅情景，就係點樣處理對外服務同內部服務嘅網絡隔離。一個好嘅做法係，建立至少兩個 overlay 網絡：一個係「公開網絡」（例如叫 front-tier），用嚟連接需要直接俾用家或者外界訪問嘅服務，例如 Nginx 呢類反向代理；另一個係「內部網絡」（例如叫 back-tier），專門用嚟俾啲後端服務（例如數據庫、緩存、應用邏輯服務）互相溝通。然後，好似 Nginx 呢類邊緣服務，就會同時接入兩個網絡：佢喺 front-tier 網絡聽外來請求，然後透過 back-tier 網絡將請求轉發去後端應用服務。咁樣做可以有效地將你嘅多容器應用部署隔離，後端服務唔會直接暴露喺公共網絡，符合安全最佳實踐。
網絡配置仲同服務擴展與更新息息相關。當你進行滾動更新或者零停機部署時，新版本嘅服務容器會逐個逐個替換舊版本。呢個時候，一個穩定同預先配置好嘅 overlay 網絡就好關鍵。新啟動嘅容器會自動加入已定義好嘅網絡，並且即刻可以透過服務名被其他容器發現，確保更新過程唔會因為網絡問題而導致服務中斷。呢個就係 Docker Swarm 作為容器編排工具嘅強大之處，將複雜嘅叢集管理同網絡抽象化，等你專注喺應用邏輯。
最後，不得不提網絡同其他 Docker Stack 功能嘅協同。例如，你定義嘅網絡可以同 Docker 密鑰（Docker Secrets）或者配置（Configs）一齊使用，確保敏感資料只會被派發到指定網絡上嘅服務容器。又或者，你可以利用節點標籤同服務部署約束（constraints），將某啲對網絡延遲敏感嘅服務（例如應用服務同數據庫）調度到同一個物理節點或者同一個機櫃嘅節點上，再配合 overlay 網絡，可以進一步優化內部通訊嘅速度，對於高效能要求的生產環境部署非常有用。
總而言之，配置 Docker Stack 嘅服務網絡，唔係求其開個網絡就算。你要由應用架構出發，諗清楚服務之間嘅通訊關係、安全隔離需求、以及同集羣管理功能（如滾動更新、密鑰管理）嘅配合。好好規劃同定義你嘅 overlay 網絡，係確保你個多服務應用能夠喺 Swarm 集羣入面穩定、安全、高效運行嘅基石。
AboutNginxProfessional illustrations
點管理配置同更新？
好，問題嚟到「點管理配置同更新？」呢個核心操作，我哋就要深入講下點樣用 Docker Stack 同 Docker Swarm 嘅指令，去靈活管理你個生產環境嘅多服務應用。首先你要明白，docker stack deploy 本身就係一個管理同更新嘅強大工具，佢嘅核心理念係「聲明式」管理。即係話，你唔使逐個容器手動搞，而係透過修改同一個 Compose file（通常係 docker-compose.yml 呢類 YAML 檔案）去定義成個堆疊嘅理想狀態，然後交由 Swarm 去幫你實現。
具體點做呢？假設我哋有個基礎嘅堆疊檔案定義，入面包含咗 Nginx 同 Redis 兩個服務。當你需要更新，例如係將 Nginx 嘅映像版本升級，或者修改某個環境變數，你只需要直接編輯個 Compose file。改好之後，再次執行 docker stack deploy -c docker-compose.yml 你的堆疊名。Docker CLI 接收到指令後，會聰明地比較新舊配置嘅差異，然後只對有改動嘅服務進行滾動更新。呢個過程係零停機部署嘅關鍵，因為 Swarm 會先啟動新版本嘅服務副本，等佢健康檢查通過後，先逐步停止舊版本嘅容器，確保服務唔會中斷。呢種服務編排方式，對於要維持 24/7 運作嘅分散式應用嚟講，係必不可少嘅。
管理配置仲包括一啲進階設定，例如點樣安全地管理密碼同設定檔。呢度就要用到 Docker 密鑰同 Config 呢啲資源。你可以將資料庫密碼、API金鑰呢類敏感資料，透過 docker secret create 指令存入 Swarm，然後喺 Compose file 入面引用。咁樣，密鑰就只會喺記憶體中解密，唔會寫入磁碟，安全好多。至於應用程式嘅設定檔，就可以用 Config 嚟管理，同樣喺堆疊檔案中定義，更新時只需更新 Config 內容再重新部署堆疊，新設定就會自動派發到相關服務嘅容器入面，管理起上嚟非常清晰同安全。
另一個重要管理課題係點樣控制服務喺邊個 Swarm 節點上運行。呢個就用到節點標籤同部署約束條件。例如你個集羣入面有啲節點係配備咗 GPU，有啲就係高記憶體配置。你可以幫呢啲節點打上標籤，好似 hardware=gpu。然後喺 Compose file 定義你個 AI 運算服務時，就可以指定佢必須部署喺有 hardware=gpu 標籤嘅節點上。咁樣，容器編排系統就會自動將個容器調度去合適嘅機器，實現資源最優化運用。對於微服務架構，唔同服務有唔同資源需求，善用節點標籤同部署約束就係高效叢集管理嘅秘訣。
講到更新策略，除咗基本嘅滾動更新，你仲可以喺 Compose file 入面設定得更精細。例如，你可以設定每次更新時，最多可以同時更新幾個副本（parallelism），同埋要等新副本運行幾耐先算健康（update-delay）。甚至你可以設定更新失敗時點樣自動回滾（rollback_on_failure）。例如你個應用有 10 個副本，你可以設定 parallelism: 2 同 delay: 10s，即係每次更新 2 個，更新完一對等 10 秒，冇問題先再更新下一對，好似慢火煎魚咁，好穩陣。萬一更新中途出錯，成個過程就會自動停低，避免成個服務冧晒。
最後，管理同更新離唔開監控同維護。部署完個堆疊，你要識用一系列 Docker CLI 指令去監察狀態。例如 docker stack ps 你的堆疊名 可以睇到每個服務副本喺邊個節點運行、狀態係點。docker stack services 你的堆疊名 就睇到服務整體狀況，例如有幾多個副本正在運行。當你需要縮容或者擴容某個服務時，唔使重新部署成個堆疊，可以直接用 docker service scale 堆疊名_服務名=數量 去調整服務副本數量，非常靈活。而所有用到嘅映像，最好都推送到私服嘅 Docker Registry，確保集羣每個節點都能夠快速、安全地拉取到相同版本嘅映像，呢點對於集羣部署嘅一致性同速度至關重要。
總括嚟講，管理同更新一個 Docker Stack，就係圍繞住一個中心檔案（Compose file）進行。所有變更，無論係更新版本、調整資源、修改設定定係擴縮容，都透過修改定義檔案再重新部署嚟完成。Docker Swarm 會負責將你聲明嘅理想狀態變成現實，過程中提供滾動更新、健康檢查、自動調度等強大功能。只要你掌握好 YAML 檔案嘅寫法同相關 Docker CLI 指令，管理一個複雜嘅多容器應用部署就會變得有條不紊，係實踐容器化同微服務不可或缺嘅技能。
AboutRedisProfessional illustrations
資源分配最佳實踐
講到用 Docker Stack 喺 Swarm 集羣管理入面做資源分配最佳實踐，我哋首先要搞清楚，呢個唔係淨係 set 吓 CPU 同 RAM 咁簡單。喺一個分散式應用嘅生產環境部署入面，資源分配直接影響到成個多服務應用嘅穩定性、成本同效能。好多新手用 docker stack deploy 嗰陣，個 Compose file（通常係個 YAML 檔）裏面嘅 deploy.resources 部分都係求其寫，或者完全唔寫，等 Docker 自己決定。咁樣喺開發環境可能冇事，但一上生產環境，好易就會出現某個服務副本食爆咗個節點嘅記憶體，搞到成個服務冧咗，甚至拖垮其他容器。
所以，第一樣嘢就係要喺你個 stack 檔案定義入面，為每一個服務明確設定 limits 同 reservations。limits 係指個容器最多可以用幾多資源，例如 cpus: '0.50' 同 memory: 512M，咁就點都唔會超過。而 reservations 就係集羣管理系統（即係 Docker Swarm）保證預留幾多資源俾個服務，確保佢一定夠資源行。呢個設定對於好似 Redis 呢類對記憶體好敏感嘅服務尤其重要。你唔想 Redis 因為冇咗記憶體而突然死咗，導致成個微服務架構出錯啩？舉個實例，如果你有個用 Nginx 做 reverse proxy 再加幾個應用服務嘅 堆疊部署，你就要根據每個服務嘅壓力測試結果，喺 YAML 檔度逐個設定好。例如 Nginx 可能食 CPU 多啲但記憶體少，你就要 set cpus: '1.0' 同 memory: 256M；而後面個應用服務可能食多啲記憶體，就要相應調整。
跟住落嚟，就要善用 節點標籤 同 deploy.placement.constraints 呢個強大功能。喺一個混合咗唔同硬件規格嘅 Swarm 叢集入面，唔係每個節點都一樣勁。你可能會有啲節點係高記憶體型，專係用來行 database 或者 Redis；有啲就係高 CPU 型，專係處理運算。透過 Docker CLI 幫唔同嘅節點打上標籤，例如 role=high-memory 或者 disk=ssd，然後喺你嘅 Compose file 入面，就可以指定某個服務一定要部署去有特定標籤嘅節點度。咁樣就實現咗精準嘅資源分配，確保每個服務都行喺最適合佢嘅硬件上，唔會話將個好食記憶體嘅服務錯誤咁放咗去部記憶體好少嘅機度，搞到成個服務編排失哂預算。
另一個好關鍵嘅最佳實踐，就係要考慮服務擴展與更新時嘅資源策略。當你用 docker stack deploy 做滾動更新或者增加服務副本數量嗰陣，Swarm 會逐個咁更新容器。如果你冇預留足夠嘅 buffer 資源，個節點可能喺更新過程中，同時行緊舊版同新版嘅容器副本，瞬間資源需求倍增，結果就係節點負載過高，甚至更新失敗。所以，聰明嘅做法係喺規劃資源嗰陣，就要預留一定比例（例如 20%）嘅空餘資源俾節點，專門用來應付呢啲滾動更新或者突發性嘅擴展需求。同時，喺你個部署設定入面，可以用 deploy.update_config.parallelism 同 order 呢類設定，去控制一次更新幾多個副本，減輕對節點資源嘅瞬間衝擊。
最後，一定要提吓監控同調整。資源分配唔係 set 完一次就一世唔使理。隨住你個分散式應用嘅用戶量增長，或者功能增加，每個微服務嘅資源消耗都會變。你要定期透過監控工具，睇吓每個服務嘅實際 CPU 同記憶體使用量，同你當初喺 YAML 檔設定嘅 limits 同 reservations 有幾大出入。如果發現某個服務長期用唔哂啲預留資源，就可以考慮調低，將資源釋放出嚟俾其他更需要嘅服務。相反，如果個服務成日逼近個 limit，咁就要諗吓係咪要優化個應用程式碼，或者直接調高資源上限，避免影響服務穩定性。呢個持續優化嘅過程，先至係容器編排同集羣管理嘅精髓所在，確保你成個多容器應用部署可以又慳錢又高效咁運行。記住，資源分配最佳實踐嘅目標，就係要喺穩定、效能同成本之間，搵到最完美嘅平衡點。
AboutComposeProfessional illustrations
常見錯誤同解決方法
好，家陣就同大家深入傾下用 docker stack deploy 做 堆疊部署 時，經常會撞到嘅「地雷」同埋點樣拆彈。喺 生產環境部署 呢啲 多服務應用，一個唔小心嘅設定，隨時搞到成個 分散式應用 跪低，所以認清以下常見錯誤真係好緊要。
首先，最多人中招嘅，就係將 Docker Compose 嘅 docker-compose.yml 檔案，就咁拎去 Swarm 集羣部署 度用。好多師兄以為 Compose file 同 Stack file 係一樣，其實 Docker Swarm 對 YAML 檔案嘅支援係有啲唔同。例如，喺 Docker Compose 入面可以用 build: 指令去即時構建映像，但係喺 docker stack deploy 嘅世界，Swarm 係唔會幫你 build image 㗎！你一定要事先將個映像 push 去 Docker Registry，或者確保集羣入面每個 節點 都已經有呢個映像本地副本。如果唔係，部署嗰陣就會出現「image not found」呢類錯誤，搞到個 服務 永遠處於 pending 狀態。解決方法好簡單，就係將你個 Compose file 入面所有 build: 部分，轉為用 image: 去指定一個已經存在於 registry 或節點上嘅完整映像名稱，例如 myregistry.com/myapp:2026-latest。
第二個常見鑊氣，就係冇設定好 overlay 網路。Docker Stack 預設會為你個堆疊創建一個 overlay 類型嘅網路，等堆疊內嘅 容器 可以跨節點通訊。但係如果你喺 YAML 檔案入面，自己定義咗網路，但又冇明確標明係 driver: overlay，或者冇將個網路設定為 attachable（如果你有特別需要），咁樣啲服務就可能會因為網絡唔通而無法互相溝通。特別係當你個應用涉及 Nginx 反向代理去後面嘅 Redis 或者微服務時，網絡設定出錯就會導致 502 Bad Gateway。建議嘅做法係，喺堆疊檔案嘅網路定義部分，清楚寫明 driver: overlay，並且喺服務定義入面，用 networks: 關鍵字將服務連接到正確嘅網路。記住，容器編排 嘅精髓之一就係網絡管理，呢步千祈唔好求其。
跟住落嚟要講嘅，係關於 Docker 密鑰（Docker Secrets）同配置（Configs）嘅管理錯誤。喺 生產環境，你絕對唔應該將密碼、API金鑰呢類敏感資料寫死喺 YAML 檔案或者映像入面。正確做法係用 docker secret create 事先創建好密鑰，然後喺堆疊檔案嘅 secrets: 部分去引用。常見錯誤係，師兄們記得創建 密鑰，但係忘記咗要喺服務定義入面，將個密鑰掛載入去 容器 嘅指定路徑（例如 /run/secrets/db_password）。又或者，創建密鑰嗰陣用嘅名，同堆疊檔案入面引用嘅名唔一致，結果又係搵唔到檔案。呢個係 服務部署 安全嘅基礎，一定要 double-check。
另一個影響 服務副本 調度嘅大問題，就係忽略咗 節點標籤 同資源限制。假設你個 微服務 需要大量記憶體，但你冇喺 Compose file 嘅 deploy.resources.limits 入面設定 memory，咁個 容器 可能會被調度去一個記憶體唔夠嘅 節點 上運行，最後因為 OOM（Out Of Memory）而被系統殺死。又或者，你想某個服務只運行喺有 GPU 嘅節點上，但你冇事先幫啲節點打上標籤（例如 node.labels.gpu==true），並且喺服務嘅 deploy.placement.constraints 入面指定呢個標籤，咁個調度就會亂嚟。集羣管理 嘅細緻度，就係體現喺呢啲資源約束同標籤運用上面。
最後，唔少人喺做 滾動更新 或者 零停機部署 時會遇到麻煩。喺 deploy.update_config 入面，參數設定得唔好，好容易導致服務更新期間出現短暫癱瘓。例如，parallelism: 2 表示一次過更新兩個副本，如果同時將佢哋停咗再起，而你呢個服務又係無狀態嘅，咁就可能會造成請求失敗。一個穩陣嘅做法係設定 parallelism: 1 同 delay: 10s，等一個副本更新完成並健康檢查通過後，隔一段時間再更新下一個，咁樣先算係真正嘅 零停機部署。另外，一定要設定好 deploy.rollback_config，萬一更新出咗事，可以快速用 Docker CLI 執行 docker stack rollback 去還原到上一個穩定版本，呢個係 生產環境 必備嘅安全網。
總括嚟講，docker stack deploy 係一個好強大嘅 容器編排 工具，但要玩得轉，就要對 Docker Swarm 嘅運作邏輯有深入理解。由映像來源、網絡設定、密鑰管理、資源調度到更新策略，每一個環節都唔可以馬虎。記住，堆疊檔案定義 就係你部應用嘅藍圖，畫得越精準，出錯機會就越細，咁先可以確保你嘅 多容器應用部署 順風順水，喺 叢集管理 上真正做到得心應手。
AboutComposeProfessional illustrations
同 Docker Compose 比較
好啦，講到 Docker Stack 同 Docker Compose 嘅比較，好多初學 容器編排 嘅朋友都會有啲混淆，覺得兩者好似差唔多。其實，佢哋雖然都係用 YAML 格式嘅 Compose file 嚟定義 多容器應用部署，但目標同適用場景就好唔同，可以話係「單機版」同「集羣部署」嘅分別。
簡單啲講，Docker Compose 主要係為咗喺單一主機（例如你部開發機或者一部測試伺服器）上面，快速拉起一組有關聯嘅 容器。你用 Docker CLI 行 docker-compose up，佢就會幫你按檔案定義，順序啟動晒 Nginx、Redis、你個應用服務等等。佢嘅重點係方便開發同測試，幫你模擬一個 微服務 環境，但就冇內置嘅高可用性或者 服務副本 管理功能。例如，你想個 Web 服務有 5 個副本分散唔同機行？Compose 本身係做唔到嘅，你要手動搞好多嘢。
而 Docker Stack 就係為 Docker Swarm（即係 Docker 內置嘅 叢集管理 工具）而生嘅部署指令。當你用 docker stack deploy 去部署一個堆疊，你其實係對住一個 Swarm 集羣（可以係多部實體機或者虛擬機組成嘅 節點）落指令。呢個指令會讀取你個 Compose file（嚴格嚟講叫堆疊檔案），然後將入面定義嘅 服務，根據你設定嘅副本數量、資源限制、節點標籤 等等，編排 到集羣中合適嘅 節點 上面運行。呢個就係真正面向 生產環境部署 嘅 容器編排 工具。舉個實例，你份 YAML 檔案入面定義咗一個 Web 服務要有 10 個副本，Docker Stack 就會確保喺成個 Swarm 集羣裏面，無論有咩節點加入或離開，呢個服務永遠保持住 10 個運行緊嘅實例，仲會自動幫你處理 服務發現 同負載均衡，呢啲係 Compose 冇嘅。
再深入啲比較，喺功能支援上都有明顯差異。Docker Stack 喺解讀 Compose file 時，只支援 docker-compose.yml 規範裏面嘅一個子集，特別係針對 集羣管理 同 生產環境 相關嘅選項。例如，Stack 原生就支援 Docker 密鑰（Secrets）同配置（Configs）管理，呢樣對於安全地部署 分散式應用 好重要，你可以將數據庫密碼、API金鑰呢啲敏感資訊，用密鑰形式分發俾集羣內嘅服務使用，而唔使寫死喺鏡像或者環境變數度。另外，Stack 部署會自動建立 overlay 網路，呢種網絡類型可以跨越唔同嘅 Swarm 節點，等唔同主機上嘅容器都可以直接通訊，彷彿喺同一個網絡內，對於 微服務 之間嘅呼叫係必需嘅。相反，標準嘅 Docker Compose 喺單機環境下，通常用嘅係 bridge 網絡，出唔到去其他主機。
仲有一個關鍵分別，就係 服務擴展與更新 嘅策略。用 Docker Compose，你想更新一個服務嘅鏡像版本，通常做法係停咗成組服務再重新 up 過，或者用 docker-compose up --build，但咁樣會有停機時間。而 Docker Stack 配合 Docker Swarm，就內置咗強勁嘅 滾動更新 機制。你只需要更新堆疊檔案入面嘅鏡像標籤，然後再行一次 docker stack deploy，Swarm 就會自動幫你逐個逐個 容器 替換新版本，並且確保整個過程服務唔會中斷，做到 零停機部署。你可以設定每次更新幾個副本、更新失敗點樣回滾，呢啲都係 生產環境 不可或缺嘅能力。
最後喺管理層面都唔同。Docker Compose 管理嘅係一組容器，而 Docker Stack 管理嘅係 Swarm 集羣入面嘅「服務」呢個抽象概念。你喺 Swarm 裏面用 docker service ls 睇到嘅，就係由 Stack 部署出來嘅服務單位。呢個抽象層令到 集羣管理 更加清晰，你唔使關心邊個容器跑喺邊部具體嘅機，你只係管理服務嘅狀態同規模。所以，如果你嘅應用只係喺自己部電腦做開發測試，Docker Compose 絕對係簡單直接嘅好拍檔。但當你要將呢個 多服務應用 搬上 生產環境，面對高可用、擴展性同滾動更新嘅需求，咁就一定要考慮用 Docker Stack 配合 Docker Swarm（或者其他如 Kubernetes 等編排器）嚟做 堆疊部署，咁先至可以發揮 容器化 同 服務編排 嘅真正威力。
AboutYAMLProfessional illustrations
擴展服務實戰示範
好啦，講完基本操作，我哋嚟到真槍實彈嘅擴展服務實戰示範。喺2026年嘅今日，無論你係用緊Docker Swarm定係其他容器編排工具，識得靈活擴展服務係生產環境部署嘅基本功。呢個過程唔單止係將服務副本由1個變10個咁簡單，仲涉及滾動更新、資源分配、同集羣管理嘅智慧。我哋就用一個貼地嘅例子，假設我哋有一個多服務應用，包含一個Nginx web服務同一個Redis緩存服務，嚟示範點樣用docker stack deploy去玩轉服務擴展與更新。
首先，你要清楚你個堆疊檔案定義（即係個Compose file）點寫。呢個YAML檔案就係你整個分散式應用嘅藍圖。喺入面，你可以為每個服務定義deploy段落，呢度就係你施展叢集管理魔法嘅地方。例如，你可以用replicas: 5嚟指定Nginx服務一開始就要有5個容器實例跑緊。但實戰中，我哋更常係按需擴展。假設而家係促銷高峰期，網站流量飆升，我哋就需要即時擴展。呢個時候，你唔使重新寫過個YAML檔，只需要用Docker CLI 打一句docker service scale
不過，齋加副本數唔夠，仲要識得點樣放。呢度就要出動節點標籤呢個神器。你可以預先為集羣內唔同嘅節點打上標籤，例如「高運算」、「高記憶體」、「SSD儲存」。然後喺堆疊檔嘅deploy.placement.constraints入面，指定你個Redis服務必須運行喺有「高記憶體」標籤嘅節點上，而Nginx就可以分散喺所有節點。咁樣做服務編排，就能確保每個服務嘅實例都運行喺最適合佢硬件特性嘅機器上，提升成個生產環境嘅穩定性同效能。
跟住落嚟係滾動更新，呢個係實現零停機部署嘅關鍵。想像下你要將Nginx嘅映像版本升級。你唔可以一下子停晒所有舊容器，咁會造成服務中斷。正確做法係喺堆疊檔定義deploy.update_config。你可以設定parallelism: 2（每次更新2個副本）、delay: 10s（每次更新間隔10秒）、同order: start-first（先啟動新容器，再停止舊嘅）。當你修改咗映像版本，再執行docker stack deploy -c docker-compose.yml
另外，實戰中仲要考慮網絡同配置。所有屬於同一個堆疊嘅服務，預設會加入同一個overlay 網路，使到服務之間可以透過服務名稱互相發現同通訊，呢點對於微服務之間嘅調用非常重要。至於敏感資訊，好似數據庫密碼，就絕對唔應該寫死喺YAML檔。應該用Docker 密鑰 (Docker Secrets) 功能，將密鑰安全地分發到集羣，然後由容器內掛載嘅檔案讀取。呢啲進階設定，都係喺你個Compose file入面定義，確保你嘅堆疊部署既安全又符合最佳實踐。
最後提一提監控同回滾。擴展同更新之後，點知成唔成功？你要習慣用docker service ps
Aboutoverlay 網路Professional illustrations
監控同維護技巧
好啦，講到用 Docker Stack deploy 部署完個 分散式應用 之後，最重要嘅後續功夫就係點樣監控同維護呢個 堆疊部署 喺 Docker Swarm 叢集管理 入面嘅健康狀態。喺 生產環境，你唔可以「放養」式管理，一定要有系統咁睇實佢。首先，最基本就係善用 Docker CLI 指令。你唔好以為 docker stack deploy 完就冇嘢做，你要成日 check 住 docker stack ps
進階啲嘅 監控，就唔可以只靠人手打指令啦，尤其係個 Swarm 集羣 有成幾十個 節點 嘅時候。你一定要設定中央化嘅日誌同指標收集系統。例如，你可以喺你個 docker stack deploy 用嘅 YAML 檔案入面，加多個全球服務（global service），將每個 節點 上面嘅 Docker 日誌，透過 overlay 網路 送去好似 ELK Stack（Elasticsearch, Logstash, Kibana）或者 Loki 呢類日誌系統。同樣道理，監測 容器 嘅 CPU、記憶體用量，你可以部署 Prometheus 嘅 exporter 同 Grafana 來做可視化。咁樣你先可以一眼睇晒成個 多服務應用 嘅表現，知道係咪某個 微服務 食爆咗記憶體，或者個 Redis 服務嘅回應時間變慢咗。
講到 維護技巧，其中一個核心就係點樣安全咁進行 滾動更新 同 服務擴展與更新。當你要更新某個服務嘅映像版本，最理想就係做到 零停機部署。喺你個 Compose file 入面，你要定義好 update_config 嘅參數，例如 parallelism: 2（一次更新兩個副本）、delay: 10s（每次更新隔十秒）、同埋 failure_action: rollback（如果更新失敗就自動回滾）。當你修改咗個 YAML 檔案，再用 docker stack deploy -c
另一個重要維護動作就係管理敏感資料，例如密碼或者 API 金鑰。千祈唔好將佢哋寫死喺 Compose file 或者映象入面。應該要用 Docker 密鑰（Docker Secrets）功能。你事先用 docker secret create 將啲敏感資料存入 Swarm，然後喺 堆疊檔案定義 入面，指明邊個服務需要存取邊個密鑰。Docker 會將個密鑰以加密形式存在管理節點，並且只喺運行相關服務副本嘅節點上，以臨時檔案嘅方式掛載俾個 容器 讀取。咁樣就安全好多，而且當你需要更新個密碼時，只要建立新版本嘅 密鑰，然後再觸發一次 服務部署 嘅 滾動更新 就得。
仲有，要善用 節點標籤 同 佈局約束（placement constraints）來做智能調度。例如，你個 多容器應用部署 裡面，有個 Nginx 服務需要對外，你就可以打個標籤（例如 edge=true）落喺嗰幾部有公網 IP 嘅 節點 度，然後喺 Compose file 入面指定個 Nginx 服務只部署喺有呢個標籤嘅節點上。又或者，某個服務好食 I/O，你可以指定佢只部署喺有 SSD 標籤嘅節點。透過咁樣細緻化嘅管理，可以令成個 集羣部署 嘅資源運用得更有效率，性能更好。
最後，定期清理同檢查都係必須嘅 維護 工作。Docker 運行得耐，會積聚好多唔再用嘅映象、停止咗嘅 容器、同埋殘留嘅 overlay 網路。你可以定時喺管理節點運行 docker system prune -a（小心使用，會清走冇用嘅映象）來釋放空間。同時，要檢查你嘅 Docker Registry 有冇足夠空間，同埋確保你嘅 堆疊 所用嘅映象標籤係明確嘅（例如用 myapp:2026.04-release 而唔係 myapp:latest），避免因為 latest 標籤被更新而引致唔預期嘅變更。總而言之，將 監控同維護 呢啲動作自動化、常規化，先可以確保你喺 生產環境部署 嘅 分散式應用 能夠長期穩定、高效咁運行落去。
About容器Professional illustrations
2026年趨勢同更新
講到二零二六年嘅趨勢同更新，Docker Stack Deploy 呢個領域真係有唔少進化，尤其係喺容器編排同生產環境部署嘅整合度上。以前大家可能覺得 Docker Swarm 對比 Kubernetes 好似簡單啲，但去到二零二六年，Swarm 嘅管理同堆疊部署流程已經變得更加精細同自動化。其中一個大趨勢係零停機部署同滾動更新嘅機制變得更加智能。而家嘅 Docker Stack 唔單止可以透過 Docker CLI 一條指令就處理好多服務應用嘅更新，仲會自動監察每個服務副本嘅健康狀態，確保新版本容器完全啟動同運作正常先至逐步收埋舊版本，真正做到對用戶零影響。呢個對於運行緊 Nginx 做反向代理或者 Redis 做緩存嘅分散式應用來講，真係幫到手，因為呢啲服務一停就可能影響成個系統。
另外，二零二六年嘅 Docker Compose 檔案（即係 Compose file）格式亦都有所延伸，支援更多同雲原生相關嘅配置。雖然核心都係用 YAML 來定義，但而家可以更加靈活咁定義服務編排策略。例如，你可以好直接喺 stack 檔案裡面指定，某個微服務需要根據節點嘅 節點標籤（例如標明有 GPU 或者高記憶體）來部署，等叢集管理更加貼近資源實際情況。同時，overlay 網路嘅設定亦都簡化咗唔少，令到唔同 Stack 裡面嘅容器之間嘅通訊更加安全同高效，對於構建複雜嘅微服務架構係一大助力。
喺集羣管理方面，Docker Swarm 嘅監控同自我修復能力亦係二零二六年嘅重點更新。而家個系統會更加主動咁偵測唔健康嘅容器或者節點，並且自動重新調度服務，確保你定義嘅服務副本數量維持不變。呢個對於生產環境嘅穩定性至關重要。另外，Docker 密鑰（Docker Secrets）嘅管理亦都更加無縫，可以好安全咁同 Docker Registry 整合，喺 docker stack deploy 嘅時候自動拉取需要嘅鏡像同配置，減少人手操作同出錯機會。
最後，不得不提嘅係服務擴展與更新嘅策略變得更多樣化。除咗可以手動調整副本數量，而家更多團隊會利用 CI/CD 管道，每次推送新代碼就自動觸發 docker stack deploy 來進行更新。呢種集羣部署模式，配合 Docker Stack 嘅滾動更新功能，令到多容器應用部署嘅整個生命周期管理變得流暢好多。總括來講，二零二六年嘅趨勢就係將 Docker Stack 同 Swarm 呢套容器編排工具變得更自動化、更智能，同時保持佢一貫嘅簡潔易用優點，等開發者同運維團隊可以更專注喺業務邏輯，而唔係底層基礎設施嘅繁瑣管理上。