古いシークレットを使い続けるセルフホストアプリを解決する方法
変更した値が実行中のプロセスに実際に読み込まれた値と一致していない場合、セルフホスト型アプリは古いシークレットを使い続けます。
ホームサーバーでは、同じパスワード、APIトークン、暗号化キーが、Composeの環境変数、envファイル、マウントされたシークレットファイル、コンテナ管理UI、またはアプリ独自の永続データベースに存在することがあります。コンテナが再作成されていない場合、アプリが設定を内部に保存している場合、または別のサービスが古い認証情報で認証を続けている場合、プロセスを再起動するだけでは不十分です。ボリュームを削除したり、再度ローテーションしたりする前に、シークレットの供給元からプロセスまでを追跡してください。
実行中のコンテナがまだ古い値を持っていることを確認する
まず、シークレットそのものを表示するのではなく、安全なフィンガープリントを1つ特定します。設定元、実行中のコンテナの環境変数またはマウントされたシークレットファイル、そして使用中の認証情報を示すアプリケーションログまたは接続エラーを比較してください。
Composeのトラブルシューティング記事では、再起動では古い設定が残ると説明されています。再起動では、変更されたサービス定義との再調整を行わず、既存のコンテナ設定を再利用するためです。
実行中のコンテナがすでに新しいフィンガープリントを示している場合は、Dockerの設定を疑うのをやめ、アプリケーションの永続設定やシークレットを検証するリモートサービスを確認してください。まだ古いフィンガープリントが示される場合は、デプロイ層での修復を続けます。
アプリが実際に読み込んでいるシークレットの供給元を追跡する
その認証情報のあらゆる供給元を整理します。Composeにインラインで記述した環境変数、.env、env_file、マウントされたファイル、DockerまたはPodmanのシークレット、アプリケーション設定ファイル、コンテナ管理UI、そして初回起動時に値を永続ストレージへ保存したウィザードなどです。
実用的なCompose設定ガイドでは、マウントされた設定とシークレットを分けて説明しています。編集したenvファイルが、アプリケーションが現在読み取っている供給元とは限らない場合に役立ちます。
このデプロイで正式な供給元となっているものだけを変更してください。3つのコピーを同時に編集すると、アプリは正常に起動しても、どの古い供給元が問題を引き起こしたのか確認できなくなります。
シークレットがコンテナ設定の一部である場合はサービスを再作成する
認証情報がコンテナの環境変数として注入される場合や、コンテナ作成時にのみ具体化されるシークレットである場合は、永続ボリュームを保持したまま対象サービスを再作成してください。単純な停止と起動では、元のコンテナ定義が変更されないことがあります。
Podmanのローテーション例では、シークレットのローテーション後にサービスを更新すると説明しています。これは、シークレットストアの更新とは別に、コンテナのライフサイクル操作が必要であることを示しています。
まずは利用側のサービスだけを再作成してください。アプリケーションが古い認証情報をそこに保存していることが明確で、検証済みのバックアップがある場合を除き、名前付きボリュームやデータベースディレクトリを削除しないでください。
環境変数を上書きする永続的なアプリ設定を確認する
セルフホスト型アプリの中には、環境変数を初回起動時のデフォルトとして扱い、その後は編集可能な設定をデータベースやアプリケーションデータディレクトリに保存するものがあります。この設計では、環境変数に設定した新しい値が正しくても、アプリが意図的に保存済みの値を使い続けることがあります。
Open WebUIのトラブルシューティングガイドでは、この境界を具体的に説明しています。永続設定が環境変数を上書きすることがあるため、保存された設定を変更するか、その動作を意図的に無効化する必要があります。
ファイルを手動で変更する前に、アプリケーションが提供する管理設定または設定データベースを確認してください。保存された設定を変更することで新しいシークレットが有効になった場合は、今後のローテーションにおける正式な設定元として記録しておきます。
アプリが代わりにシークレットファイルを読み込んでいないか確認する
アプリケーションは、環境変数から生成済みまたはマウント済みのシークレットファイルへフォールバックすることがあります。そのため、コンテナを再作成しても、プロセスが永続ボリューム上の古いファイルを読み続けている可能性があります。
Open WebUIのインストール例では、環境変数が指定されていない場合、アプリが後の起動時に保存済みのシークレットファイルを読み込むことが示されています。Compose YAMLとは別に、実際のファイルパスを確認する必要がある理由が分かります。
ファイルのパス、更新日時、所有者、安全なフィンガープリントを確認してください。暗号化キーや署名用シークレットを変更すると、セッションが無効になったり、すでに暗号化されたデータが読み取れなくなったりする可能性があるため、必ずアプリケーションがサポートする方法で置き換えてください。
利用側と提供側を1つのトランザクションとしてローテーションする
データベースのパスワード、APIトークン、サービス認証情報には、それを提示するアプリと、検証する提供側の2つの側面があります。一方だけを更新すると認証エラーが発生し、アプリが古い値をキャッシュしていると誤解する可能性があります。
シークレット更新の手順では、アプリケーションがローテーションされたシークレットを再読み込みする必要があると説明されています。再起動、シグナル、またはアプリケーション固有の再読み込み処理が必要であり、プロセスがすべてのファイル変更を自動的に検知すると考えてはいけません。
実際の認証処理を1つ実行して確認し、サービスをもう一度再起動または再作成してから再テストします。再作成後も新しい認証情報が有効で、古い認証情報が拒否されれば、修復は完了です。新しいシークレットが読み込まれているのにリクエストが失敗する場合は、次の確認ポイントとして、APIパスに問題があるセルフホスト型アプリに関するZimaSpaceガイドを参照してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
