このチュートリアルでは、Alibaba Cloud上でコンテナを扱う際にDocker Composeを使用して実践的な経験を積むことに焦点を当てています。

本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。

#Deploy: update_config: parallelism
並列処理は、サービスの更新をどのくらいの速さで行うかを設定します。新しく起動されたコンテナは、できるだけ早く起動されます。新しいコンテナはこの update_config 設定を使用しません。

したがって、これでテストするには、UPDATEの並列処理を観察できるように、すでに実行されているコンテナのセットが必要です。

まず、parallelism = 1 (デフォルト)とします。

docker-compose.ymlに以下のように追加します。

nano docker-compose.yml

version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 600

    deploy:
      replicas: 6

      update_config:
        parallelism: 1

実行します。

docker stack rm mystack
docker stack deploy -c docker-compose.yml  mystack
docker ps -a

そして約3秒後には、6つのコンテナが実行されるようになりました。この最初に実行した docker stack deploy は並列化オプションを無視しています。

残念ながら、docker stack deployを再実行しても、並列化オプションは動作していません。Dockerはあまりにも賢いので、docker-compose.ymlファイルを読み込んで、何も変更されていないことを確認し、mystack内のコンテナを更新しません。

これを証明するために、別のコンソールコマンドセッションを起動して、docker eventsを実行してみましょう。

元のシェルに戻り、3回実行します。

docker stack deploy -c docker-compose.yml  mystack

他のコンソール出力を観察してください。

期待される出力 .

2018-11-08T12:48:34.385699607+02:00 service update qdzqiek7c59mkxznatszsh13j (name=mystack_alpine)
2018-11-08T12:48:37.423780596+02:00 service update qdzqiek7c59mkxznatszsh13j (name=mystack_alpine)
2018-11-08T12:48:39.804717121+02:00 service update qdzqiek7c59mkxznatszsh13j (name=mystack_alpine)

サービスは3回に分けて更新されますが、停止することもなければ新鮮なコンテナを起動することもありません。

そのため、強制的に更新するには docker-compose.yml に変更を加える必要があります。

最も簡単な変更：ちょうどsleep600の後ろに数字を追加します。

これを実行します。

docker stack deploy -c docker-compose.yml  mystack

ここには表示されていませんが、他のコンソール出力を観察してみてください。

新しいコンテナが作成され、古いコンテナが削除されています。

docker ps -a を実行すると、上部に新しいコンテナが表示され、下に終了したものが表示されます。sleepを6001に変更したことがわかります。

 CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                       PORTS               NAMES
bafa8e4e1d62        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.5.mtw5rzfpyd6dwnh9mez7p7hlk
a80b531eff59        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.6.nl9culv3otymevgjufamkkwld
fa45c52b0825        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.1.oe2d85c55uf1qlbvv1pozcsgx
2565cfbda1db        alpine:3.8          "sleep 6001"        21 seconds ago      Up 5 seconds                                     mystack_alpine.4.5zaqrvwv32ou8vmdvnbu21qtn
b69ceeaf69a1        alpine:3.8          "sleep 6001"        21 seconds ago      Up 5 seconds                                     mystack_alpine.2.utc38k1pg124zx65ae1s8qo5g
9669904d0bb1        alpine:3.8          "sleep 6001"        21 seconds ago      Up 4 seconds                                     mystack_alpine.3.zbltrdwmk0omxtkywuwhlw9ub
dc8566cc12ae        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.3.bi13jj6v7f2s3b31yc6k9dmf0
9d385bfd3565        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.6.g8w5a0fe0ufcum2y2lhd0i1dq
58f14d78f436        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.1.zotzhrpqblzzyo62urafwgzcs
2090bb37bb31        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.2.loezk57p62tkfohgzbh1tc1j8
c8df0b31e188        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.4.619ms1rkhar35un6x4g5ulc3h
c85a0f2db1e0        alpine:3.8          "sleep 600"         9 minutes ago       Exited (137) 8 seconds ago                       mystack_alpine.5.odw21g73i1p62s90lpj1936xv

私たちはコンテナの更新が起こっているのを目撃しただけです。しかし、チュートリアルのこの部分の目的は、並列処理がどのように動作するかを示すことです。

他のコンソールで前のdocker eventsコマンドを停止し、これを入力します。

docker events  --filter event=create  --filter event=kill

docker-compose.ymlのスリープ時間を任意の桁数に変更します。

再実行：

docker stack deploy -c docker-compose.yml  mystack

最初のコンソールでdocker ps -aを繰り返し実行します。数分後に更新処理が完了します。

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                            PORTS               NAMES
84da4828fea3        alpine:3.8          "sleep 6002"        3 seconds ago        Created                                               mystack_alpine.4.ludkp9e9ec63tf27n05j2h8rt
99d63687086c        alpine:3.8          "sleep 6002"        18 seconds ago       Up 3 seconds                                          mystack_alpine.1.zbfm2q2403wg5f0626dlodab4
5d4ac8f2ae15        alpine:3.8          "sleep 6002"        32 seconds ago       Up 17 seconds                                         mystack_alpine.5.oadzbajbcr6l1rms28kb23xux
350971f0734e        alpine:3.8          "sleep 6002"        47 seconds ago       Up 32 seconds                                         mystack_alpine.2.lxggijot4518tj0xl3bi36eay
95f6fcc3c898        alpine:3.8          "sleep 6002"        About a minute ago   Up 46 seconds                                         mystack_alpine.6.qgje7g5r7e7e24neuqiafip0g
960174cdab88        alpine:3.8          "sleep 6002"        About a minute ago   Up About a minute                                     mystack_alpine.3.v9zm2yipmvjzb673da8sbryh1

10-15秒ごとに約1つの新しいコンテナを取得します。これは並列処理 = 1 の場合に得られるものです。

2つ目のコンソール出力を見てみましょう: docker events

ご覧の通りです。1つの新しいコンテナが作成され、1つの古いコンテナが削除されました。

この更新処理を高速化するために、docker-compose.yml の並列処理を 3 に上げてみましょう。

nano docker-compose.yml

並列処理：3

再実行：

docker stack deploy -c docker-compose.yml  mystack

docker ps -aを実行すると、上に新しいコンテナが、下に退避したコンテナが表示されます。sleepを6003に変更したのを見てください。

すぐに上部に3つのコンテナが作成され、15秒後に残りの3つが作成されているのがわかります。

このように、完璧な理想は6つの並列性であることは間違いありません。6個すべてを一度に更新します。

残念ながら、これはそうではありません。更新に失敗した場合、6つの新しいコンテナが失敗し、6つの以前の完璧に動作していたコンテナがすべて終了してしまいます。

幸いなことに、max_failure_ratio と failure_action はこのような問題に対処します。このトピックについては次のセクションで詳しく説明します。

#Deploy：update_config：failure_ratioとfailure_action
この2つの設定を利用することで、更新に失敗したことによるダメージを軽減することができます。

failure_ratio specifies which percent failure to tolerate: Syntax: 0.1 means 10 percent.

failure_action: Specifies what to do if an update fails. continue, rollback, or pause (default: pause).

今はまだ以前のコンテナが稼働しています。このコンテナを 6 つの新しいコンテナに更新して、それぞれがすぐに失敗するようにします。

docker-compose.yml に以下を追加します。

nano docker-compose.yml

version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: exit 1

    deploy:
      replicas: 6

      update_config:

        parallelism: 1
        max_failure_ratio: 0
        failure_action: pause

コマンドは exit 1 - エラー応答コード 1 のexitであることを意味しています。

デフォルトのfailure_actionはpauseですが、ここでは含めています。

他のコンソールコマンドセッションを使って、docker eventsを実行してください。

これらの失敗したコンテナをデプロイします。

docker stack deploy -c docker-compose.yml  mystack

docker ps -a -aを実行すると、30秒後くらいにこのように表示されます。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
cbcaf8fce479        alpine:3.8          "exit 1"            6 seconds ago       Created                                 mystack_alpine.2.zvk1x6hevpt3x0q6aha0616sx
3ce0f3bca6c8        alpine:3.8          "exit 1"            12 seconds ago      Created                                 mystack_alpine.2.hyikxli7cwuk0xauaqw87epu0
4ae02b292f54        alpine:3.8          "exit 1"            18 seconds ago      Created                                 mystack_alpine.2.lseuovn0g4imn75q1eufnyfx9
1ea70f30f397        alpine:3.8          "exit 1"            24 seconds ago      Created                                 mystack_alpine.2.tfwagwvevh9vdxyne7cfy41fa
2eeef13d4240        alpine:3.8          "exit 1"            30 seconds ago      Created                                 mystack_alpine.2.n5qny1d5sbwah7fgsa83eabat
b926e22199d1        alpine:3.8          "sleep 6003"        21 minutes ago      Up 20 minutes                           mystack_alpine.5.w3ll2y30r1b75137fbbqak1rf
248f8ffe019e        alpine:3.8          "sleep 6003"        21 minutes ago      Up 20 minutes                           mystack_alpine.1.62dpe6cgrtmkercmn2bdlo3j3
815143b43f11        alpine:3.8          "sleep 6003"        21 minutes ago      Up 21 minutes                           mystack_alpine.4.enk3mweaht4zqre0jehm2nyn1
c13461b6f58c        alpine:3.8          "sleep 6003"        21 minutes ago      Up 21 minutes                           mystack_alpine.3.9jfg8kc1l0ps6km6hv5wlzddc
f2dc173cbf21        alpine:3.8          "sleep 6003"        21 minutes ago      Up 21 minutes                           mystack_alpine.6.8mo8t73z58jbf1e9vhvzjup53

リストの一番上に6つの新しいコンテナが作成されていますが、その下には6つの古いコンテナがまだ動いています。しかし、新しいコンテナは実行されていないので、作成された状態になっているだけです。

イベントコンソールを観察してみてください - Dockerは、これらの新しいコンテナを「実行中」にするために、継続的に破棄して再作成しています。明らかにpauseでは一時停止しません。

それらのコンテナをすべてクリーンアップします: ( prune はスタック rm が見逃したコンテナを削除します。それは残念ながら頻繁に起こります。)

docker stack rm mystack
docker container prune -f

Pauseが思ったように動作しません。failure_action: rollbackをテストしてみましょう。

failure_action: のロールバックをテストするためには、新しく始める必要があります。

1、6つの作業コンテナを作成します。
2、6つのexit = 1エラーコンテナを含むdocker-compose.ymlを作成します。
3、失敗のアクションをロールバックに設定します。
4、デプロイスタックを実行して結果を観察します。
次を使用してdocker-compose.ymlに追加します。

nano docker-compose.yml

version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 600

    deploy:
      replicas: 6

作業コンテナをデプロイします。

docker stack deploy -c docker-compose.yml  mystack

6つのエラーコンテナを作成します。以下を docker-compose.yml に追加します。

nano docker-compose.yml

version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: exit 1

    deploy:
      replicas: 6

      update_config:

        parallelism: 1
        max_failure_ratio: 0
        failure_action: rollback

エラーコンテナを展開します。

docker stack deploy -c docker-compose.yml  mystack

結果を観察する: docker ps -a を 30 秒程度繰り返し実行します。

最初の3つのコンテナを注意深く観察して、何が起こっているかを判断できるかどうかを確認します。

docker ps -a

最終的な結果はこんな感じです。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                        PORTS               NAMES
c2d1ae806906        alpine:3.8          "sleep 600"         25 seconds ago      Up 22 seconds                                     mystack_alpine.2.soht49wefpwm1nvm1gbl7ru1l
455a5907758a        alpine:3.8          "exit 1"            40 seconds ago      Created                                           mystack_alpine.2.yr0zkfu9n40s0rbezfhjtl6yu
3c254ba9a72b        alpine:3.8          "sleep 600"         2 minutes ago       Exited (137) 26 seconds ago                       mystack_alpine.2.04g1vrnoomagvv89aobbbzmxz
b635a1e52147        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.1.gibfdph75s0o46s5h3x96csm2
0ac32ac0ad34        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.3.oxs3mjm7vp3c6jbc1kj2kz990
33554d287fe9        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.5.ds3lra1qvr9y8e8b1xi2cn5c0
f381b1250167        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.4.t4gv1gor6aul3b53ei6pcxu5e
fd97395ba2ac        alpine:3.8          "sleep 600"         2 minutes ago       Up 2 minutes                                      mystack_alpine.6.n1nshrlnywqcrvn5u2x93nr10

まず、新しいコンテナを作成します。

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
455a5907758a        alpine:3.8          "exit 1"            7 seconds ago        Created                                 mystack_alpine.2.yr0zkfu9n40s0rbezfhjtl6yu

5秒後くらいに1つの古いコンテナが出てきます。

CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                       PORTS               NAMES
3c254ba9a72b        alpine:3.8          "sleep 600"         About a minute ago   Exited (137)

そして、Dockerは新しいコンテナが実行状態に移行できないと判断したので、docker-compose.ymlで以前の設定でコンテナを再作成/ロールバックします。

このコンテナは一番上の方に表示されています。ステータスを参照してください: up 22 seconds; it is working.

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                        PORTS               NAMES
c2d1ae806906        alpine:3.8          "sleep 600"         25 seconds ago      Up 22 seconds                                     mystack_alpine.2.soht49wefpwm1nvm1gbl7ru1l

ゆっくりと出力をスクロールして、コンピュータで同じことが起こったかどうかを確認してください。

ロールバックは素晴らしい働きをします。

結論：以下の設定は本番では便利です。

1、一度に1つのコンテナだけをアップデートします。
2、障害を許容しません。
3、失敗時、ロールバックします。

    update_config:

        parallelism: 1
        max_failure_ratio: 0
        failure_action: rollback

#Deploy: update_config: monitor
https://docs.docker.com/compose/compose-file/#update_config より

monitor:各タスク更新後に障害を監視する時間(ns|us|ms|s|m|h) (デフォルトは0s)。

ここでは演習はありませんが、この設定は重要です。

先ほど読んだように、コンテナの更新後に障害を監視するための時間です。

コンテナ内のアプリケーションは、Dockerが障害の有無をテストする前に十分な時間を持っていなければなりません。

デフォルトの継続時間の値である0秒は、実用的な目的には適していません。これは、コンテナが正常に起動することを確認するためにのみ有用です。

コンテナ内でWebサーバーを稼働させているとしましょう。さらに、1分間に1回のWebサイト訪問を想定してみましょう。そのため、モニターの設定を1分にするのは、おそらく頻度が高すぎるでしょう。その代わりに、少なくとも 5 分間に設定して、障害のテストをする前にクラッシュする機会を与えることができます。

あなたの職場のアプリケーションに適したモニター持続時間の値を決定する必要があります。

ヘルスチェックは、質問をするのと似ています。「can I ping it?」

これらの監視は、コンテナ全体がクラッシュするかどうかをテストします。これらのテストは、コンテナ内のアプリケーションが他のコンテナと連携しなければならない状況下でも動作するかどうかをテストします。

例えば、新しいApacheのバージョンをデプロイしたものの、必要なモジュールをすべてロードすることができない場合、ヘルスチェックのpingやテキストhtmlページのwgetsは完璧に動作しますが、php + Mysqlページを提供する必要がある瞬間にクラッシュしてしまいます。

そのため、新しく更新されたコンテナ内のアプリケーションを実行するのに十分な時間を与えてから、Dockerが失敗をテストできるようにしなければなりません。

私たちは、接続性だけでなく機能性もテストするヘルスチェックを開発したいと考えています。

そのようなヘルスチェックは、数秒以内に新しいコンテナが不健全であることを示すことができ、実際の本番の作業を処理できるようになる（そして失敗する）数分前になります。

#並行処理実験の出力
以下は、様々な並列処理の設定を試して集めたdockerのイベント出力です。( /tmp にイベントを出力し、その後そのファイルを操作しました)

2本のkillラインは、1つのコンテナ用です：signal 15、十分にすぐに死んでいない場合：signal9を送信します。

並行処理: 1

   cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:01:35.148583578+02:00 container create 8b51499
    2018-11-03T10:01:37.840231366+02:00 container kill be8f3715a
    2018-11-03T10:01:37.865611953+02:00 container kill be8f3715a
    2018-11-03T10:01:39.886188372+02:00 container create a38781a
    2018-11-03T10:01:42.572866743+02:00 container kill e498e5f5f
    2018-11-03T10:01:42.598606635+02:00 container kill e498e5f5f
    2018-11-03T10:01:44.423905486+02:00 container create 64ae4c0
    2018-11-03T10:01:47.123993008+02:00 container kill 914343611
    2018-11-03T10:01:47.146988704+02:00 container kill 914343611
    2018-11-03T10:01:48.972005129+02:00 container create b37cef5
    2018-11-03T10:01:51.642712373+02:00 container kill 92619e0a6
    2018-11-03T10:01:51.667003244+02:00 container kill 92619e0a6
    2018-11-03T10:01:53.497100262+02:00 container create 8a73470
    2018-11-03T10:01:56.163374613+02:00 container kill 420dc4d89
    2018-11-03T10:01:56.188237090+02:00 container kill 420dc4d89
    2018-11-03T10:01:58.000843644+02:00 container create 41b4480
    2018-11-03T10:02:00.699576981+02:00 container kill c8f4d973c
    2018-11-03T10:02:00.721565297+02:00 container kill c8f4d973

並行処理：２

cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:08:47.299682233+02:00 container create 6f1df52
    2018-11-03T10:08:47.567222566+02:00 container create ea9bf95
    2018-11-03T10:08:49.943237084+02:00 container kill 8b51499ad
    2018-11-03T10:08:49.958679991+02:00 container kill 64ae4c05c
    2018-11-03T10:08:49.977677725+02:00 container kill 8b51499ad
    2018-11-03T10:08:49.997521920+02:00 container kill 64ae4c05c
    2018-11-03T10:08:52.539334772+02:00 container create cdbbef8
    2018-11-03T10:08:52.812900162+02:00 container create 16e1af2
    2018-11-03T10:08:55.157361545+02:00 container kill b37cef51e
    2018-11-03T10:08:55.169221551+02:00 container kill 8a73470b2
    2018-11-03T10:08:55.193477357+02:00 container kill b37cef51e
    2018-11-03T10:08:55.207277169+02:00 container kill 8a73470b2
    2018-11-03T10:08:57.830146930+02:00 container create 0ab17e5
    2018-11-03T10:08:57.949710902+02:00 container create 9cc8547
    2018-11-03T10:09:00.233887111+02:00 container kill a38781a0f
    2018-11-03T10:09:00.257647812+02:00 container kill 41b4480ad
    2018-11-03T10:09:00.272834309+02:00 container kill a38781a0f
    2018-11-03T10:09:00.288598877+02:00 container kill 41b4480ad

並行処理：３

    cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:11:34.283896923+02:00 container create 8a0373b
    2018-11-03T10:11:34.583536405+02:00 container create 61cbe75
    2018-11-03T10:11:34.803563295+02:00 container create a2bd707
    2018-11-03T10:11:36.854815108+02:00 container kill cdbbef891
    2018-11-03T10:11:36.861978752+02:00 container kill 0ab17e57f
    2018-11-03T10:11:36.890035520+02:00 container kill ea9bf9502
    2018-11-03T10:11:36.899725135+02:00 container kill cdbbef891
    2018-11-03T10:11:36.905718703+02:00 container kill 0ab17e57f
    2018-11-03T10:11:36.922317316+02:00 container kill ea9bf9502
    2018-11-03T10:11:39.891013146+02:00 container create 7576427
    2018-11-03T10:11:40.238136177+02:00 container create a26d947
    2018-11-03T10:11:40.439589543+02:00 container create 53002e5
    2018-11-03T10:11:42.434787914+02:00 container kill 16e1af20f
    2018-11-03T10:11:42.445537379+02:00 container kill 9cc854731
    2018-11-03T10:11:42.485085063+02:00 container kill 9cc854731
    2018-11-03T10:11:42.490162686+02:00 container kill 16e1af20f
    2018-11-03T10:11:42.498272764+02:00 container kill 6f1df5233
    2018-11-03T10:11:42.547462663+02:00 container kill 6f1df523

並行処理：６

   cut -c1-60 /tmp/events | egrep 'create|kill'
    2018-11-03T10:13:22.444286947+02:00 container create bb4b2db
    2018-11-03T10:13:22.838989116+02:00 container create a00d0b1
    2018-11-03T10:13:23.039740661+02:00 container create f1f9090
    2018-11-03T10:13:23.595395816+02:00 container create 568b219
    2018-11-03T10:13:23.824193225+02:00 container create 77d7d22
    2018-11-03T10:13:24.191986311+02:00 container create 1ea8ad8
    2018-11-03T10:13:25.105183046+02:00 container kill 8a0373b67
    2018-11-03T10:13:25.146410226+02:00 container kill 8a0373b67
    2018-11-03T10:13:25.150991208+02:00 container kill 53002e5b3
    2018-11-03T10:13:25.190384877+02:00 container kill 75764275f
    2018-11-03T10:13:25.204178523+02:00 container kill a2bd707bc
    2018-11-03T10:13:25.230797581+02:00 container kill a26d9476c
    2018-11-03T10:13:25.234104353+02:00 container kill 61cbe7540
    2018-11-03T10:13:25.252980697+02:00 container kill 53002e5b3
    2018-11-03T10:13:25.268581894+02:00 container kill 75764275f
    2018-11-03T10:13:25.283548856+02:00 container kill a2bd707bc
    2018-11-03T10:13:25.299920739+02:00 container kill a26d9476c
    2018-11-03T10:13:25.306631692+02:00 container kill 61cbe7540

#Deploy: restart_policy
この設定オプションは、終了時にコンテナを再起動する方法を指定します。

condition のデフォルト値は any です: これはコンテナが失敗したとき、または正常に終了したときに再起動することを意味します。

restart_policy は、スウォームモードでスタックをデプロイする場合にのみ適用されます。

restart は、docker-compose up を使ってデプロイするときに適用されます。

これがどのように動作するかを確認するために、3秒のスリープの後にコンテナを正常に終了させます。コンテナが自動的に再起動されることを期待しています。

docker-compose.yml に以下を追加します。

nano docker-compose.yml

version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 3

    deploy:
      replicas: 1

docker stack deploy -c docker-compose.yml  mystack

docker ps -a を 25 秒間繰り返し実行すると、コンテナは 3 秒後に終了し、新しいコンテナが自動的に作成されてその場所を埋めるようになります。デフォルトの restart_policy は期待通りに動作します。

docker ps -a

約25秒後に期待される出力。

CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS                      PORTS               NAMES
42738b793169        alpine:3.8          "sleep 3"           6 seconds ago       Up Less than a second                           mystack_alpine.1.wopmb7xzyakbftkwsk9eq0goo
95e00ae7c883        alpine:3.8          "sleep 3"           15 seconds ago      Exited (0) 7 seconds ago                        mystack_alpine.1.h0n7hh12bn4jgb35bozpirm9r
bac92d42ca3f        alpine:3.8          "sleep 3"           25 seconds ago      Exited (0) 16 seconds ago                       mystack_alpine.1.2xujcjgypj9kbdcwsw0g0ysw8
0998efbcba8f        alpine:3.8          "sleep 3"           34 seconds ago      Exited (0) 26 seconds ago                       mystack_alpine.1.puqpmp9u13ivqvclah5cmidgx

これは永遠に続きます。幸いなことに、この再起動の最大試行回数を制限することができます。

max_attempts は、コンテナをあきらめる前に何回再起動を試みるかを指定します (デフォルト: never give up)。

を使用して、以下を docker-compose.yml に追加します。

nano docker-compose.yml

version: "3.7"
services:
  alpine:
    image: alpine:3.8
    command: sleep 2.22

    deploy:
      replicas: 1

      restart_policy:
        max_attempts: 3

これを使ってデプロイします。

docker stack deploy -c docker-compose.yml  mystack

実行してみると、20秒後にdocker ps -aを繰り返し実行すると、3つの新しいコンテナしか作成されていないことに気づくでしょう。その後、予想通り自動再起動が停止します。

また、delayを使って再起動間の待ち時間を調整することもできます。

デフォルト値は0で、再起動はすぐに行われます。

これを任意の時間に設定することができます。このチュートリアルでは説明しませんが、簡単なテストをしてみてください。

最後に、ウィンドウオプションもあります。

ウィンドウウィンドウ: ウィンドウ: 再起動が成功したかどうかを判断するまでの待ち時間を指定します。

あなた自身でも自由にテストしてみてください。

さらに興味深いエクササイズとして、遅延とウィンドウの間の相互作用を実験してみてください。

#結論
これでこのチュートリアルは終了ですが、Alibaba Cloud Elastic Compute Service (ECS) での docker-compose トレーニングの開始を意味します。これで、いくつかのdocker-composeの設定オプションをしっかりと理解し、かなりの実践経験を積むことができるようになるはずです。

Docker-composeの詳細については、公式ドキュメント https://docs.docker.com/compose/compose-file/ を参照してください。

または、Alibaba Cloudのコンテナサービスをチェックして、コンテナ化のメリットを最大限に享受する方法を学びましょう。

アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ