docker swarm

標籤：docker swarm

docker swarm 回到最基礎的群集組建

潮流特區
MacauYeah ・2025-11-21

雖然筆者都知道，全世界在講 k8s ，全世界都叫筆者放棄 docker swarm，但無獨有偶，docker swarm 還是有使用的價值。 你只有單個服務在運行，只想要做冗餘或分流。快速地用 docker swarm 做最小可行性産品，推出市場。 傳統的HA功能做到了，但你沒有中央匯整日誌的功能。而你也不想把事情攪得太複雜，使用docker swarm 可以讓你在任何一個管理節點上查看不同 container 的日誌。 你的客戶只提供VM，他可能有自己的k8s平台，但不讓你使用。自建一套docker swarm ，先入場，事後擴展再要求客戶提供k8s，對於客戶來講，先證明系統是有價值的，在金錢成本上或能力上，一定是件比較可以接受的事。 筆者之前介紹過一系列的 docker swarm 教學，但生成群集的部份一直沒有做介紹。因為實在太簡單，所以一直都沒有收納在教學內容當中。但現在考慮其完整性，以及為了讓大家感受一下它有多簡單，所以重新寫了組建群集的步驟。 組成群集 以前各家不同的軟件，想要起一個群集，要左攪右攪，又要重啟。而docker swarm真的很簡單，只要各機中有 docker ，再在各機中順序打指令就好。 node 1 使用docker swarm init docker swarm jointoken manager # node 1 gt; docker swarm init gt; docker swarm jointoken manager To add a manager to this swarm, run the following command docker swarm join token SWMTKN1xxxxxxxxxxxxxxxxxxxxxxx xxx.xxx.xxx.xxx2377 其餘的管理員節點就根據上述的提示，使用 docker swarm join token SWMTKN1xxxxxxxxxxxxxxxxxxxxxxx xxx.xxx.xxx.xxx2377 就好。只要總數的管理員節點有奇數個就可以了（包括當初的node 1）。即是1、3、5等都可以。這是因為在容錯的情況下，必需由管理節點作出多數決，才能容易地知道判斷是哪些節點出現問題。 如果不為容錯，只想增加可工作的機器，那麼我們只需要增加工作節點。我們可以在任何管理員節點生成docker swarm jointoken worker gt; docker swarm jointoken worker To add a worker to this swarm, run the following command docker swarm join token SWMTKN1yyyyyyyyyyyyyyyyyyyyyyy yyy.yyy.yyy.yyy2377 若想要檢查各個節點的工作狀態，在管理員節點上執行 docker node ls 看到了。 docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS ENGINE VERSION xxxxxxxxxxxxxxxxxxxxxxxxx node1hostname Ready Active Leader 28.5.1 yyyyyyyyyyyyyyyyyyyyyyyyy node2hostname Ready Active Reachable 28.5.1 全部教學請見 httpsmacauyeah.github.ioAProgrammerPreparesVMDockerNotesSwarmModeCommandCN.html

Swarm mode 上線 7 - load balancer | 反向代理

潮流特區
MacauYeah ・2025-06-30

前述我們介紹了負載平衡器的概念，也使用了nginx作為反向代理，管理網絡訪問，分流到對應的服務上 docker service 。 nginx是穩定的，大家初次使用 reverse proxy （反向代理），請選擇它，因為相對簡單，也易於在單機上做對比測試。 而nginx有個麻煩的地方，就是每次加 docker service，都需要更改 nginx 的設定。我們service 越多，config檔就越長。一個不少心，某些設定有衝突，就會讓 nginx 無法重起。 所以，我們在一定規模後，就需要改用自動化的反向代理。 traefik 就是其中之一。所恨的是，官方沒有提供 swarm 的範例，需要自行摸索。幸好筆者找到一個Github網路資源，bluepuma77 traefikbestpractice，內有一個traefik在docker swarm上的基本設定，足以解開筆者的某些謎思，至少可以讓筆者進行使用驗證。 bluepuma77 提供的範例可能還有些複雜，筆者就再簡化一下，讓大家可以從最基本的環境中開始。 下述 docker service 中 traefik 自動偵測 swarm 中，有那些其他 service 需要經過traefik 代理。 whoami 一個官方提供的簡單版http 回應，它正常可以回應 http 80的請求。 有一些重要的地方需要特別說明： 需要設定 providers.swarm.exposedByDefault=false，不然traefik自己也需要定義反向代理的port。設定了這個，也可以讓 swarm 中某些 service 得以被忽略。有需要經 traefik 對外的，就在 label 下設定 traefik.enable=true 需要設定providers.swarm.network=proxy，swarm中也需要有該網絡的存在。不然traefik 沒有預設的網絡可以走。 現時 docker service 使用是的 ingress mode，方便 traefik service 可以在不同的 manager 上遊走。測試時需要注意使用 ipv4 ，例如 curl 需要指定 ipv4 的 ip 即curl v H 'hostwhoami.localhost' http127.0.0.1 ，若直接使用 whoami.localhost ，有機會會指向 ivp6 ， ingress mode 就接不到。 Reference httpsgithub.combluepuma77traefikbestpracticeblobmaindockerswarmtraefikdockercompose.yml httpsdoc.traefik.iotraefikroutingrouters#pathpathprefixandpathregexp

Swarm mode 上線 6 - 2| 升級陷阱

潮流特區
MacauYeah ・2025-04-14

上一期筆者就介紹寺過swarm的相容性，可以任意地刪除其中node、加入新的node，系統會自動同步各機狀態。今日，我們就來討論一下加減的流程吧。 實戰輪調流程 假設我們有5個 node，都為manager，各個 docker 版本都為28.0.4 ，我們將要關掉node 5 ubuntu 22，並加入node 6 ubuntu24，輪調流程如下 如果node5有vvip，login node 5，關掉vvip systemctl stop keepalived login node1, 把node5降為drain模式，變為worker，並從群集中刪除 docker node update availability drain node5 docker node demote node5 若然node5不是直接關機、刪除，只想好好地離開群集，可以 login node5, 在node5上預先執行 docker swarm leave docker node rm force node5 如果之前node5有好好地離開群集，而且狀態已經轉為down，那麼就不用quot;forcequot;了，用最保守的刪除指令就可以 docker node rm node5 login node1, 取得manager token docker swarm jointoken manager node5關機，新增node6，使用相容的ip段，或者使用node5的ip login node6, 加入群集，設定vvip docker swarm join token xxxx XX_IPXX_PORT systemctl stop keepalived 這陷阱這陷阱 偏我遇上 上述的操作，有一些可能的陷阱，筆者就剛好踩過，未來不知道會不會有官方保證 docker的版本需要相同，不同版本可能不能加入群集，例如 docker 28.0.4 不能加到 docker 27.5.1。 docker 27.2.x 不能加到 docker 27.5.1。 docker swarm，官方雖然宣稱支援不同版本共存，但這指的是已加入的node，在不解綁的情況下原機升級。 在swarm已有多版本共存的情況下，有一個node選擇完全脫離，它想再加入，也是會失敗的。可能這不是docker自身的限制，而是底層library的相容性問題。筆者在實測不同版本時，就得到這樣的error。docker credentials cannot check peer missing selected ALPN property

Swarm mode 上線 6 | OS升級前的準備

潮流特區
MacauYeah ・2025-04-08

如果大家一直有跟進安全更新，基本上每個一至兩個月，都會有OS kernel和Docker Engine Update。也許大家習慣還是以不變應萬變，但有些時候還是不可避免地遇到嚴重漏動，需要強制更新。那麼當我們在這個情況時，我們該如何做呢？在開始做之前，我們先測試一下Swarm的容錯率有多高。 官方就宣稱，只要swarm中，manager例下的數目沒有超過半數，就依然可以運行。這個部份，筆者相信大家一早就感受過。但筆者認為，在直正出意外的情況是，少於半數的manager倒下了，但其餘的manager又不幸要重啟，到底又些活著的manager，又可否成功重新啟動？所以下面就來做些測試。 測試1 測試REPO 初始化script initDockerCluster.sh 筆者在原本的教學中，就有一個3個manager node 2 worker node的範例，我們只要安裝ubuntu OS, packer, 並使用 # run setupMultipassWithFixIP.sh will install multipass and config fix ip .setupMultipassWithFixIP.sh # install packer, please refer to httpsgithub.commacauyeahubuntuPackerImageblobmainREADME.md packer init template.pkr.hcl packer build template.pkr.hcl # initialize docker cluster in multipass .initDockerCluster.sh 在上述的環境中，node21, node22, node23是manager, node24, node25則是worker。在全關的情況下，只要正常啟動兩台manager，worker就可以成功復活。 測試2 測試REPO 初始化script initDockerClusterLoopJoin.sh 筆者寫了另一個起始方案，會有5個manager node，而且依賴順序如下 node22 =gt; node21 node23 =gt; node22 node24 =gt; node23 node25 =gt; node24 node21 =gt; node22 # initialize docker cluster in multipass .initDockerClusterLoopJoin.sh 在上述的環境中，5台機也是manager。 initDockerClusterLoopJoin 的前半部份，它會建立順序依賴，即每一台機器，都經前一台機器進行加入的動作。而後半部份會把node21刪掉，並經multipass用一個全新的guest os重起，重新加入到。 在全關的情況下，只要正常啟動三台manager，它們都可以繼續運行。 這個測試的例子表明，即使原本作為依賴的機器死了，只要群齊中其餘多數manager仍然存在，它們也是可以復活的。更重要的是，即使最初引領一切的node21死掉了，什至是被刪掉重來，也是相安無事的。 結論 更新時，最保守的做法，是先加入新的manager，再除去舊有的manager。但這個做法下，manager的IP就不可避免地被改變。若然DNS或者防火牆沒有相應的自動化幫忙，先加入再替換就變得很痛苦了。 而上述的測試，其實代表了我們可以先暫停或移除舊有的manager，更新完後再接回去，這樣部份IP就可以重用。我們只要維持多於原本半數的manager活著，然後逐一替換或升級原有的機器，也不會有問題。即使在升級途中，其他manager不幸地斷線，重啟後它們還是有條件自行修復。我們也不需要顧及更新順序，只需想好Virtual IP的分配策略就足夠，其餘就像是單機升級一樣。

概有雲供應商的K8S，為何要自己弄Docker Swarm / 本地K8S ?

潮流特區
MacauYeah ・2024-11-19

其實筆者寫了這麼多篇docker 的文章，可能有朋友會問，為何要自己從零建立Container環境，使用供應商直接提供的K8S服務不是很好嗎？ 按照市場發展，各大雲供應商都越來多，競爭越嚟越激烈，作為用戶方，理應可以得到更合理的價格。不過作為使用VPS多年的筆者，真的沒有覺得雲服務的價格可以便宜到一個不用煩惱的水平，大家還是需要很㥀重地考量自己的業務是不是值得雲端化。 正常來講，在有足夠使用量的前提下，雲端化也是合適的，也真的有產到錢。但問題是大部份情況下公司內部自主開發的應用，都沒有去到這個程度。每個應用去租用一個VPS，即使使用最低配置，用起來的時候覺得不夠快，閒起來的時侯也是浪費錢。 這時，使用 Container 技術，就是讓多個不同的應用，共享同一個或多個VPS的好方法。因為 Container 可以簡易地做到應用之間的隔離，即使不同應用之間有依賴衝突，只要 Contianer 層面沒有衝突就可以共存。 Docker swarm 與 K8S 同為 container 技術，文章最前面，就提到了這個問題，為何不選現有的K8S，反而要自己弄Docker Swarm？其實關鍵亦是價錢的問題。使用K8S固然方便，但就每個節點都得使貴一級的雲端供應商服務，當我們的應用總是流量不足，就更易變得食之無味，棄之可惜。老實講，貴一級的雲端服務，有它存在的價值，很多東西可以做自動化擴展，例如概據流量自動擴容。另外，因為底層 Container 技術有供應商支援，也不用再另外購買支援服務。但這些都是業務有一定流量，才能展現出優勢。 反觀Docker Swarm，就是簡單可入手，初時一個VPS也可以。什至乎不上雲，找幾台舊電腦，實機做也可以。當然K8S也可以實機，不過就簡易程度來講，Docker Swarm 無得輸。待業務真正成長到一個有足夠流量的服務時，才進一步遷移到供應商的原生雲。在初期使用自建的Docker Swarm或小型K8S，可以先加入一些資源統計，以確定是否即裝滿負荷。

Swarm mode 上線 5 - load balancer | 還有那些事該考量？

潮流特區
MacauYeah ・2024-11-18

前面介紹了 ingress network ，亦介紹了 proxy gateway 。能做到的基本都做到了，再來就是考量安全性的問題。因為加了 proxy gateway ，前述的例子是所有 service ，都放在同一個 yaml 檔中。好處是，所有相關的東西存放在同一個檔中， gateway ，背後的 service 都一眼看到。但壞處就是有其中一個 service 更新，都要改那個 yaml 檔。更大的問題是， stack deploy 的指令，不單只更新其中一個 service ，就連其他 service 都會自動取得最新 image 而 redeploy 。 對於一個緊密的系統來講，同步更新可能不是大問題。但對於一些預定排程發佈的系統可不能這樣因為副作用而更新了。如果你也有這樣的分開管理需求，可以參考下面做法，把 gateway service 及 upstream service 放在不同的檔案中，然後經過 external network把所有 service 串連起來。 # nginxstack.yaml, docker stack deploy c nginxstack.yaml nginx services httpgateway image httpgateway ports 80808080 deploy replicas 1 update_config delay 10s restart_policy condition onfailure # managerstack.yaml services managerhttp image bretfisherhttpenv networks nginx_default default deploy replicas 3 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==manager networks nginx_default external true # dmzstack.yaml services dmzhttp image bretfisherhttpenv networks nginx_default default deploy replicas 2 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==dmz networks nginx_default external true 這樣，不同 service 的維護人員，就可以獨自控制自己的檔案。在第一次發佈時，確認 nginxstack.yaml 先行發佈就可以了。對應的發佈指令是docker stack deploy c nginxstack.yaml nginx，它會自動産生一個 nginx_default （即 stack名字_default ）的網絡。之後其他service，就可以經networks的設定找到它了。 services YOUR_SERVICE networks nginx_default default networks nginx_default external true 上述即使分離檔案，在安全性考量時還是有一個問題，就是 ingress network 的問題。試想一下，dmzhttp （Demilitarized Zone）原本被設定的原因，就是想限制某些訪問只能一些可以公開的服務。但因為經過 ingress network 之後，它們會在所有機器上開放這些 port。那就是，以下面的例子來講，若 dmzhttp 是公開的服務， intrahttp 是內部服務，即使用 intrahttp 使用不同的port 8889。但一經 swarm mode 預設的 ingress network ，在node.labels.zone==dmz的那些節點，還是可以訪問到 intrahttp 。 services dmzhttp image bretfisherhttpenv ports 88888888 deploy replicas 2 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==dmz intrahttp image bretfisherhttpenv ports 88898888 deploy replicas 3 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==intra 我們前述介紹的 proxy gateway ，其實已經有一定程度可以解決這個問題。因為 proxy gateway 是根據 http 協定中的 host header 去做分流。在邊界網絡進來的「合法」訪問，道理上會好好地經引導到我們的 dmzhttp 。不過網路的邪惡可容小看， proxy gateway 也會有被騙的一日。有特定能力的攻擊者，只需找到目標域名，還是可以接觸到 intrahttp 。 若要做進一步隔離，在這種情況下，我們可以在 dmz , intra 機器中各設定一套 swarm ，完全獨立，這是最安全的做法。但這樣做的管理成本就會變高，因為兩個網段都會有自己的 manager 節點，而且在 dmz 網段的 manager 節點也有被攻擊的可能。 若我們回到單一 swarm 的方向，可以修改各個 service 中的 port 和 deploy 。利用 post mode 中的「host」，配合 deploy mode 中的「global」，完全跳開 ingress network。 services dmzhttp image nginx ports target 80 published 8888 mode host deploy mode global update_config delay 1s restart_policy condition any placement constraints node.labels.zone==dmz intrahttp image bretfisherhttpenv ports target 8888 published 8888 mode host deploy mode global update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==intra 上面的例子中， dmzhttp 會在所有 dmz 的機器中，每個節點只運行一份服務，而且直接使用該機的 8888 port ，外面不會再有 ingress network 的 存在。同樣地，intrahttp 會在 intra 的所有節點，運行一份服務，佔用它們的8888 。這兩個服務，即使使用一個 port ，swarm 也不會說有任何問題。因為它們不會經 ingress network 搶佔其他人的 8888。 可能會有讀者問，如果 host mode 這麼安全，為什麼預設會是 ingress network，那我們就要先了理清 ingress network 與 host mode 有有什麼分別？假設我們只運行一個service，它佔用8888。 功能ingress modehost mode replicas 數 同一個 service replicas 為任意數量，什至比節點的數目多 因為有 port 限制，每個節點最多只能運行一份 Virtual IP Virtual IP 任意在節點中跳轉也可以，因為 ingress 會自動找到對應的 service 所在的節點 Virtual IP必需要與 service 所在節點綁定，其他節點訪問不到 load balance 有 沒有 host mode 就像我們傳統在各自的節點上自行佈署自己的程序，各個節點只有一份。所以不會有自動 load balance 的效果，如果客戶端訪問固定的IP，就會得到是固定的接器接受請求。我們有需要，就要在前面加一個 Proxy Gateway 或 HA proxy 。 Virtual IP 也一樣， host mode 下需要好好地自動跟著 service 的生命期，不過幸運的是， Docker 預設己經有自動重啟 service 功能，即前文中的 restart_policy ，它在 host mode 下也適用。如果大家有配合 deploy 中的 global mode ， Virtual IP 的並沒有實際變動。但如果沒有 global mode ，就要再想想辦法了。 最後考慮 load balance 的問題，如果進入點的 service 的真的不太消耗資源，沒有 load balance 也是可以的 ，但若超負荷，就必需要自建 proxy gateway 。經過進入點後，若我有背後的 service 就沒有所謂的 ingress 和 host mode 選擇。

Swarm mode 上線 5 - load balancer | proxy gateway 代理伺服器

潮流特區
MacauYeah ・2024-11-11

前面的例子，我們已經成功設定 ingress Network，也加了 virtual ip 。如果大家的目標是單一 web 應用，應該就已經很足夠。但作為一個足夠節儉的老闆，怎會讓一個 Swarm 只跑一個 Web 應用？但問題來了，一個 docker swarm service 就已經佔用一個公開端口 例如上述的8888，或是更常見的443。怎麼可以做到多個 service 分享同一個端口？答案就是回到傳統的 Web Server 當中，使用它們的 virtual host 及 proxy 功能，以達到這一效果。我們就以 Nginx 為例，去建立一個守門口的網關 gateway 。 以下就是一個最簡單的例子，最前端的 httpgateway nginx 對外公開端口 8080 ，它根據 virtual host，去分派對應的請求去 dmzhttp bretfisherhttpenv 及 managerhttp bretfisherhttpenv 。構架圖就是以下這樣。 ┌───────────┐ ┌──────────────►│ dmzhttp │ │ └───────────┘ │ ┌───────────────┐ │ httpgateway │ ────────►│ nginx8080 │ └──┬────────────┘ │ │ ┌─────────────┐ └─────────────►│ managerhttp │ └─────────────┘ 換成 docker stack ，就大概如下 services httpgateway image httpgateway ports 80808080 deploy replicas 1 update_config delay 10s restart_policy condition onfailure dmzhttp image bretfisherhttpenv deploy replicas 2 update_config delay 10s restart_policy condition onfailure managerhttp image bretfisherhttpenv deploy replicas 3 update_config delay 10s restart_policy condition onfailure docker stack有一個很好的功能，就是 service 名會自動成為同一段網絡中的 hostname 。即是httpgateway中，它可以經DNS，找到 dmzhttp 、 managerhttp，也就是它的 nginx 可以設定成如下的樣子。 # default.conf server listen 8080; listen 8080; server_name managerhttp; resolver 127.0.0.11 valid=30s; location set $upstream_manager managerhttp; proxy_cache off; proxy_pass http$upstream_manager8888$request_uri; server listen 8080; listen 8080; server_name dmzhttp; resolver 127.0.0.11 valid=30s; location set $upstream_dmz dmzhttp; proxy_cache off; proxy_pass http$upstream_dmz8888$request_uri; 上面的例子中，就是一般的 virtual host nginx proxy 設定。特別要說明的是 resolver 那一行，它指向 docker DNS 127.0.0.11， 而且還可以讓nginx在找不到上游時，不要馬上死亡。這樣 docker swarm 中各個 service 隨時加加減減，有保命的作用。 最後我們的 httpgateway 就是 nginx image default.conf 上述的 docker 就可以用以下方式打包。 # Dockerfile # docker image build t httpgateway . FROM nginxlatest COPY default.conf etcnginxconf.ddefault.conf 上面的 docker stack 和 nginx config，只要同步增加 service 及對應的 proxy pass，就可以o讓同一個端口，根據不同hostname做分流。當然，如果大家可以共用端口及 hostname 也可以，分流就改用 nginx location 來設定，不過這是更加偏向 nginx 的內容，日後有機會再介紹。本篇就先集中於 docker 相關的議題。 在安全性的角度， docker 還有一些配置可以做，就是讓 dmzhttp 和 managerhttp 在不同的機器上發佈。假設我們的網絡分開兩段，一段是 manager 專用，一段是 dmz 專用。在建立 docker swarm 後，我們可以為不同的節點加入對應的標簽。 docker node update labeladd zone=manager YOUR_MANAGER_NODE docker node update labeladd zone=dmz YOUR_DMZ_NODE 然後我們通過修改 docker stakc 中的 placement gt; constraints ，限制不同的 service 在不同的節點上運行。 services httpgateway image httpgateway ports 80808080 deploy replicas 1 update_config delay 10s restart_policy condition onfailure dmzhttp image bretfisherhttpenv deploy replicas 2 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==dmz managerhttp image bretfisherhttpenv deploy replicas 3 update_config delay 10s restart_policy condition onfailure placement constraints node.labels.zone==manager 使用上面的例子，我們就可以達到簡單分離的效果。但大家緊記，這個分離效果始終是一個規則式功能，它與防火牆的隔離還是有本質上的區別。除了利用傳統的防火牆技術外，我們的docker swarm network，其實也可以做更多隔離，我們日後再慢慢加強這個例子。

Swarm mode 上線 5 - load balancer | 負載平衡器

潮流特區
MacauYeah ・2024-10-28

前面我們一直談 swarm 的設定，但對於真實的服務，我們還要考慮客戶端是如何連接我們的伺服器群集。通常網路服務，客戶端都會經過域名轉換成IP，然而通過IP連線服務。 Ingress Network 假設我們 swarm 內有5個節點，那到底域名應該指向我們哪一個節點的 IP 呢？ 如果我們不考慮節點死機的話，其實5個節點的IP都可以。因為 swarm 會自動把同一個公開的 port ，在每一個節點上都可以訪問到。 以下例子，即使只有一個 container 運行，佔用 port 8888，它還是會在5個節點上全開。 swarm 通過自己的 ingress network，它所有節點的 8888 串連起來。 services http image bretfisherhttpenv ports 88888888 deploy replicas 1 update_config delay 10s restart_policy condition onfailure 我們可以在每個節點上，都會找到這個 ingress network，而且那個Network ID，應該是一樣的 gt; docker network ls grep ingress t7rmk6g9zybm ingress overlay swarm 如果上述的 service 的 replicas 調成大於1的數量， ingress network 還會方便地自動 round robin 輪替 地分派流量，達到最簡單的負載平衡。 Virtual IP 前述的設定，我們有一最大的假設，就是節點不會死機。但實際情況下，各種原因，例如安全性更新、重啟中，都會讓節點暫時無法使用。即使所有 service 都是會自動 failover 故障轉移，但客戶端還是用舊機 IP ，它還是無法訪問。因為該機 IP 已無法使用，除非我們連 IP 也懂 failover。這時， Virtual IP 就是我們的救命靈藥。 在 ubuntu 上，我們可以經過 keepalived 去設定 Virtual IP aptget update amp;amp; aptget install keepalived y 然後設定 keepalived ， 假設 172.22.1.5 是我們的 Virtual IP 。 然後每個節點都要加入conf # vim etckeepalivedkeepalived.conf # assume failover ip is 172.22.1.5 vrrp_instance VI_1 # change interface according to machine status interface eth1 state MASTER # 101 for node1, 102 for node2 # you can start seq from other value, remind unqiue for each node is ok; virtual_router_id 101 # lower value will become master # ex, node1 priority 100, node2 priority 200, node3 priority 150. # if node 1, 2, 3 alive, node2 will become master. # if node 2 gone, node 3 will become master. priority 100 advert_int 1 authentication auth_type PASS auth_pass YOUR_RANDOM_PASSWORD virtual_ipaddress 172.22.1.5 上述需要特別注意的是 virtual_router_id 每個節點應該都要不一樣，以作唯一標識。 priority 每個節點應該都要不一樣，最大的那個節點，就會優先使用 Virtual IP 。 auth_pass 每個節點都相同，但大家在抄時，記得更改。 還有的是開通 iptables ，讓各個節點可以經網絡廣播的方式互相看到對方。 iptables I INPUT d 224.0.0.08 j ACCEPT iptables I INPUT p vrrp j ACCEPT systemctl restart keepalived

Swarm mode 上線 4 | IP 設定

潮流特區
MacauYeah ・2024-07-23

單機模式 IP設定 平常我們自己做測試，網絡功能通常用預設的就好。但當我們的Docker Container需要存取在區域網內的其他資源，避晚IP網段相衝是必需要的事。 大部份情況下，單機Docker使用的預設IP段會是 172.17.0.016 172.18.0.016 ... 若然現在區域網中，有一段172.18.0.024，大家不想Docker踩到其中，可以修改設定檔，加入預設的defaultaddresspools，以後它就只會從指定的區段使用。 # vim etcdockerdaemon.json quot;defaultaddresspoolsquot; quot;basequot; quot;172.17.0.016quot;, quot;sizequot; 24 , quot;basequot; quot;172.19.0.016quot;, quot;sizequot; 24 , quot;basequot; quot;172.20.0.016quot;, quot;sizequot; 24 其中base，是docker可以操作的總區域，size指的是Docker要自行分段的話，每段的大小是多少，上述的例子，就代表未來可能有以下Docker 網段。 172.17.0.024 172.17.1.024 ... 172.17.255.024 172.19.0.024 172.19.1.024 ... 172.19.255.024 172.20.0.024 172.20.1.024 ... 172.20.255.024 修改完設定後，重啟Docker就會生效。當然，重啟前，先刪除所有不在預設範圍的所有Container。 Swarm模式 IP設定 Swarm模式，與單機差不多，它需要在初始化Swarm就要定義，而且它不能與單機的網段有重疊。單機會預設使用Private IPv4 Class B，Swarm則是預設使用Private IPv4 Class A段，所以我們若就更改，就使用10.x.x.x吧。 docker swarm init defaultaddrpool 10.1.0.016 defaultaddrpoolmasklength 24 經上述例子初始化的 ingress 網段，將會是 10.1.0.024，隨後每個stack 則會是 10.1.1.024 10.1.2.024 10.1.3.024 重置Swarm 跟單機的情況類似，如果已建立Swarm後才修改網段，還是要整個刪掉重來。 每個節點都要執行以下指令。 docker swarm leave force 實測swarm leave這個指令也會把所有運行中的stack刪掉。 各節點重新建立swarm # in node 1, init new swarm with new ip docker swarm init defaultaddrpool 10.1.0.016 defaultaddrpoolmasklength 24 # in node 1, get new manager token docker swarm jointoken manager # in node 2 and node 3, join node 1 with new token docker swarm join token XXXXX YOUR_NEW_NODE1_IP2377 雙管齊下 如果大家同想要修定單機及Swarm的網段，還要留意有一個特別的網段docker_gwbridge。它雖然是Swarm的附帶產物，但它則是受單機的網段控制。也就是，如果大家有需要同時修改單機及Swarm的網段，則需要手動刪除Swarm及docker_gwbridge 在每個節點先刪掉舊有的Swarm及docker_gwbridge，並關掉docker docker swarm leave force docker network rm docker_gwbridge 在每個節點為docker_gwbridge修改設定，然後重起docker # vim etcdockerdaemon.json quot;defaultaddresspoolsquot; quot;basequot; quot;172.17.0.016quot;, quot;sizequot; 24 然後像前述一樣，重起Swarm。