JSESSIONID Cookie に基づいて、スティッキーである必要がある長寿命の対話型ユーザー セッションを持つ webapp のゼロ ダウンタイム ローリング アップデートを提供する方法を見つけようとしています。
この (およびその他の) 理由から、Docker Swarm や Kubernetes などのコンテナー テクノロジに注目しています。
次の方法について、適切な答えを見つけるのに苦労しています。
- 新しいセッションがアプリの最新バージョンに移動することを確認してください
- 既存のセッションは、開始されたアプリのバージョンに関係なく引き続き提供されます
- 古いバージョンへの/上のすべてのセッションが閉じられたら、古いバージョンを適切にクリーンアップします
いくつかの詳細情報:
- リクエストは、JSESSIONID Cookie に基づいてセッションにリンクされます
- セッションは数日間存続する可能性がありますが、たとえば 24 時間以内にアプリ内からセッションを終了することができます (ユーザーに「新しいバージョンがあるためログアウト/再度ログインするか、午後 12 時に自動的にログアウトされる」という通知を送信します)。 " 例えば）
- もちろん、アプリの各バージョンには、負荷分散された方法で既に実行されている複数のコンテナーがあります
- コンテナーの総数が増えてもかまいません。たとえば、古いバージョンのコンテナーのそれぞれがまだ稼働中である場合、それらはすべて 1 つのセッションをホストするため、ユーザーの大部分は既に新しいバージョンのアプリ
したがって、必要なフローについての私の考えは、次のようなものです。
- アプリの新しいバージョンを入れる
- すべての新しい接続 (JSESSIONID cookie が設定されていない接続) を新しいバージョンのアプリに 1 回だけ移動させます。
- アプリの古いバージョンのコンテナーがセッションを提供しなくなった場合は、コンテナーを削除します/....
前述したように、私は Kubernetes と Docker Swarm を検討していますが、他の提案も受け付けていますが、最終的なソリューションはクラウド プラットフォームで実行できるはずです (現在 Azure を使用していますが、将来的には Google または Amazon クラウドが使用される可能性があります)。
ポインタ/ヒント/提案またはアイデアを歓迎します
ポール
編集: @Tarun の質問と一般的な説明への回答: はい、ダウンタイムは必要ありません。私が想像する方法は、古いバージョンをホストしているコンテナーが実行され続け、既存のすべてのセッションを提供することです。古いサーバー上のすべてのセッションが終了すると、古いサーバーは削除されます。
新しいコンテナーは、新しいバージョンのロールアウトが開始された後にアプリを起動するユーザーに対してのみ、新しいセッションを提供します。
例を挙げると、 - 午前 9 時に古いバージョンのアプリの新しいセッション A を起動します - 午前 10 時に新しいバージョンがロールアウトされます。- 古いバージョンを実行しているコンテナーでホストされたままのセッション A を引き続き使用しています。- 正午にランチに行ってログアウトします - 古いバージョンを実行しているコンテナに接続された最後のセッションだったので、コンテナは破棄されます - 午後 1 時に戻ってログインし、新しいバージョンのアプリ
理にかなっていますか？