コンテナで復旧可能なJellyfin環境を構築する方法

ランタイムを使い捨て可能にし、永続状態を明確にして、クリーンな環境で復元手順を再現できるようにすることで、復旧可能なJellyfinコンテナ環境を構築できます。

コンテナイメージは、復旧に必要な要素の一つにすぎません。Jellyfinサービスを正常に動かすには、設定とデータベースの状態、メディアのマウント先、UID/GIDの所有権、ハードウェアアクセラレーション用のデバイス割り当て、ポート、シークレット、ネットワーク名、復元したデータを読み込める正確なイメージバージョンも必要です。目指すのは「Dockerが自動で再起動する」ことではなく、障害が発生したホストを、正しい状態がどこに保存されていたか推測せずに再構築できることです。

Composeファイルを書く前に復旧単位を定義する

コンテナを完全に削除しても保持する必要があるものを列挙します。Composeまたは同等のデプロイ定義、環境設定、シークレットの復旧方法、Jellyfinの設定とデータベース、必要なメタデータ、プラグインの状態、メディアストレージへの対応関係です。キャッシュとトランスコードのディレクトリは別に明記し、失われても再生履歴やユーザー設定と同じバックアップ優先度にならないようにします。

テスト済みのDocker Compose復旧ガイドでは、復旧可能な一式を、定義、環境ファイル、シークレット、バインドマウントまたはボリューム、データベース整合性を保ったコピー、イメージ参照、復元順序として説明しています。Jellyfinにもこの考え方が適しています。フォルダーだけではなく、サービスの構成一式を復旧します。

これらの情報を簡潔な復旧マニフェストに記録します。その一覧から再構築できないなら、コンテナはまだ文書化されていないホストの状態に依存しています。Jellyfinの基本的な復旧単位を個別に復元・検証できるまでは、プロキシ、監視ツール、追加のデータベースを導入しないでください。

置き換え可能なランタイムと永続状態・メディアを分離する

イメージは置き換え可能にし、アプリケーションの状態は置き換え不要にします。Jellyfinの設定・データのパスは明示的な永続ストレージにマウントし、メディアは別に割り当てます。ワークフロー上問題がなければ、読み取り専用にするのが望ましいです。キャッシュとトランスコード用の作業領域は、それぞれ別の役割として分けておきましょう。一時ディレクトリがいっぱいになっても、データベースの停止やバックアップの肥大化につながらないようにできます。

最近のDocker復旧ガイドでは、コンテナのファイルシステムを永続的な状態として扱わず、Composeの定義、ボリュームまたはバインドマウント、環境設定、ホスト外のバックアップを分けています。重要なのはディレクトリ名そのものではなく、ライフサイクルごとにホスト側の管理者と復元方法を明確にすることです。

人が読みやすいホストパスによってバックアップやトラブルシューティングが明確になる場合はバインドマウントを、使用中のツールで名前付きボリュームの一覧作成とバックアップを確実に行える場合は名前付きボリュームを選んでください。どちらも復旧可能です。問題なのは、元のホストを失って初めて中身が判明する、名前のない、または記録されていない場所です。

ランタイムのバージョンを固定し、ホスト固有のインターフェースを記録する

復旧可能なデプロイでは、現在の永続データをどのバージョンのJellyfinが生成したかを把握しておく必要があります。更新ポリシーに適した範囲でバージョンを指定したイメージ参照を使い、最後に正常動作が確認されたイメージを記録してください。また、コンテナのユーザーID、レンダーデバイスのマッピング、補助グループ、ネットワークモード、公開ポート、リバースプロキシへの依存関係も記録してください。

コンテナの更新では実行ファイルのレイヤーが変更されても、永続データはそのまま残ることがあります。そのため、再現可能なセルフホスティングのワークフローには、記憶に頼るのではなく、明示的な定義が必要です。最近のDockerセルフホスティングガイドでComposeが使われているのは、長い一度限りのコマンドではなく、宣言的なプロジェクトディレクトリからサービス設定を再作成できるためです。

古いイメージだけでロールバックできると思い込まないでください。新しいJellyfinのバージョンでは永続データが移行されることがあるため、実際にロールバックするには、アップグレード前の状態と古いランタイムの組み合わせが必要になる場合があります。そのため、復旧手順書ではバージョン、状態コピーのタイムスタンプ、デプロイ定義をまとめて保管してください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

一貫性のあるバックアップを取り、隔離環境で復元を検証する

バックアップでは、アプリケーションの一貫性のある状態を取得し、稼働中のボリュームと同じ障害ドメインの外部に保管する必要があります。稼働中のファイルベースのデータベースを通常の再帰コピーでコピーすると、完全に見えても有効な復旧ポイントではない状態になることがあります。適切な場合はJellyfinのアプリケーション対応バックアップ機能を使用するか、整合性の挙動を理解したうえで、制御された停止またはスナップショットの方法を使ってください。

同じ原則は、より広範なバックアップテストにも当てはまります。バックアップが信頼できると言えるのは、ファイルを展開するだけでなく、実際の復元テストによって使えるアプリケーションを復旧できた後です。Jellyfinでは、別のポートでテスト環境を起動し、本番のメディアを読み取り専用にしたうえで、ユーザー、ライブラリ、視聴状況、代表的な再生、プラグイン、再起動を確認してください。

復元にかかった時間と、手動で行ったすべての作業を記録してください。忘れていたchmod、隠れた環境変数、または一度限りのデバイスマッピングが必要になった場合は、それをデプロイ契約に追加し、リハーサルをやり直してください。書面に記載された入力だけを使い、本番環境の変更可能な状態に頼らずに、クリーンな環境を再構築できたときにのみ、復元テストは完了です。

必須のマウントやデバイスがない場合はフェイルクローズする

意図したメディアマウントがなくても、GPUデバイスが公開されていなくても、コンテナは起動することがあります。その結果、ライブラリが空になったり、予期せずソフトウェアトランスコードが行われたり、ローカルの代替ディレクトリに書き込まれたりする可能性があります。実践的なComposeのサービス準備状態ガイドでは、「実行中」と「準備完了」は異なる状態である理由と、依存関係のチェックで利用側サービスの起動を制御すべき理由を解説しています。サービスを本番環境として動作させる前に、起動時のチェックで重要なパスを確認できれば、より安全に復旧できます。

ZimaSpaceのJellyfinサービススタック移行でも、同じ境界を適用しています。以前の構成を廃止する前に、マウント、永続状態、ハードウェアアクセス、再生、再起動時の動作を検証します。

マウントの有無、空き容量、設定ファイルの所有者、アクセラレーターの認識状態を事前チェックに含めてください。必須パスに問題があれば、空のディレクトリを使って起動せず、停止してください。アクセラレーションに失敗した場合は、家庭内の目標に従って、既知の縮退モードでサービスを継続するか停止します。気づかないうちにフォールバックし、デバイスが1つ欠けただけでホスト全体のCPUに負荷がかかる事態を招かないでください。

コンテナの再構築が当たり前になるまで障害訓練を繰り返す

コンテナの削除、ホストの再起動、不適切なイメージ更新、キャッシュの消失、メディアマウントの欠落、アプリケーション状態のクリーンなディレクトリへの復元をテストしてください。これらの経路をテストするために、実際のメディアを破壊する必要はありません。目的は、どのレイヤーが自動的に復旧し、どのレイヤーにバックアップが必要で、どのレイヤーをフェイルクローズさせるべきかを実証することです。

復旧可能な設計では、復元したデータで使い捨て環境にアプリケーションを起動できることも実証する必要があります。隔離された復元検証ワークフローでは、一時コンテナとヘルスチェックを使って、本番環境に触れることなくアプリケーションデータをテストします。新しいランタイムが本番環境の状態を初めて変更する前に、バックアップとロールバックの方法を把握しておきましょう。

サービス定義がバージョン管理され、永続パスが明確で、バックアップが別の場所にあり、復元に成功し、交換用ホストで家庭内の復旧目標時間内にJellyfinを再稼働できるなら、これ以上アーキテクチャを複雑にしないでください。測定済みの容量要件や障害ドメイン要件を満たす場合に限り、サービスやホストを追加してください。復旧可能性を支えるのは、明示された状態と復元の実践であり、コンテナの数ではありません。