Plexコンテナのアップグレードチェックリスト：バックアップ、バージョン固定、テスト、安全なロールバック
Plexコンテナをアップグレードする前に、永続状態を保護し、正常動作が確認できているイメージを記録し、依存関係を検証して、新しいものを取得する前にロールバックできる状態にしておきましょう。
アップグレードは、イメージを更新するだけの習慣ではなく、管理された変更として行うべきです。コンテナ自体は置き換え可能ですが、Plexのデータベース、メタデータ、マウント、GPUアクセス、ネットワークモード、周辺サービスはそうとは限りません。以前の動作状態を復元できるだけの情報を取得し、そのうえで毎回同じ少数のテストによって新しいバージョンを検証します。
イメージを置き換える前に永続状態を保護する
新しいコンテナが、バックアップされていない状態を破損または移行してしまえば、最速のロールバックも役に立ちません。バックアップには、Compose YAMLのコピーだけでなく、永続的なPlexデータのパスと、既知の復元手順を含める必要があります。
コンテナのアップグレード計画では、永続状態を保護し、ロールバックを定義し、結果を検証する必要があります。
バックアップ方法でPlexの停止または静止状態が必要な場合は、Plexを停止または静止させてから永続状態を取得し、バックアップを読み取れることを確認します。テスト環境で復元できない場合は、アップグレードを延期してください。
正常動作しているイメージと設定を正確に記録する
浮動するlatestタグだけを使用すると、回帰が発生した際に最後の正常な状態を再現することが難しくなります。イメージ参照、環境変数、マウント、デバイス、ネットワーク設定は、まとめて取得しておくべきです。
Docker Composeのサービス定義により、ボリューム、永続パス、サービスの境界が明確になります。
現在のイメージダイジェストまたは明示的なバージョンに加え、デプロイファイルとPlexに必要な環境変数を保存します。推測せずに以前のコンテナを再作成できないなら、ロールバックの準備はできていません。永続コンテナデータとマウントの契約を個別に保護している場合にのみ、イメージを使い捨てにできます。
ホストと連携サービスの依存関係を確認する
Plexのイメージ更新によって、以前のバージョンでは明らかにならなかったドライバー、GPUデバイス、ファイルシステム、プロキシ、または連携サービスの依存関係が表面化することがあります。変更前に、これらのインターフェースを簡単に事前確認しておきましょう。
複数サービスで構成されたメディアスタックでは、メディアパス、ストレージ、ワークフローのタイミングを共有する他のサービスとPlexが並行して動作することがあります。
アップグレードの前後に、マウント、UID/GID、ハードウェアデバイスへのアクセス、DNS、プロキシへの到達性を確認します。Plexと同時に依存関係も変更する場合は、障害の原因を把握できるよう、変更を分離してください。
固定したアップグレード後テストセットで検証する
コンテナが稼働していることは、アップグレードが成功した証拠ではありません。ログイン、ライブラリの閲覧、Direct Play、想定どおりのトランスコード1件、メタデータの書き込み、リモートアクセス、バックグラウンドタスクをすべて確認する必要があります。
使用率、飽和度、エラーの確認により、単に負荷が高いリソースと、実際に制約を受けている、または障害が発生しているリソースを区別できます。
アップグレードのたびに同じ短いスモークテストを実行し、以前のバージョンとリソース使用量を比較します。重要なテストに失敗した場合や、リソース需要が大きく変化した場合は、まずロールバックしてからリリースを調査してください。
おすすめ商品
サポートとヒント
もっと読む
ライブTV録画の容量・保存期間・クリーンアップガイド
実際の録音を測定し、ヘッドルームを確保し、経過時間と容量の制限を組み合わせ、ストレージが満杯になる前に最も古い対象プログラムが削除されることを確認する。
データベース復元後のホームメディアメタデータ復旧ワークフロー
復元した状態を保護し、メディアの識別情報とパスを確認してから、メタデータを広範囲に変更する前に、パイロットライブラリで不足しているアートワークや一致項目を修復します。
オーディオ、ビデオ、字幕のJellyfinクライアント互換性チェックリスト
代表的なファイルを一度に1つの変数だけテストし、すべてのクライアントについて、ダイレクトプレイ、リマックス、音声変換、動画トランスコード、または失敗を記録します。
