このチュートリアルでは、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ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ