サービスへのローリングアップデートの適用

読む時間の目安: 2 分

チュートリアルの前の手順では、サービスのインスタンス数を スケール変更 しました。 ここでは Redis 3.0.6 というタグをつけたコンテナーを使って、サービスのデプロイを行います。 そしてこのサービスが Redis 3.0.7 というコンテナーイメージを用いるように、ローリングアップデートを使ってサービスをアップグレードします。

  1. マシンへの接続ができていなければ、端末画面を開いて SSH により接続します。 接続先はマネージャーノードを起動したマシンです。 たとえばこのチュートリアルではmanager1というマシンを利用します。

  2. Regis タグを Swarm にデプロイします。 そして Swarm に対して、アップデートの待機時間（update delay）を 10 秒に設定します。 なお以下の例は、古い方の Redis タグを使っています。

    $ docker service create \
  --replicas 3 \
  --name redis \
  --update-delay 10s \
  redis:3.0.6

0u6a4s31ybk7yw2wyvtikmu50

    上のコマンドにより、サービスデプロイ時のローリングアップデートポリシーを設定したことになります。

    --update-delayフラグは、サービスの 1 つあるいは複数のタスクに対して、アップデートの待機時間を設定するものです。 数値をTとして、Tsは秒、Tmは分、Thは時間を表現します。 そこでたとえば10m30sは 10 分 30 秒の遅延を表現します。

    デフォルトにおいてスケジューラーは、一度に 1 つのタスクをアップデートします。 --update-parallelismフラグを指定すれば、スケジューラーが同時にアップデート可能なサービスタスクの最大数を設定することができます。

    ある 1 つのタスクに対するアップデート処理の結果としてRUNNINGという状態が返ってきたとします。 デフォルトでスケジューラーは、その場合、別のタスクを処理するようにし、最終的にタスクすべてのアップデートが完了するようにスケジュールされます。 アップデートのどういうタイミングであっても、タスクがFAILEDを返してきたら、スケジューラーはアップデート処理を中断します。 この動きに対しては、docker service createやdocker service updateにおける--update-failure-actionフラグを使って制御することができます。

  3. redisサービスを確認します。

    $ docker service inspect --pretty redis

ID:             0u6a4s31ybk7yw2wyvtikmu50
Name:           redis
Service Mode:   Replicated
 Replicas:      3
Placement:
 Strategy:	    Spread
UpdateConfig:
 Parallelism:   1
 Delay:         10s
ContainerSpec:
 Image:         redis:3.0.6
Resources:
Endpoint Mode:  vip

  4. redisに対するコンテナーイメージのアップデータを行います。 Swarm マネージャーはUpdateConfigポリシーに従って、ノードへのアップデートを適用します。

    $ docker service update --image redis:3.0.7 redis
redis

    スケジューラーは、デフォルトで以下のようにしてローリングアップデートを適用します。

    • 最初のタスクを停止します。
    • 停止したタスクに対してアップデートをスケジュールします。
    • アップデート対象のタスクに対してコンテナーを起動します。
    • 1 つのタスクに対するアップデートにおいて RUNNING が返ってきたら、指定された待機時間だけ待って、次のタスクの処理を開始します。
    • アップデート中にタスクがFAILEDを返したら、アップデートを中断します。

  5. docker service inspect --pretty redisを実行して、新たなイメージが思ったとおりの状態になっていることを確認します。

    $ docker service inspect --pretty redis

ID:             0u6a4s31ybk7yw2wyvtikmu50
Name:           redis
Service Mode:   Replicated
 Replicas:      3
Placement:
 Strategy:	    Spread
UpdateConfig:
 Parallelism:   1
 Delay:         10s
ContainerSpec:
 Image:         redis:3.0.7
Resources:
Endpoint Mode:  vip

    処理失敗によりアップデートが中断していたらservice inspectの結果は以下のようになります。

    $ 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 <サービスID>を実行します。 たとえば以下のとおりです。

    $ docker service update redis

    特定のアップデータ失敗が続くようであれば、これを解消するために、docker service updateに何らかのフラグを指定して、サービスを再設定する必要があるかもしれません。

  6. docker service ps <サービスID>を実行して、ローリングアップデートの状況を確認します。

    $ docker service ps redis

NAME                                   IMAGE        NODE       DESIRED STATE  CURRENT STATE            ERROR
redis.1.dos1zffgeofhagnve8w864fco      redis:3.0.7  worker1    Running        Running 37 seconds
 \_ redis.1.88rdo6pa52ki8oqx6dogf04fh  redis:3.0.6  worker2    Shutdown       Shutdown 56 seconds ago
redis.2.9l3i4j85517skba5o7tn5m8g0      redis:3.0.7  worker2    Running        Running About a minute
 \_ redis.2.66k185wilg8ele7ntu8f6nj6i  redis:3.0.6  worker1    Shutdown       Shutdown 2 minutes ago
redis.3.egiuiqpzrdbxks3wxgn8qib1g      redis:3.0.7  worker1    Running        Running 48 seconds
 \_ redis.3.ctzktfddb2tepkr45qcmqln04  redis:3.0.6  mmanager1  Shutdown       Shutdown 2 minutes ago

    Swarm が全タスクに対するアップデートを終えていない状態であれば、redis:3.0.6を実行しているものがあり、また redis:3.0.7を実行しているものもありました。 上の結果からは、ローリングアップデート処理を終えた状態であることがわかります。

次にすることは

次は Swarm 内からの ノードの解放 について学びます。

tutorial, cluster management, swarm, service, rolling-update