ダウンタイムなしでのDockerスタックのデプロイ

ダウンタイムなしでのDockerスタックのデプロイ

私はDockerチュートリアルに従って、自分のバージョンでやっています

version: "3.1"
services:
    web:
        image: registry.gitlab.com/xxxx/xxxx:latest
        deploy:
             replicas: 2
        ports:
             - "8888:80"
    mysql:
        image: mysql:latest
        environment:
           MYSQL_ROOT_PASSWORD: password
           MYSQL_USER: user
           MYSQL_PASS: password
        ports:
             - "8889:3306"
        volumes: 
           - mysql-data:/var/lib/mysql
volumes:
   mysql-data:

コードを変更するたびに、新しい Docker イメージを再構築して更新を実行します。

docker stack deploy --compose-file docker-compose.yml xxxx-learn 

その後、ダウンタイムが発生していることに気付きました。新しいコンテナを 1 つずつ起動し、古いコンテナを 1 つずつ停止します。問題は、新しいイメージをダウンロードするのに数分かかり、Web サーバーの実行に時間がかかることです。

私が考えていた解決策の 1 つは、これら 2 つの Web サーバー レプリカの前で Nginx ロード バランシングを実行することです。しかし、もっと良い解決策はあるでしょうか?

答え1

再起動ポリシーと stop_grace_period を Compose ファイルに追加する必要があります。

version: "3.1"
services:
    web:
        stop_grace_period: 10s
        deploy:
             replicas: 2
             restart_policy:
               condition: on-failure

答え2

その後、ダウンタイムが発生していることに気付きました。新しいコンテナを 1 つずつ起動し、古いコンテナを 1 つずつ停止します。問題は、新しいイメージをダウンロードするのに数分かかり、Web サーバーの実行に時間がかかることです。

イメージ/コンテナのヘルスチェックを定義する必要があります。これがないと、Docker はアプリケーションがリクエストを処理する準備ができたかどうかを認識できず、「まだ準備ができていない」コンテナにリクエストを送信し、最初のコンテナを置き換えた直後に残りの実行中のコンテナを停止します。

ヘルスチェックは、コンテナ内で実行してアプリケーションが正常かどうかを識別するコマンドを定義します。このドキュメントイメージ内でヘルスチェックを構成する方法については、こちらをご覧ください。

関連情報