Jellyfinを1つのコンテナから堅牢なサービススタックへ移行する方法

まず現在の動作を明確に定義し、永続状態を保護してから、可逆的でテスト済みの段階を踏んでサービスを追加することで、Jellyfinを移行します。

この手順は、文書化されていないコマンドや一体型の構成から発展した、稼働中のDockerコンテナを対象としています。目的はコンテナ数を最大化することではなく、明示的なマウント、ネットワーク、デバイス、ヘルスシグナル、バックアップ範囲、ロールバックを備えた、再現可能なJellyfinサービスを構築することです。メディアストレージはアプリケーション状態から分離し、受け入れテストに合格するまで旧インスタンスを保持し、家庭内で運用できる依存サービスだけを追加してください。

レジリエンスで対応すべき範囲を定義する

新しいスタックで対応すべき障害を選びます。Jellyfinプロセスのクラッシュ、不適切なイメージ更新、設定ストレージの消失、プロキシの利用不能、ホストの再起動、ホスト全体の喪失などです。それぞれに必要な制御は異なります。再起動ポリシーはプロセス終了後の復旧には役立ちますが、削除されたボリュームを復元したり、到達不能なメディアマウントを修復したりはしません。

設定、視聴状態、サービス可用性について、測定可能な復旧目標を設定します。許容できる停止時間とデータ損失、アラートの受信者、再構築可能な部分を決めてください。この範囲を定めることで、特定したリスクを減らさないデータベース、プロキシ、ダッシュボード、自動化機能を小規模な家庭内移行に追加することを防げます。

稼働中のコンテナを棚卸しする

正確なイメージ参照、コマンド、環境変数、公開ポート、ネットワーク、再起動ポリシー、ユーザーIDとグループID、デバイスマッピング、DNS設定、ラベル、設定マウント、キャッシュマウント、メディアマウント、シークレットを記録します。さらに、すべてのホストパスの所有者と権限も取得してください。コンテナUIのスクリーンショットだけでは、完全なデプロイ記録になりません。

動作を変えずに、その棚卸し結果をCompose定義へ変換します。このDocker runからComposeへの移行ガイドのフラグを一つずつ対応付ける方法が有用なのは、最初のマイルストーンを機能拡張ではなく再現性として扱うためです。初回の切り替えでは、現在稼働しているイメージのダイジェストまたはバージョンを固定してください。

永続状態、キャッシュ、メディアを分離する

Jellyfinの設定とデータベース状態を、明確な名前の永続パスに割り当てます。使い捨てのキャッシュやトランスコード用セグメントは別のパスに配置し、重要なバックアップデータと誤認されないようにします。所有するメディアは独立してマウントし、ワークフローで許可される場合は読み取り専用にします。レジリエントなアプリケーション層によって、大規模なメディアライブラリの保護境界を曖昧にしてはいけません。

バックアップ方式がアプリケーション整合性を保証しない限り、最初の整合性のある状態コピーを作成する前にJellyfinを停止または静止させます。権限、チェックサムまたはファイル数、バックアップ時刻、復元先を記録してください。コンテナイメージにユーザーデータが含まれているとは決して考えないでください。デプロイ定義、シークレット、永続状態、メディア参照は、それぞれ別個の復旧入力です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

ネットワークを変更する前に復元を実証する

一時的な復元先を作成し、保護対象のアプリケーション状態をそこへコピーします。メディアを読み取り専用でマウントし、別のポートで固定済みのJellyfinサービスを起動してください。ユーザー、ライブラリ、視聴履歴、メタデータ、プラグイン、代表的な再生を確認します。一時インスタンスを破棄し、どの手順も記憶に依存しなくなるまで、文書化した手順から繰り返します。

実用的なComposeバックアップでは、デプロイファイル、環境入力、ボリューム、アプリケーション整合性を保ったデータベースエクスポートを保存する必要があります。このComposeのバックアップとアップグレードガイドでは、イメージだけ、または稼働中のデータベースファイルだけをコピーしても、完全な復旧経路にはならない理由を説明しています。

宣言的なJellyfinサービスへ切り替える

メンテナンス時間を設定し、旧コンテナを停止して、最後の整合性のある状態バックアップを取得します。その後、旧インスタンスが自動的に再起動しないようにします。同じ永続パスとデバイスアクセスを使って、同等のComposeサービスを起動してください。ローカルのヘルスチェックと再生確認に成功してから、公開経路を変更せず維持します。

コンテナのヘルス状態、ログ、ライブラリの可視性、ハードウェアデバイスへのアクセス、ダイレクト再生、代表的なトランスコード、字幕処理、再起動を検証します。サービスからデバイスやマウントが見えない場合は、切迫した状況で複数の層を編集するのではなく、停止して旧コンテナへ戻してください。ロールバックには、切り替え前の状態と元の実行パラメータに加え、以前固定していたイメージを使用します。

隣接サービスは境界ごとに一つずつ追加する

リモートからの入口に個別管理の経路が必要な場合にのみ、リバースプロキシを導入します。明確なヘルスシグナルがあり、誰かが対応できる場合にモニタリングを追加します。再起動ループ、ストレージ喪失、バックアップ失敗を把握する必要がある場合に、アラートチャネルを追加します。各サービスには、担当者、永続状態に関する判断、ネットワーク範囲、更新方法、障害時の影響が必要です。

これらの境界を設けるアーキテクチャ上の理由については、ZimaSpaceによるJellyfinのデプロイでサービススタックを使う理由の解説で別途説明されています。移行中はこのモデルを慎重に適用し、同時に復旧すべきコンポーネントをまとめ、再生が任意のダッシュボードや自動化機能に依存しないようにします。

ヘルス、更新、バックアップを可視化する

ヘルス状態は、単にプロセスが動いているかではなく、ユーザーが利用する経路で定義します。Jellyfinがローカルで応答すること、メディアマウントが存在すること、有効化している場合は公開経路が意図したサービスに到達すること、既知のファイルを一つ読み取れることを確認してください。アプリケーション障害とストレージまたはネットワーク障害を区別できる十分な情報を添えて、失敗したチェックを運用担当者がすでに使っている通知チャネルへ送ります。

Compose定義をバージョン管理し、シークレットをリポジトリの外に保管し、デプロイ前にイメージの変更を確認します。手動復元が成功してから、バックアップを自動化してください。このJellyfinのヘルスチェックとモニタリングガイドでは、宣言、チェック、アラート、バックアップをどのようにつなげるかを示しています。保存状態を変更する可能性がある更新については、承認とロールバックの時点を残してください。

旧経路を廃止する前に障害訓練を行う

ホストを再起動し、Jellyfinを予期せず停止させ、プロキシを利用不能にし、テスト用のメディアパスを切断し、アプリケーション状態をクリーンな一時環境へ復元します。各訓練で、想定したアラート、復旧順序、ユーザーから見た動作を確認してください。唯一のメディアコピーに対して破壊的なストレージ喪失をシミュレートしてはいけません。

復旧時間と手動コマンドを記録します。すぐに再起動しても空のライブラリで戻ってくるコンテナは、サービスのテストに失敗しています。バックアップが存在しても、目標時間内に復元できなければ、復旧テストに失敗しています。サービスをさらに追加する前に、これらの境界を修正してください。

安定した運用契約で移行を完了する

新しいJellyfinサービスが通常の家庭内利用、計画的な更新、ホストの再起動、クリーンな復元リハーサルを乗り切った後にのみ、元のコンテナを廃止します。選択した保持ポリシーに従い、旧パラメータ、切り替え前の最終バックアップ、現在のCompose定義、シークレットの復旧方法、マウントマップ、ロールバック手順をアーカイブします。

スタックが再現可能で、監視され、復旧可能で、運用担当者にとって理解しやすくなったら、拡張を止めます。測定された容量、信頼性、または障害ドメイン上の要件が求める場合にのみ、別のノードや依存関係を追加してください。レジリエンスは図に描かれたコンテナ数ではなく、把握された状態と実践された復旧によって生まれます。