Service介紹
要在Docker引擎處於群集模式時部署image,需要創建一個Service(服務)。
創建一個服務時,指定要使用哪個容器鏡像,以及要在正在運行的容器中執行哪些命令。還可以為服務定義選項,包括:
- 群集所在的端口使服務在群集外部可用
- 一個覆蓋網絡,用於服務連接到群中的其他服務
- CPU和內存限制和保留
- 滾動更新策略
- 要在群集中運行的映像副本的數量
Services, tasks, and containers
當部署服務到 swarm,swarm manager接收你對服務期望狀態的定義。然后它為服務在 swarm 中的節點調度一個或多個副本任務。這些任務在 swarm 的節點上彼此獨立地運行。
例如假設你想負載均衡三個 HTTP 服務器實例。下面的圖表展示了三個 HTTP 服務器副本。
三個 HTTP 實例中的每一個是 swarm 中的一個任務。
容器是一個獨立的進程。在swarm模式模式中,每個task只調用一個容器。task類似於調度程序放置容器的“插槽”。一旦容器處於活動狀態,調度程序就會識別出任務處於運行狀態。如果容器未通過健康檢查或終止,則任務終止。
Tasks and scheduling
任務是 swarm 內調度的原子單位。當你通過創建或更新服務聲明一個期望狀態的服務,調度器通過調度任務來實現期望的狀態。例如,你指定一個服務始終保持運行三個HTTP 實例。調度器就創建三個任務。每個任務運行一個容器。容器是任務的實例化。如果一個 HTTP 容器之后出現故障停止,此任務被標志為失敗,調度器就會創建一個新的任務來生成一個新容器
任務是一個單向機制。它單向地執行一系統狀態,assigned,prepared, running 等。如果一個任務失敗了,調度器就會刪除這個任務和它的容器,然后創建一個新的任務來替換它。
下面的圖表顯示 swarm 模式是如何接收服務創建請求和調度任務到 worker 節點的。
Replicated and global services
有兩種類型的services部署,副本和全局
- Replicated services
你可以指定運行相同任務的數量。例如,你決定部署三個 HTTP 實例的副本,每個提供相同的內容。 - global services
在每個節點上運行一個相同的任務。不需要預先指定任務的數量。每次增加一個節點到 swarm 中,協調器就會創建一個任務,然后調度器把任務分配給新節點。
下圖表示用黃色表示擁有三個副本的 Replicated service,用灰色表示了一個global service
task 狀態
Docker允許你創建可以啟動任務的服務。服務是對所需狀態的描述,任務完成這項工作。在集群節點上按以下順序調度工作:
- 使用docker service create或UCP web UI或CLI創建服務。
- 請求被發送到Docker manager節點。
- Docker manager節點將服務安排在特定節點上運行。
- 每個服務可以啟動多個任務。
- 每個任務都有一個生命周期,有像NEW、PENDING和COMPLETE這樣的狀態。
任務是運行一次直至完成的執行單元。當一個任務停止時,它不會再次執行,但是一個新的任務可能會取而代之。
任務在許多狀態中前進,直到它們完成或失敗。任務在新狀態中初始化。任務通過許多狀態向前推進,而它的狀態不會后退。例如,任務永遠不會從COMPLETE變為RUNNING。
task的生命周期
NEW 任務在初始化狀態
PENDING 正在分配任務所用的資源
ASSIGNED Docker分配任務給節點
ACCEPTED 任務被工作節點接受。如果工作節點拒接任務,狀態將會轉變成REJECTED
PREPARING Docker正在准備任務
STARTING Docker正在開啟任務
RUNNING 任務正在執行
COMPLETE 任務結束,不帶錯誤代碼
FAILED 任務結束,帶着錯誤代碼
SHUTDOWN Docker請求任務關閉
REJECTED 工作節點拒絕任務
ORPHANED 節點宕機時間太長
REMOVE 該任務不是終端,但相關服務已被刪除或縮小
查看task狀態
運行docker service ps
```script
$ docker service ps webserver
ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
owsz0yp6z375 webserver.1 nginx UbuntuVM Running Running 44 seconds ago
j91iahr8s74p \_ webserver.1 nginx UbuntuVM Shutdown Failed 50 seconds ago "No such container: webserver.…"
7dyaszg13mw2 \_ webserver.1 nginx UbuntuVM Shutdown Failed 5 hours ago
```
操作
部署一個Service到swarm
-
執行下面的命令
[root@localhost ~]# docker service create --replicas 1 --name helloworld alpine ping www.baidu.com 7k5nx2b4zj8at0aohqfj6lcqw overall progress: 1 out of 1 tasks 1/1: running [==================================================>] verify: Service converged
- docker service create 創建服務
- --name service的名字
- --replicas指定一個service有幾個實例運行
-
查看運行的service
[root@localhost ~]# docker service list ID NAME MODE REPLICAS IMAGE PORTS 7k5nx2b4zj8a helloworld replicated 1/1 alpine:latest
查看service的詳細信息
```script
[root@localhost ~]# docker service inspect --pretty helloworld (or ServiceID)
ID: 7k5nx2b4zj8at0aohqfj6lcqw
Name: helloworld
Service Mode: Replicated
Replicas: 1
Placement:
UpdateConfig:
Parallelism: 1
On failure: pause
Monitoring Period: 5s
Max failure ratio: 0
Update order: stop-first
RollbackConfig:
Parallelism: 1
On failure: pause
Monitoring Period: 5s
Max failure ratio: 0
Rollback order: stop-first
ContainerSpec:
Image: alpine:latest@sha256:769fddc7cc2f0a1c35abb2f91432e8beecf83916c421420e6a6da9f8975464b6
Args: ping www.baidu.com
Init: false
Resources:
Endpoint Mode: vip
```
-
以json格式返回service的詳細信息
[root@localhost ~]# docker service inspect 7k5nx2b4zj8a [ { "ID": "7k5nx2b4zj8at0aohqfj6lcqw", "Version": { "Index": 16 }, "CreatedAt": "2019-06-08T12:21:18.255252358Z", "UpdatedAt": "2019-06-08T12:21:18.255252358Z", "Spec": { "Name": "helloworld", "Labels": {}, "TaskTemplate": { "ContainerSpec": { "Image": "alpine:latest@sha256:769fddc7cc2f0a1c35abb2f91432e8beecf83916c421420e6a6da9f8975464b6", "Args": [ "ping", "www.baidu.com" ], "Init": false, "StopGracePeriod": 10000000000, "DNSConfig": {}, "Isolation": "default" }, "Resources": { "Limits": {}, "Reservations": {} }, "RestartPolicy": { "Condition": "any", "Delay": 5000000000, "MaxAttempts": 0 }, "Placement": { "Platforms": [ { "Architecture": "amd64", "OS": "linux" }, { "OS": "linux" }, { "OS": "linux" }, { "Architecture": "arm64", "OS": "linux" }, { "Architecture": "386", "OS": "linux" }, { "Architecture": "ppc64le", "OS": "linux" }, { "Architecture": "s390x", "OS": "linux" } ] }, "ForceUpdate": 0, "Runtime": "container" }, "Mode": { "Replicated": { "Replicas": 1 } }, "UpdateConfig": { "Parallelism": 1, "FailureAction": "pause", "Monitor": 5000000000, "MaxFailureRatio": 0, "Order": "stop-first" }, "RollbackConfig": { "Parallelism": 1, "FailureAction": "pause", "Monitor": 5000000000, "MaxFailureRatio": 0, "Order": "stop-first" }, "EndpointSpec": { "Mode": "vip" } }, "Endpoint": { "Spec": {} } } ]
-
查看Service在哪些節點運行
[root@localhost ~]# docker service ps helloworld ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS w8gx7yw2j0yu helloworld.1 alpine:latest localhost.localdomain Running Running 12 minutes ago 6ooy7juh1wqi \_ helloworld.1 alpine:latest localhost.localdomain Shutdown Rejected 12 minutes ago "No such image: alpine:latest@…" 34iewe90umel \_ helloworld.1 alpine:latest localhost.localdomain Shutdown Rejected 13 minutes ago "No such image: alpine:latest@…" vyvdbph10jg3 \_ helloworld.1 alpine:latest localhost.localdomain Shutdown Rejected 14 minutes ago "No such image: alpine:latest@…" 1mkb9fdpbnnx \_ helloworld.1 alpine:latest localhost.localdomain Shutdown Rejected 14 minutes ago "No such image: alpine:latest@…" 【注意】由於沒有更改主機名,所以在NODE列里無法區分主機,一定要設置合適的主機名,以便於區分。
-
在任務節點上運行docker ps,可以查看關於任務容器的詳細信息
[root@localhost harbor]# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d7f574d9350b alpine:latest "ping www.baidu.com" 23 minutes ago Up 23 minutes helloworld.1.w8gx7yw2j0yuybx0v1dd165vb
在集群中擴展服務
將service部署到集群中后,可以通過命令行擴展service中的容器數量。在service中運行的容器稱為“tasks”(任務)
-
將helloworld service運行的任務擴展為5個
[root@localhost harbor]# docker service scale helloworld=5 helloworld scaled to 5 overall progress: 5 out of 5 tasks 1/5: running [==================================================>] 2/5: running [==================================================>] 3/5: running [==================================================>] 4/5: running [==================================================>] 5/5: running [==================================================>] verify: Service converged [root@localhost harbor]#
-
查看更新后的service 列表
[root@localhost harbor]# docker service ps helloworld ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS w8gx7yw2j0yu helloworld.1 alpine:latest node1 Running Running 34 minutes ago 6ooy7juh1wqi \_ helloworld.1 alpine:latest node1 Shutdown Rejected 34 minutes ago "No such image: alpine:latest@…" 34iewe90umel \_ helloworld.1 alpine:latest node1 Shutdown Rejected 35 minutes ago "No such image: alpine:latest@…" vyvdbph10jg3 \_ helloworld.1 alpine:latest node1 Shutdown Rejected 35 minutes ago "No such image: alpine:latest@…" 1mkb9fdpbnnx \_ helloworld.1 alpine:latest node1 Shutdown Rejected 36 minutes ago "No such image: alpine:latest@…" w44j1ygrmi7s helloworld.2 alpine:latest node2 Running Running 2 minutes ago chfthbqpj178 helloworld.3 alpine:latest node2 Running Running 2 minutes ago v55w9i8xdppb helloworld.4 alpine:latest node1 Running Running 2 minutes ago 3wmd93u5gsjh helloworld.5 alpine:latest node2 Running Running 2 minutes ago
刪除Service
```script
[root@localhost harbor]# docker service rm helloworld
helloworld
[root@localhost harbor]# docker service list
ID NAME MODE REPLICAS IMAGE PORTS
[root@localhost harbor]#
```
注意
即使service不在存在,容器也需要幾秒鍾來清理
Service滾動更新
在上面的步驟中擴展了Service中tasks的數量,下面將部署一個redis 3.0.6,通過滾動更新把redis更新為3.0.7
-
部署一個redis3.0.6集群,並為集群配置10秒的更新延遲
[root@localhost harbor]# docker service create --replicas 3 --name redis --update-delay 10s redis:3.0.6 50gtthzgzwmqjkpubutfsgnu6 overall progress: 3 out of 3 tasks 1/3: running [==================================================>] 2/3: running [==================================================>] 3/3: running [==================================================>] verify: Service converged
2.--update-delay: 更新服務任務(Task)執行間隔 默認情況下,調度程序每次更新一個任務。可以設置--update-parallelism 來調整調度器同時更新任務的最大數量。
默認情況下,當對單個任務的更新結束,調度程序才會對另一個任務進行更新,直到所有的任務都更新為止。如果在更新任務期間失敗,調度程序將暫停更新。可以使用--update-failure-action 來控制docker service create or docker service update執行失敗后的行為
-
查看redis service的詳細信息
[root@localhost harbor]# docker service inspect --pretty redis ID: 50gtthzgzwmqjkpubutfsgnu6 Name: redis Service Mode: Replicated Replicas: 3 Placement: UpdateConfig: Parallelism: 1 Delay: 10s On failure: pause Monitoring Period: 5s Max failure ratio: 0 Update order: stop-first RollbackConfig: Parallelism: 1 On failure: pause Monitoring Period: 5s Max failure ratio: 0 Rollback order: stop-first ContainerSpec: Image: redis:3.0.6@sha256:6a692a76c2081888b589e26e6ec835743119fe453d67ecf03df7de5b73d69842 Init: false Resources: Endpoint Mode: vip
-
現在更新redis容器鏡像。swarm manager將根據updateconfig策略對節點應用進行更新
[root@node1 ~]# docker service update --image redis:3.0.7 redis redis overall progress: 3 out of 3 tasks 1/3: running [==================================================>] 2/3: running [==================================================>] 3/3: running [==================================================>] verify: Service converged
滾動更新步驟
- 停止第一個任務(容器)
- 添加更新調度到此任務
- 啟動更新后的容器
- 如果任務執行結果為RUNNING, 等待 delay 設置的時間后開始下一個任務
- 如果有任意一個任務失敗,停止此次更新
-
查看更新后的信息
[root@node1 ~]# docker service inspect --pretty redis ID: 50gtthzgzwmqjkpubutfsgnu6 Name: redis Service Mode: Replicated Replicas: 3 Placement: UpdateConfig: Parallelism: 1 Delay: 10s On failure: pause Monitoring Period: 5s Max failure ratio: 0 Update order: stop-first RollbackConfig: Parallelism: 1 On failure: pause Monitoring Period: 5s Max failure ratio: 0 Rollback order: stop-first ContainerSpec: Image: redis:3.0.7@sha256:730b765df9fe96af414da64a2b67f3a5f70b8fd13a31e5096fee4807ed802e20 Init: false Resources: Endpoint Mode: vip
如果顯示下面的內容,表示由於更新失敗而暫停
$ docker service inspect --pretty redis
ID: 0u6a4s31ybk7yw2wyvtikmu50
Name: redis
...snip...
Update status:
State: paused
Started: 11 seconds ago
Message: update paused due to failure or early termination of task 9p7ith557h8ndf0ui9s0q951b
...snip...
重新啟動更新
docker service update redis
-
更新后的狀態
[root@node1 ~]# docker service ps redis ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS 2au9etgoryzy redis.1 redis:3.0.7 node1 Running Running 23 minutes ago daxio9w01x6f \_ redis.1 redis:3.0.6 node2 Shutdown Shutdown 22 minutes ago t5na1flecwgb redis.2 redis:3.0.7 node1 Running Running 23 minutes ago ny2ia69mibek \_ redis.2 redis:3.0.6 node2 Shutdown Shutdown 22 minutes ago 355xlpbugpt2 redis.3 redis:3.0.7 node1 Running Running 23 minutes ago 305huk42qp07 \_ redis.3 redis:3.0.6 node1 Shutdown Shutdown 8 hours ago [root@node1 ~]#
更新service
當更新service時,Docker將停止其容器並使用新的配置重新啟動它們。
Service configuration details
Configure the runtime environment
可以為容器中的運行環境配置以下選項
--env 環境變量
-workdir 容器內的工作目錄
--user 用戶名或UID
下面的服務將容器環境變量$MYVAR設置為myvaule,從/tmp/目錄運行,並作為root用戶運行
[root@node1 ~]# docker service create --name helloworld --env MYVAR=myvalue --workdir /tmp --user root alpine ping docker.com
更新現有service運行的命令
要更新現有服務運行的命令,可以使用——args標志
[root@node1 ~]# docker service update --args "ping baidu.com" helloworld
helloworld
overall progress: 1 out of 1 tasks
1/1: running [==================================================>]
verify: Service converged
[root@node1 ~]#
指定service應該使用的image版本
創建一個service而沒有指定要使用的image版本時,該service將使用帶有最新標記的版本。可以通過幾種不同的方式強制服務使用特定版本的映像。
$ docker service create --name="myservice" ubuntu:16.04
控制service的位置
swarm service提供了幾種不同的方式來控制service在不同的節點上的規模和位置
- 可以指定服務需要運行特定數量的副本,還是應該在每個工作節點上全局運行。參考 Replicated and global services
- 可以配置service的CPU或內存需求,而service只在能夠滿足這些需求的節點上運行。
- Placement constraints (位置約束)允許將service配置為僅在具有特定(任意)元數據的節點上運行,如果不存在適當的節點,則會導致部署失敗。
- Placement preferences(位置偏好) 允許對每個節點應用具有范圍值的任意標簽,使用算法將service的task分散到這些節點上。目前唯一支持的算法是spread,它試圖將task均勻地放置。例如,如果你每個節點標簽與標簽架有一個值從1到10,然后指定一個位置偏好的機架,然后service task盡可能均勻地放置在所有節點標簽架,在其他位置限制,位置偏好,和其他特定於節點的限制。
與約束不同,位置偏好是最佳選擇,如果沒有節點能夠滿足該首選項,service不會部署失敗。如果為service指定了一個位置偏好,當swarm manager決定哪些節點應該運行service task時,匹配該位置偏好的節點會優先匹配。
Replicated or global services
群集模式有兩種類型的服務:復制服務和全局服務。對於復制的服務,可以指定群集管理器要調度到可用節點上的復制任務的數量。對於全局服務,調度程序在每個可用節點上放置一個任務,以滿足服務的位置約束和資源需求。
您可以使用—mode控制服務的類型。默認是復制類型。對於復制的服務,可以指定要使用——replicas啟動的復制任務的數量。例如,要啟動具有3個復制任務的復制nginx服務:
$ docker service create \
--name my_web \
--replicas 3 \
nginx
要在每個可用節點上啟動全局service,請將模式全局傳遞給docker service create。每當一個新節點可用時,調度程序就在新節點上為全局服務放置一個task。例如,啟動一個service,在集群的每個節點上運行alpine:
$ docker service create \
--name myservice \
--mode global \
alpine top
服務約束允許將service部署到滿足節點標准的節點上。您可以基於節點屬性和元數據或引擎元數據對服務應用約束。有關約束的更多信息,請參閱docker service create CLI reference.
為服務保留內存或cpu
要為服務保留給定數量的內存或cpu數量,請使用--reserve-memory或--reserve-cpu標志。如果沒有可用節點能夠滿足需求(例如,如果您請求4個cpu,而集群中沒有節點具有4個cpu),則服務將保持掛起狀態,直到有合適的節點可用來運行其任務。
內存不足異常(OOME)
如果服務試圖使用超過群集節點可用內存的內存,您可能會遇到內存不足異常(OOME),並且容器(或Docker守護進程)可能被內核OOM殺手殺死。要防止這種情況發生,請確保您的應用程序在內存充足的主機上運行,並了解內存耗盡的風險。
Placement constraints(位置約束)
使用位置約束來控制可以分配給服務的節點。在下面的示例中,service只在標簽區域設置為east的節點上運行。如果沒有適當標記的節點可用,任務將在Pending中等待,直到它們可用為止。--constraint使用 ==或!=操作符。對於復制的服務,可能所有服務都運行在同一個節點上,或者每個節點只運行一個副本,或者一些節點不運行任何副本。對於全局服務,服務在滿足位置約束和資源需求的每個節點上運行。
$ docker service create \
--name my-nginx \
--replicas 5 \
--constraint node.labels.region==east \
nginx
還可以將位置約束、位置偏好和CPU/內存約束一起使用,參考 docker service create CLI reference.
Placement preferences(位置偏好)
由於位置限制限制了服務可以運行的節點,位置首選項嘗試以算法的方式將任務放在適當的節點上(目前,僅支持平均分布)。例如,如果為每個節點分配一個機架標簽,可以設置一個位置偏好,以便通過值將服務均勻地分布到具有機架標簽的節點上。這樣,如果您丟失了機架,服務仍然在其他機架上的節點上運行。
位置偏好不是嚴格執行的。如果沒有節點具有在位置偏好中指定的標簽,則服務將像未設置首選項一樣部署。
對於全局服務,位置偏好將被忽略。
下面的示例設置一個偏好,根據datacenter標簽的值將部署分散到各個節點。如果一些節點具有datacenter=us-east,而其他節點具有datacenter=us-west,則服務將盡可能均勻地部署在這兩組節點上。
$ docker service create \
--replicas 9 \
--name redis_2 \
--placement-pref 'spread=node.labels.datacenter' \
redis:3.0.6
缺少或空標簽
缺少標簽的節點仍然接收任務分配。作為一個組,這些節點接收任務的比例與其他節點相同。在某種意義上,缺少標簽與標簽上附加空值是一樣的。如果服務只在節點上運行,而標簽用於spread首選項,則偏好應與約束相結合。
您可以指定多個位置偏好,並按遇到它們的順序處理它們。下面的示例設置具有多個位置偏好的服務。任務首先分布在各個數據中心上,然后分布在機架上(由各自的標簽表示):
$ docker service create \
--replicas 9 \
--name redis_2 \
--placement-pref 'spread=node.labels.datacenter' \
--placement-pref 'spread=node.labels.rack' \
redis:3.0.6
這個圖說明了位置偏好是如何工作的
用docker service update更新service時,--placement-pref-add在所有現有的位置偏好之后附加一個新的位置偏好。 --placement-pref-rm刪除與參數匹配的位置偏好標簽
配置服務的更新
當你創建一個service時,可以指定service滾動更新的方式,
--update-delay 配置更新service task的時間間隔。時間可以用T表示,秒用Ts表示,分鍾用Tm表示,小時用Th表示,10m30s表示10分鍾30秒
--update-parallelism 調整調度器同時更新任務的最大數量。當對單個任務的更新結束,調度程序才會對另一個任務進行更新,直到所有的任務都更新為止。如果在更新任務期間失敗,調度程序將暫停更新。可以使用--update-failure-action 來控制docker service create or docker service update執行失敗后的行為
在下面的示例中,調度程序一次最多應用兩個副本的更新。當更新后的任務返回運行或失敗時,調度程序會等待10秒,然后停止下一個要更新的任務:
$ docker service create \
--replicas 10 \
--name my_web \
--update-delay 10s \
--update-parallelism 2 \
--update-failure-action continue \
alpine
--update-max-failure-ratio 在更新service期間,多少task更新失敗后,判定此次更新為失敗。比如,--update-max-failure-ratio 0.1 --update-failure-action pause 表示在10%的更新task失敗后,更新將暫停。
如果task沒有啟動,或者在--update-monitor 指定的監視期內停止運行,則認為單個task更新失敗。--update-monitor 默認值是30s,這意味着在啟動后的前30秒內失敗的任務將計入服務更新失敗,在此之后的失敗將不計算在內。
回滾到服務的前一個版本
如果服務的更新版本沒有按預期運行,可以使用 docker service update的--rollback回滾到service的前一個版本。
使用--rollback時可以和--update-delay 0s結合,表示執行回滾時不存在時間間隔
$ docker service update \
--rollback \
--update-delay 0s
my_web
在Docker 17.04或更高版本中,如果服務更新未能部署,可以配置服務自動回滾。
在Docker 17.04或更高版本中,手動回滾是在服務器端而不是客戶端處理的.這允許手動啟動回滾來遵守新的回滾參數。客戶機是版本敏感的,所以它仍然對舊守護進程使用舊方法。(理解不清楚)
更新失敗自動回滾
您可以這樣配置服務:如果對服務的更新導致重新部署失敗,服務可以自動回滾到以前的配置。這有助於保護服務可用性。您可以在服務創建或更新時設置以下一個或多個標志。如果沒有設置值,則使用默認值。
參數 | 默認 | 描述 |
---|---|---|
--rollback-delay | 0s | 在回滾一個任務之后,在回滾下一個任務之前需要等待的時間。值0表示在部署第一個回滾任務之后立即回滾第二個任務。 |
--rollback-failure-action | pause | 當任務無法回滾時,[pause]或[continue]回滾其他任務。 |
--rollback-max-failure-ratio | 0 | 在回滾期間容忍的失敗率,指定為0到1之間的浮點數。例如,給定5個任務,失敗率為0.2可以容忍一個任務無法回滾。值0表示不能容忍任何失敗,值1表示可以容忍任意數量的失敗。 |
--rollback-monitor | 5s | 每次任務回滾后監視期的持續時間。如果任務在此時間段結束之前停止,則回滾將視為失敗。 |
--rollback-parallelism | 1 | 並行回滾的最大任務數。默認情況下,一次回滾一個任務。0將並行回滾所有任務。 |
下面的示例配置一個redis服務,以便在docker服務更新未能部署時自動回滾。兩個任務可以並行回滾。在回滾之后,將對任務進行20秒的監視,以確保它們不會退出,並且允許最大故障率為20%。--rollback-delay and --rollback-failure-action使用默認值
$ docker service create --name=my_redis \
--replicas=5 \
--rollback-parallelism=2 \
--rollback-monitor=20s \
--rollback-max-failure-ratio=.2 \
redis:latest
service 訪問卷或綁定掛載
為了獲得最佳性能和可移植性,應該避免直接將重要數據寫入容器的可寫層,而是使用數據量或綁定掛載。這一原則也適用於服務。
您可以為swarm中的service創建兩種類型的掛載,volume mounts or bind mounts。無論使用哪種類型的掛載,在創建service時使用--mount配置它,或者更新現有的service時使用--mount-add或--mount-rm。如果不指定類型,則默認為數據卷
數據卷
數據卷是獨立於容器而存在的存儲。swarm service數據卷的生命周期類似於容器下卷的生命周期。卷比task和service聲明周期長,因此它們的刪除必須單獨管理。可以在部署service之前創建卷,或者如果在調度任務時某個特定主機上不存在卷,則根據service上的卷規范自動創建卷。
service使用已有的數據卷--mount
$ docker service create \
--mount src=<VOLUME-NAME>,dst=<CONTAINER-PATH> \
--name myservice \
<IMAGE>
如果將任務調度到特定主機時,不存在具有相同
$ docker service create \
--mount type=volume,src=<VOLUME-NAME>,dst=<CONTAINER-PATH>,volume-driver=<DRIVER>,volume-opt=<KEY0>=<VALUE0>,volume-opt=<KEY1>=<VALUE1>
--name myservice \
<IMAGE>
有關如何創建數據卷和卷驅動程序的更多信息,參考use volume。
Bind mounts
Bind mounts是來自調度程序為task部署容器的主機的文件系統路徑。Docker將路徑掛載到容器中。在swarm初始化task的容器之前,文件系統路徑必須存在。
下面的示例顯示綁定掛載語法:
- 掛載讀寫綁定:
$ docker service create \
--mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH> \
--name myservice \
<IMAGE>
- 掛載只讀綁定:
$ docker service create \
--mount type=bind,src=<HOST-PATH>,dst=<CONTAINER-PATH>,readonly \
--name myservice \
<IMAGE>
重要提示:綁定掛載雖然很有用,但它們也可能導致問題。在大多數情況下,建議您將應用程序架構設計為不需要從主機掛載路徑。主要風險包括:
- 如果將主機路徑綁定到service的容器中,則該路徑必須存在於集群每個節點上。Docker swarm模式調度程序可以在任何滿足資源可用性需求並滿足您指定的所有約束和位置偏好的機器上調度容器。
- 如果正在運行的服務容器變得不健康或無法訪問,Docker swarm模式調度程序可以在任何時候重新調度它們。
主機綁定掛載不可移植。當使用綁定掛載時,不能保證應用程序在開發中以與在生產中相同的方式運行。
Create services using templates
略
參考
https://docs.docker.com/engine/swarm/services/
https://my.oschina.net/u/915811/blog/1593855
https://www.cnblogs.com/wanghui-garcia/p/10240182.html