JellyfinにはDockerと仮想マシンのどちらが適している？導入方法を比較

エヴァ・ウォン

IceWhale author

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

Docker vs Virtual Machine for Jellyfin: Which Deployment Route Fits? - Zima Store Online

Dockerは、シンプルな永続マウントとホストデバイスへの直接アクセスを備えた軽量なLinuxサービスが必要な場合にJellyfinに適しています。一方、独立したゲストOSの制御、より強固なカーネル分離、またはハイパーバイザーระดับのライフサイクル管理を重視する場合は、仮想マシンが適しています。ただし、DockerはVM内でも実行できるため、両者は完全な正反対ではありません。仮想化を優先するホームラボでは、これが最も整った第三の選択肢になることもあります。

判断は、「コンテナは常に高速」「VMは常に安全」といった一般論ではなく、GPUアクセラレーションやメディアストレージを含め、実際に必要なハードウェアと復旧方法を基準に行うべきです。

必要な分離境界から始める

DockerコンテナはLinuxホストのカーネルを共有しながら、プロセス、ファイルシステム、ネットワークなどの名前空間を分離します。VMはハイパーバイザーの背後で独自のゲストカーネルを実行します。つまり、VMはより強固なOS境界を作れますが、パッチ適用、バックアップ、起動、メモリやストレージの割り当てが必要なゲストOSも追加されます。

Jellyfinが専用ホストまたはアプリケーション中心のホスト上で動く安定したLinuxサービスの1つであるなら、通常はコンテナの分離で十分です。ホストが実験用プラットフォームである場合、別のLinuxディストリビューションが必要な場合、またはJellyfinの変更をホストのカーネルやパッケージセットから分離したい場合は、VMの分離境界のほうが有用です。

GPUアクセスが最初の実用的な互換性チェックポイント

Linux上のDockerでは、Jellyfinに/dev/driなどのレンダリングデバイスへのアクセスを与え、ホストのドライバースタックを利用できます。Jellyfinのコンテナに関するガイダンスでは、ハードウェアアクセラレーションのためのデバイスマッピングを説明しており、WindowsまたはmacOS上のコンテナ化されたJellyfinは、ハードウェアアクセラレーションによるトランスコードのサポート対象外であることも記載されています。

VMでは、ハイパーバイザーが仮想GPUまたはパススルーによるGPU経路を公開する必要があり、デバイス全体のパススルーを使うと、そのアクセラレーターがゲスト専用になる場合があります。これはドライバーの分離や専用GPUが必要な場合には適した方法ですが、セットアップと復旧に関する依存関係が増えます。

ZimaSpaceによるコンテナ方式のデバイスアクセスとVMパススルーの比較でも、同じ基本的な違いが示されています。共有ホストデバイスノードとゲストによる排他的所有は、異なるデバイス分離の問題を解決します。

VMがデータ層を所有するまでは、Dockerのストレージマッピングのほうが簡単

Jellyfinの設定とキャッシュが永続的なホストパスまたはボリュームに保存され、メディアがローカルディスクやOSにマウントされた共有からバインドマウントされている場合、Dockerはスムーズに動作します。ストレージを最初に認識するのはホストであり、コンテナには必要なパスだけが渡されます。

VMでは、メディアを仮想ディスク、ディスクまたはコントローラーの直接パススルー、あるいはゲスト内のSMB/NFSマウントのどれで提供するかを決める必要があります。VMを使えばJellyfinスタック全体を1つのゲストとして移植可能にできますが、数TBのメディアを仮想ディスクイメージに結び付けると、バックアップや移行が必要以上に大掛かりになる可能性があります。

Featured

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

ZimaCube2

スナップショットのボタンではなく、バックアップとロールバックの範囲を比較する

Dockerでは、Composeなどのデプロイ定義とJellyfinの永続状態を組み合わせた小さなバックアップ単位を作りやすくなります。コンテナを再作成してメディアを再マウントすれば、使い捨てのランタイム層を保存しなくてもアプリケーションを復旧できます。

VMのスナップショットはゲストの状態を手軽に取得できますが、外部メディアの完全なバックアップや、長期利用を想定したデータベースの整合性のあるバックアップが自動的に含まれるわけではありません。既存のハイパーバイザーがゲストのバックアップ、レプリケーション、復元テストを適切に処理できる場合は、運用面で有利です。そうでなければ、VMは復旧すべき層をもう1つ増やすことになります。

オーバーヘッドは主な判断基準ではなく、決着をつける要素として使う

コンテナは通常、別の汎用ゲストOSを起動しないため、メモリとストレージのオーバーヘッドが少なくて済みます。VMでは、ゲストカーネルとサービス用のRAMに加え、OS用の仮想ディスクが必要です。小規模な常時稼働サーバーではこの差が重要になることがありますが、RAMに余裕のあるホストでは、GPU、ストレージ、メンテナンス要件と比べて無視できる場合もあります。

VMが実際の分離要件やドライバー要件を解決するなら、ベンチマーク上の効率だけを理由にDockerを選ばないでください。同様に、VMが管理されていないマウントや認証情報を別のOSで包むだけなら、「セキュリティ」だけを理由にVMを選ぶべきではありません。

ホストの役割に応じて、Docker、VM、または第三の選択肢を選ぶ

Dockerが適しているのは、ホストがLinuxで、オーバーヘッドを抑えたい、永続パスを簡単に文書化できる、必要なGPUを確実にマッピングできる場合です。VMが適しているのは、Jellyfinに独立したOS、より強固なカーネル分離、またはハイパーバイザーによるライフサイクル管理とデバイス所有権が必要な場合です。

Linux VM内のDockerが適しているのは、ホームラボがすでに仮想化を中心に構成されている一方で、移動可能なゲスト内ではコンテナ方式のアプリケーションデプロイを使いたい場合です。VMの境界に明確な役割がある場合にのみ追加の層が正当化されます。そうでなければ、新しい機能を生まない複雑さが増えるだけです。

選択する前に、実際のハードウェアトランスコードを1回実行し、デプロイメントを再起動して、永続状態をクリーンな環境に復元してください。これらのテストに最小限の運用負担で合格する方法が、そのホストにとってより適したJellyfinのデプロイ方法です。