コンテナの分離はJellyfinのリソースアクセスにどのような影響を与えますか？

コンテナ分離は、Jellyfin の実行境界内でどのファイル、ユーザー、デバイス、ネットワーク、リソース制限を参照できるかを制御することで、リソースへのアクセスを変えます。

コンテナは正常に起動しても、Jellyfin から見るとメディアパスが空だったり、レンダーデバイスへの権限がなかったり、上流サービスを名前解決できなかったり、ホストで利用可能なメモリを下回る上限が設定されていたりすることがあります。重要なのは、可視性と容量の違いです。ネームスペースとマッピングはプロセスが到達できる範囲を決め、cgroup と共有ホストは実際に使用できる CPU、メモリ、I/O の量を決めます。

マウントネームスペースが Jellyfin から見えるファイルシステムを決める

コンテナは、ホストの完全なファイルシステムビューを自動的に継承しません。バインドマウントやボリュームによって、選択したディレクトリを選択したパスに意図的に公開します。そのため、Jellyfin がメディアライブラリを見られるのは、意図したホストパスがプロセスの動作するネームスペースにマッピングされている場合だけです。タイプミスによって、コンテナの起動失敗ではなく、メディアがないように見える有効な空ディレクトリが作られることがあります。

Linux のコンテナ分離では、マウントネームスペースを利用してプロセスに制限されたファイルシステムビューを与えます。マウントネームスペースモデルは、ホストパスがコンテナ外では存在して読み取り可能でも、コンテナ内では完全に存在しない状態になり得る理由を説明しています。Jellyfin が操作する必要があるのは、管理者のホストシェルで見えるパスではなく、自身のネームスペースから見えるパスです。

この境界で重要なのは、永続性と所有者情報です。マウントが見えていても、読み取り専用だったり、誤った UID が所有していたり、ネットワークファイルシステムの準備が遅れて起動時に利用できなかったりすることがあります。問題を Jellyfin のライブラリの不具合と判断する前に、実行中のコンテナ内からパス、マウント種別、読み書きの意図、既知のファイル 1 つを確認してください。

ユーザーとグループのマッピングが、見えるパスで許可される操作を制御する

ファイルシステムが見えることは、権限があることを意味しません。Jellyfin のプロセスには実効ユーザーおよびグループ ID があり、ホストのファイルシステムはその ID、または再マッピングされたユーザーネームスペースに基づいてアクセスを評価します。コンテナでディレクトリを一覧表示できても、マッピングされた認証情報が所有権や ACL ルールと一致しないために、キャッシュファイルの作成、字幕の更新、保護されたメディアの読み取りに失敗することがあります。

ネームスペースではユーザーとグループの ID を再マッピングできます。また Docker では、特定の非 root アカウントでアプリケーションを起動することもできます。コンテナのユーザー分離に関する説明は、権限を減らすことで分離性が向上する一方、Jellyfin が必要とする正確なディレクトリに対して、所有権やグループアクセスを意図的に設定する必要がある理由を示しています。

この境界で重要なのは最小権限です。ホスト全体に広範な権限を与えればテストは通るかもしれませんが、分離性が弱まり、実際の不一致が隠れてしまいます。メディア、設定、キャッシュ、トランスコードの各パスに必要な最小限の読み取りまたは書き込みアクセスを付与し、手動で行ったシェル上の変更に依存せず、デプロイ後も権限モデルが維持されることを確認するためにコンテナを再作成してください。

デバイスのマッピングがハードウェアアクセラレーションの有無を決める

ホストに GPU が搭載されていても、デバイスノードやドライバーインターフェースがコンテナの許可されたビューの外にあるため、Jellyfin から利用できないことがあります。そのため、ハードウェアアクセラレーションにはホストの能力とランタイムへの公開の両方が必要です。デバイスがマッピングされていない、またはプロセスが開けない場合、Jellyfin はソフトウェア処理にフォールバックすることがあり、物理マシンが変わっていなくても CPU 負荷が大きく変化します。

Jellyfin のハードウェア選定ガイドでは、メディアエンジンのサポートと実際に利用可能なアクセラレーションが、トランスコード容量の中心であることを強調しています。ハードウェアアクセラレーションの境界は、サービスを分離した時点でコンテナの問題になります。ランタイムが必要なデバイスやドライバーインターフェースにアクセスできなければ、適切な GPU 世代であっても意味がありません。

障害の境界は、ダッシュボード上の期待ではなく、パスの確認です。コンテナ内にデバイスが存在すること、Jellyfin ユーザーがデバイスを開けること、代表的なトランスコードで意図したハードウェア処理が実際に選択されることを確認してください。リソースの可視性を証明する前に、ソフトウェア処理へのフォールバックを CPU 制限の引き上げで補おうとしてはいけません。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ネットワークネームスペースは到達性を変えるが、新たな帯域幅を生み出すわけではない

ブリッジネットワーク、ホストネットワーク、公開ポート、DNS 名、サービスネットワークは、Jellyfin がクライアントや依存先に到達する方法を変えます。ネットワークネームスペースはアドレスとルーティングテーブルを分離できるため、ホストから到達できるサービスがコンテナからは到達できなかったり、その逆が起きたりします。これは、その下にある物理 Ethernet リンクを変えずに、検出方法や依存関係への経路を変えるものです。

ZimaSpace のサービススタックモデルでは、個別のサービスが独自のネットワーク ID とライフサイクル境界を持ちながら、明示的なルートと共有ホストリソースに依存する仕組みを説明しています。ここではサービスネットワークの境界が役立ちます。コンテナが「起動中」であることは、Jellyfin がプロキシを名前解決できること、リモートマウントに到達できること、クライアントが期待するアドレスを広告できることの証明にはならないからです。

この境界で重要なのは、レイヤーを分けることです。DNS やルートの障害をネットワークスループット不足として診断してはならず、帯域を使い切ったアップリンクをネームスペースモードの切り替えで直すこともできません。名前解決、ルート到達性、待ち受けポート、実効帯域幅を別々の観測としてテストし、選択したネットワークモードが実際のレイヤーに対応していることを確認してください。

cgroup は消費量を制限するが、ホストリソースを非公開にはしない

CPU シェア、メモリ上限、I/O 制御によって、1 つのサービスがホストリソースを無制限に消費するのを防げます。しかし、コンテナが別の物理サーバーになるわけではありません。Jellyfin は、キャッシュ、ストレージキュー、ネットワークインターフェース、メモリ帯域幅、場合によってはアクセラレーターエンジンを、他のワークロードと引き続き競合します。制限は最大割り当て量とスケジューリングポリシーを定義するものであり、専有容量を保証するものではありません。

cgroup のリソース制御モデルは、ネームスペースと cgroup の違いを明確にしています。ネームスペースはプロセスから見える範囲を制御し、cgroup は CPU、メモリ、I/O などのリソースを割り当てたり制限したりします。これにより、正しく分離された Jellyfin コンテナでも、別のコンテナが共有ディスクを飽和させるとバッファリングが発生する理由や、ホスト上の別の場所に空き RAM があっても低いメモリ上限によって回収が強制される理由が分かります。

分離を 2 つのテストで検証します。まずコンテナ内から可視性を証明し、次に通常のピーク負荷を実行して、cgroup の制限とホストの飽和のどちらが先にボトルネックになるかを観測します。サービスの再現性と予測可能性が維持される場合は境界を維持し、必要なデバイスやパスが隠れている場合、または制限によって実際のワークロードが再生期限を維持できない場合は見直してください。