Docker Swarm上篇已把服務搭建起來並透過指令快速指定Nginx來執行多容,這次在針對簡單實用功能進行示範:
擴展縮容
Scaling本身概念簡單,也是雲端能帶來的其中一項價值所需,當回應需求服務數量或連線流量過大時,能透過擴展機制一次啟動多個相應的服務同時處理需求回應與因應流量,直到流量或需求恢復正常,就可以透過縮容來減少服務數量,以節省主機成本。
–replicas
代表目前要啟動2
個Container來運行我的Nginx服務。擴增
透過docker service scale hello-a=5
就可以把容器數量從2
新增成5
來應付更多的流量。縮容
只需要透過docker service scale gyhello=2
來降低數量即可。
–name
用來定義此服務的名稱,也可在之後當成DNS給其他服務做使用。
-p 8080:80
則是把容器裡的80連接埠映射到宿主機上的8080連接埠。
docker service ps gyhello
docker service scale gyhello=5
docker service ps gyhello
docker service scale gyhello=2
docker service ps gyhello
負載平衡
當流量進到Docker Swarm的服務中,會透過像輪詢(Round Robin
)的機制去把進來的流量做分流,也就是輪流把流量送到各服務去,舉例第一個進來給A容器,第二個進來給B容器,第三個進來再給A,以此類推...
iptables -L -t nat
補充一下鳥哥教學
- filter是流量進到宿主機本身來決定是否Accept or Drop or Forward的方式。
- NAT流量本身跟此台宿主機並無直接關係,主要作為來源與目的IP & Port間轉至後端容器主機。
- Mangle屬特殊表格,會去標記某些規格並改寫封包。
下面那條規則可以發現流量被導入到172.18.0.2:8080這邊
用ifconfig
查看目前網路介面可以發現172.18.0.2與docker_gwbridge
網路介面相關聯,透過Node建立Container
後在與容器建立連線,故節點中涵蓋一組容器IP:172.18.0.2
docker network inspect docker_gwbridge
這裡有一個被隱藏的Container叫ingress-sbox,看起來流量是先進入此Container後再把流量分配到真正的Service
自測一下Nginx服務是否正常
因為我的Docker是在GCE上建立,負載平衡服務就地取材Google Load Balancer做示範
選擇TCP類型負載平衡,因為我等等示範的Nginx網站是8080自訂連接埠
測試無須高可用,選擇單一區域即可
後端集區我把本次的兩台Docker宿主機器拉進來關連到此負載平衡服務上
因為是8080非原來綁定的防火牆開通規則中,都是網站服務所以我把8080綁定到原來80的網站進入規則中,最後只要回頭檢視GCE上的防火牆是否有更新即可
測試後端的健康狀態,暫時初先偵錯後台有錯誤警示在本次測試先行忽略,並記錄此連線URL IP即可
透過外部 http://34.96.140.94:8080 並透過無痕瀏覽模擬不同的Session
檢視docker Service Log的確就有看到分別不同的宿主機內的Docker來做回應以達到簡單的負載平衡的功能驗證作用
最後補充一下Docker Swarm故障排除時能夠幫助到的Log紀錄檢視,可以參考Docker Swarm 進階實戰 (2)