コンテナのアップグレード中にPlexの設定が失われるのを防ぐ方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Prevent Plex Configuration Loss During Container Upgrades - Zima Store Online

アップグレード前に永続的なアプリデータを保護し、交換可能なコンテナ層だけを変更することで、Plexの設定消失を防ぎます。

ホームサーバーでは、危険なのはイメージの取得自体ではなく、誤った設定パス、未検証のバックアップ、または実用的なロールバック参照なしにPlexを再作成することです。まず、現在のサーバーが実際に使用している永続ディレクトリを確認し、破壊的な変更を行う前にその状態を保護します。アップグレード後のコンテナが新規サーバーとして起動した場合は、設定を誤った状態に重ねて再構築せず、そこで停止してマッピングを確認してください。

Plexの設定を使い捨てのコンテナから分離する

コンテナイメージは交換されることを前提としていますが、保持したいPlexの状態はその交換後も残らなければなりません。実行中のコンテナをアプリケーション層、永続的なアプリデータを別個の復旧対象として扱います。この2つの層が分離されていないと、通常のアップグレードが意図しないリセットにつながる可能性があります。

永続側に含まれるのは、映画やテレビ番組のフォルダーだけではありません。Plexは、データディレクトリとサーバー設定を使用して、ライブラリ構造、メタデータ、環境設定、その他のサーバー状態を保持します。一方、メディアファイル自体は別のストレージに残しておけます。したがって、メディアだけを保護しても、同じサーバーを復元するために必要なPlex設定は保護できません。

アップグレードを計画する前に、この永続状態を保持しているホストディレクトリまたは名前付きボリュームを特定します。多くのコンテナ構成では、Plex内では /config のような設定マウントとして表示されますが、復旧で重要なのはホスト側の場所です。そのソースを確実に指し示せない場合は、確認できるまでアップグレードを保留してください。

アップグレード前に現在の設定パスを確認する

最初の確認は、破壊的な操作ではなく観察から始めます。コンテナ定義、Composeファイル、NASアプリの設定、またはコンテナ管理UIを開き、アクティブな設定マウントと、Plexの状態が保存されていると考えているホスト側の場所を比較します。既知の正常なサーバーがまだ稼働している間に行い、信頼できる基準を確保してください。

正しいマッピングは、現在のサーバーがすでに使用している、データが存在するアプリデータの場所につながるはずです。PlexのDocker環境では、コンテナの再起動やアップグレード後もデータが残るよう、アプリケーション状態をPlex用の永続ボリュームに保持します。コンテナを再デプロイする際は、空のディレクトリや新しく作成されたディレクトリではなく、検証済みのホスト側設定ソースを再利用してください。

マッピングが誤っている、曖昧である、またはPlexが使用できない場所を指している場合は、イメージの取得や再作成を行う前に停止します。古いコンテナがまだ利用できる間にパスまたはアクセスの問題を修正し、Plexを再度開いて期待どおりのサーバーが表示されることを確認してください。この確認により、マッピングは推測ではなく、検証済みの基準になります。

マッピングをスクリーンショット、エクスポートしたアプリテンプレート、または保存済みのComposeファイルとして記録します。目的は記録そのものではなく、復旧プロセスから記憶頼みの作業をなくすことです。アップグレード後は、新しいコンテナ定義を正常に動作していたものと比較し、どのホストパスや権限設定が変わったのかを推測せずに済むようにします。

イメージを変更する前に復旧可能なバックアップを作成する

アクティブな設定パスを検証したら、イメージを変更する前に、その永続的なPlex状態を別の復旧先へコピーします。バックアップには、アーカイブ、スナップショットと独立したコピーの組み合わせ、またはNASがサポートする別の方法を使用できます。ただし、単に正しいと期待しているディレクトリではなく、既知の正常なサーバーを表すものでなければなりません。

稼働中のデータベースファイルには注意してください。データベースの変更中にPlexのアプリデータを単純にコピーするバックアップ方法では、ツールがアプリケーション整合性のあるスナップショットやデータベース対応方式を提供しない限り、まずPlexコンテナを停止または静止します。アーカイブが明らかなエラーなく完了したからといって、不整合なデータベースを取得した高速コピーが安全なバックアップになるわけではありません。

コピーが完了したら、稼働中のディレクトリとは別に検査します。認識可能なPlexアプリデータの構造が含まれていること、タイムスタンプとサイズを確認し、アーカイブを一時的な場所に開くか展開できることをテストします。バックアップを正常に読み取れない場合は、稼働中のコンテナに触れる前にバックアップ手順を修正してください。

アップグレード前のコピーは、稼働中のアプリデータパスとは別に保管します。これから再マッピングまたは整理する同じディレクトリツリー内にバックアップを置くと、保護対象だったソースと一緒に消える可能性があります。直近の目的はアップグレードのミスから復旧できることです。ディスク障害へのより広範な保護は、通常のNASバックアップポリシーに従って行えます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

コンテナ定義と最後に正常動作したイメージ参照を保存する

設定データだけでは、役立つロールバックには不十分です。現在のコンテナ定義として、イメージ参照、ボリュームマッピング、関連する環境変数、ネットワークモード、デバイスマッピング、その他記憶だけでは再現しにくい設定も保存します。ComposeファイルやエクスポートしたNASアプリテンプレートは、障害発生後に手書きで再構築するより信頼できます。

latestのような可変タグに頼る前に、バージョン付きタグ、ダイジェスト、または解決可能な別の参照で、最後に正常動作したイメージを記録します。「昨日は動いていた」ことは分かっていても、実際に昨日使用していたイメージを特定できなければ、ロールバックははるかに困難です。アプリデータ、コンテナ定義、そして特定のイメージ参照を保存することで、現在の構成を再現可能な復旧ポイントにできます。

アップグレードの検証が終わる前に、以前のイメージを削除したり、保存したデプロイ定義を消去したりしないでください。新しいコンテナが設定パスとは無関係な理由で失敗した場合でも、保護したアプリデータを変更せずに以前の実行環境を再作成できるようにしておきます。これにより、ロールバックはソフトウェア層に集中でき、新しい設定移行と復旧作業が混ざるのを防げます。

永続状態の境界を変更せずにアップグレードする

バックアップとロールバックの準備が整ったら、検証済みの永続設定マッピングを変更せずに、Plexイメージを置き換えるか更新します。コンテナイメージを置き換えながら同じ永続ボリュームを再利用することで、アプリデータを使い捨てのコンテナ層の外部に保持できます。メンテナンスの目的が明示的な移行でない限り、メディアパスやその他の正常なマウントも安定させてください。

期待される結果は単純です。アップグレード後のコンテナが同じ永続的な /config 状態を使用して起動し、Plexが既存のサーバーとして戻ってくることです。マッピングが維持されていれば、新しいコンテナは保存済みのライブラリデータベース、設定、メタデータを再利用でき、初回インストールのように扱うことはありません。新しい設定変更を行う前に、確認すべき状態はこれです。

Plexに初回設定画面、空のライブラリ、またはクレームフローが表示された場合は、すぐにサーバーの再構築を始めないでください。新しいコンテナを停止し、その設定マッピングを正常動作していた定義と比較します。コンテナ交換後に新規サーバーのように見える場合は、まず永続性を確認すべきです。誤った状態を設定すると、復旧経路が分かりにくくなる可能性があります。

マッピングが正しいにもかかわらず新しいイメージが失敗する場合は、保存したイメージ参照とデプロイ定義を使用して、保護したアプリデータをそのまま残しながら最後に正常動作したコンテナへ戻します。アプリデータ自体が破損しているように見える場合は、唯一の既知の正常なバックアップ上で試行錯誤するのではなく、アップグレード前のコピーから復元してください。

ロールバック用コピーを削除する前にアップグレード後のサーバーを確認する

コンテナが起動しただけでは、アップグレードが検証済みとはいえません。メンテナンス前に記録した基準とアップグレード後のサーバーを比較し、期待されるサーバーID、ライブラリ、重要な設定、メディアパス、そして少なくとも1回の代表的な再生セッションを確認します。いずれかが異なる場合は、復旧用資産を削除する前に調査してください。

アップグレード後のバージョンが起動したことだけでなく、復旧が可能であることを確認するまで、アップグレード前のアプリデータバックアップと最後に正常動作したイメージ参照を保持します。復元テストを行うことで、バックアップが実用的な復旧経路になることを確認できます。テストは、本番環境に影響を与えずにアーカイブを展開する、または一時的な場所にコピーを復元するだけでも構いません。

アップグレード後のサーバーが基準と一致し、復旧パッケージも利用可能であることを確認できたら、メンテナンス期間は完了したとみなせます。アップグレードが一度成功したからといってすぐに削除するのではなく、通常のポリシーに従ってバックアップを保持またはローテーションしてください。これにより、スケジュールタスク、ライブラリスキャン、通常の家庭内利用を再開した後にのみ現れる問題にも対応できます。

Plexの状態を置き換えたり解釈し直したりする可能性がある今後の変更にも、同じ保護手順を適用します。たとえば、コンテナイメージのアップグレード、別ホストへの移行、設定パスの移動、大幅な権限変更、アプリデータの保存先変更などです。永続マッピングを再確認し、新しい復旧ポイントを作成し、ロールバックの情報を保存して、削除前に結果を検証します。この手順を実行するタイミングは、任意のカレンダー間隔ではなく、破壊的な変更が発生するときです。