セッション状態サービスを再起動せずにリバースプロキシを再起動する方法
リバースプロキシの再読み込みや再起動を、その背後にある認証サービスやセッション状態サービスから独立して実行できるようにすると、計画メンテナンスの安全性が高まります。
通常、プロキシプロセスが転送するログイン状態を所有する必要はありません。メンテナンス前に、Cookieへの署名、サーバー側セッションの保存、認証の終端、アクティブなHTTP接続のドレインをそれぞれどのコンポーネントが担当しているかを確認してください。状態を保持するコンポーネントは稼働させたままにし、設定変更だけの場合は可能な限りプロキシをグレースフルに再読み込みします。また、プロキシを完全に置き換えた場合でも、同じ認証ゲートウェイとセッションストアに、同じシークレットで再接続できることを確認してください。
プロキシのライフサイクルを認証サービスのライフサイクルから分離する
Composeの依存関係、再起動ポリシー、共有スクリプト、スタックマネージャーの操作を確認し、プロキシの再起動によって認証ゲートウェイ、アプリケーション、Redis、データベースまで自動的に再作成されないようにしてください。
セッションアーキテクチャの例として、Redisをプロキシのライフサイクル外に配置する構成があります。これにより、複数の認証インスタンスや再起動間で同じセッションバックエンドを共有できます。
すべてのエッジサービスを、単一の一括再起動コマンドにまとめないでください。証明書やルートの変更がプロキシにしか影響しない場合は、既存のログイン状態を検証するサービスを稼働させたままにします。
可能な限り再起動ではなく設定を再読み込みする
ルート、証明書、ヘッダーを変更する場合は、サービスを停止するのではなく、プロキシがサポートするグレースフルな再読み込み手順を使用してください。適用前に設定を検証し、構文エラーによって計画メンテナンスがダウンタイムに変わらないようにします。
API7のNGINX解説では、古いワーカーが接続をドレインする仕組みと、更新後の設定で新しいワーカーがリクエストを受け付ける流れを説明しています。
再読み込みによってプロキシプロセスの系統は維持されますが、デプロイスクリプトが認証サービスまで再起動する場合、そのサービスが保護されるわけではありません。この2つのライフサイクルを分けて考えてください。
プロキシの置き換え後も外部セッションストレージを維持する
認証ゲートウェイがCookieの外部にセッションデータを保存する場合は、プロキシの操作中もRedisなどのセッションバックエンドを永続化し、変更しないでください。すべての認証インスタンスが使用するバックエンドアドレスとシークレットを記録しておきます。
OAuth2 Proxyは、インスタンス間でセッションを共有する必要がある場合、共有セッションストレージとしてRedisをサポートしています。
一時的なキャッシュを、信頼できるログイン状態と混同しないでください。現在のユーザーの検証にセッションバックエンドが必要な場合は、テスト済みの専用メンテナンス手順に従ってのみ再起動またはフラッシュしてください。
Cookieと署名用シークレットを安定させる
認証ゲートウェイが使用するCookieの暗号化または署名用シークレットを記録し、置き換え後のプロキシスタックが同じシークレットソースをマウントするようにしてください。再デプロイ時に新しい値を生成すると、正常なブラウザCookieまで無効になります。
リバースプロキシのセッションガイドでは、安定したセッションポリシーが再起動後も維持されることを説明しています。これは単一のTCP接続の存続期間に依存するものではありません。
署名用シークレットのローテーションは、明示的なログアウトの想定または重複期間の戦略を伴う、独立したセキュリティ変更として実施してください。セッションの無効化を意図していない限り、通常の計画プロキシ再読み込みにシークレットのローテーションを組み合わせないでください。
プロキシを完全に再起動する際は接続をドレインする
プロキシのバイナリやコンテナを置き換える必要がある場合は、利用可能であればグレースフルまたは無停止の再起動機構を使用し、確立済みのリクエストがレスポンスの途中で切断されないようにしてください。長時間接続にはメンテナンスタイムアウトを設定します。
HAProxyの再読み込みガイドでは、無停止の再読み込みによって接続を維持する方法を説明しています。古いプロセスを直ちに終了させることはありません。
接続の継続性とログインの継続性は別のものです。WebSocketが再接続できたとしても、置き換え後のプロキシが同じ認証サービスと状態サービスに接続することで、セッションが有効なまま維持される必要があります。
計画メンテナンスの前後で1つのセッションをテストする
ログイン済みのブラウザを1つと、新しいプライベートセッションを1つ用意します。メンテナンス前にセッションCookie、プロキシルート、認証サービス、バックエンドを記録し、プロキシだけを再読み込みまたは置き換えた後、同じ保護対象リクエストを再実行します。
Caddyの運用ガイドでは、計画された設定更新に対してリバースプロキシサービス全体を停止するのではなく、完全な再起動ではなく再読み込みを推奨しています。
既存のログインが維持され、新しいログインも成功し、状態を保持する依存サービスが意図せず再起動されていなければ、メンテナンス設計は機能しています。ユーザーがログアウトされたままの場合は、プロキシ再起動後のセッション消失に関する関連ZimaSpace記事が、適切な復旧手順です。
よくある質問
グレースフルなプロキシ再読み込みを行えば、ユーザーがログイン状態を維持できることは保証されますか？
いいえ。プロキシ接続は保護されますが、同時に認証サービス、セッションストア、またはCookie署名用シークレットが変更されると、ユーザーがログアウトされる可能性があります。
Redisは常にプロキシの再起動後も維持すべきですか？
Redisがセッション状態や、認証に必要な別の永続的依存サービスを保存している場合に限ります。キャッシュ専用のRedisインスタンスでは、復旧の境界が異なります。
同じCookie名を維持するだけで十分ですか？
いいえ。署名または暗号化用のシークレットとバックエンドのセッション状態も、ブラウザがすでに保持しているCookieと互換性を保つ必要があります。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
