Skip to content

Docker Swarm 進階實戰 (1)

  • Ops
tags: docker, devops

Docker Swarm進階實戰(1)

容器的更新

在不移除及重啟容器的情況下更新,從以下指令選項可以知道,container update旨在控制和限縮該容器的資源

另外要清楚的是我們透過docker run執行一個容器,其狀態就只有RunningShotdown兩種,如果出了差錯,此容器不會也不該有任何操作可以重新建立自己

Service的更新

  1. 再來看service update的選項,很明顯比容器更還多出許多操作,因為swarm service存在的目的就是要能在不影響服務的情況下取代(replace)、重建recreate容器

  2. swarm mode也是利用這種方式,逐一取代service底下執行的容器,達到滾動更新

  3. docker service的指令並非直接告訴系統去新增或刪除容器,而是新增了一連串的工作到佇列中,整個處理的流程帶有scale、rollback、failure mitigation等功能

  4. service更新的目標是limit downtime,也就是控制停機時間

  5. stack deploy會觸發service更新

  6. service更新會對nodes做rebalancing

滾動更新

  • Swarm service的分配原則
    • 預設分散至多個nodes上
    • 使用率較低的node優先配置
    • 使用者可自行定義此分配模式
  • 定義service分配的5種方式:
    • Service Constraints
    • Service Modes
    • Placement Preferences
    • Node Availability
    • Resource Requirements
  • 測試前準備事項
    • 準備3+個以上nodes組成的swarm
    • 至少要有1個manager跟2個worker
    • 清理運行中的docker程序及服務
    • 部署一個visualizer服務

1. Service Constraints

  • 對nodes加上label來限制(constraints)服務的配置
  • label可以是built-in或custom
    • built-in: node.<-- key -->
  • 可以在service新增/修改時add/remove label
  • hard requiremnts,亦即符合條件的node才配置服務
  • 一個service可加上多個限制條件
  • label可以是單個key,或key=value的篩選方式
  • 可以用==!=來篩選
  • label分成兩種:
    • node.labels標籤存在raft資料庫,只能由manager node來新增
    • engine.labels透過docker engine的設定檔daemon.json新增,須重開docker daemon
    • 通常是使用預設的node.labels,如果不方便對manager做動態設定,才會從engine.lables下手

範例:service只在manager配置

範例:新增node標籤

接著以key, value限制service配置

範例:在service更新時重設條件

範例:stack file

built-in label list

  • id
  • hostname
  • ip(e.g. 172.19.17.0/24)
  • role(manager|worker)
  • platform.os(linux|windows)
  • platform.arch(x86_64|386)
  • labels

2. Service mode

  • 預設是replicated,例如replica=10,docker swarm會執行10個container並盡可能分散到各個node上,但不能確保每個node都會配置到該task
  • Global是replica的相反,能確保one task on node
  • Global適用於host agents(monitoring, backup, proxy…)
  • 目前僅限於service create時設定

3. Placement Preferences

  • 是soft requirement
  • 目前只有spread這個策略
    • spread tasks among all values of a Label
    • 適用availablility zones, datacenters, racks, subnets > things where you want to spread workload out amongst various type of infrastructure
  • 可用於service create/update

範例: Lable all nodes with availability zone

根據這個Label加以分散

範例: Multi-level perferences 官方範例

使用--placement-pref增加限制

現在試著打破限制,使用新的條件增加覆蓋原有限制,測試soft requirement

stack file範例

4. Node Availability

每個節點會有一個有機狀態(admin-controlled state):

  • active: 執行現有的task,且可以指派新的task至該node(available)
  • pause: 常用在trouble shooting,現有的tasks持續執行(不保證如果有執行service update,相同的容器會依舊執行),但不能指派新的task至該node(not available)
  • drain: 維護時會用到,重新指派現有的tasks,且不能指派新的task至該node(not available)

有些文章會建議維護時可以把manager node設為drain,但實際上你會需要在manager node做管理的事情,例如有monitoring tools要跑(e.g. Portainer, swarm web GUI),或是需要與swarm溝通的logging engine,這些容器可不能被停掉(drain/pause),尤其這兩個狀態如果容器出了任何問題,沒辦法重新建立

建議不要用在manager node,而是用label的方式來限制(控制)manager tasks

範例指令

pause node2

drain node3,將其tasks指派到其他nodes

5. Resource Requirements

針對節點資源的條件限制,如cpu用量和記憶體大小,使用上要特別注意,例如運行database的service,資料如果持續增長到超過限制,該容器會被關閉重新排程

Reservation是一種promise,例如主機有4 CPU,如果把某個service的CPU資源設為4,其他service將無法取得任何CPU資源

docker run針對限制容器資源有許多設置選項,但Swarm中的docker service是另一回事,目前只有cpu和memory的選項可以操作

如果docker找不到足夠的資源來部署service,該service會進入Pending的狀態,然後持續kill、recreate的流程直到找到資源為止

範例指令

或是藉由剝奪資源來關閉service

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *