Docker ou machine virtuelle pour Jellyfin : quelle méthode de déploiement vous convient ?

Docker convient à Jellyfin lorsque vous recherchez un service Linux léger avec des montages persistants simples et un accès direct aux périphériques de l’hôte ; une machine virtuelle convient lorsque le contrôle indépendant du système invité, une isolation renforcée du noyau ou la gestion du cycle de vie au niveau de l’hyperviseur sont plus importants. Ils ne sont pas parfaitement opposés, car Docker peut également fonctionner dans une machine virtuelle, ce qui constitue souvent la troisième option la plus propre pour un laboratoire domestique axé sur la virtualisation.

La décision doit être prise en fonction du matériel et du plan de récupération dont vous avez réellement besoin, notamment pour l’accélération GPU et le stockage multimédia, plutôt qu’en se fondant sur l’affirmation générale selon laquelle les conteneurs sont toujours plus rapides ou les machines virtuelles toujours plus sûres.

Commencez par définir la limite d’isolation dont vous avez réellement besoin

Un conteneur Docker partage le noyau Linux de l’hôte tout en isolant les processus, les systèmes de fichiers, les réseaux et d’autres espaces de noms. Une machine virtuelle exécute son propre noyau invité derrière un hyperviseur. Cela signifie qu’une machine virtuelle crée une limite plus forte au niveau du système d’exploitation, mais ajoute également un système invité qui doit être corrigé, sauvegardé et démarré, et auquel il faut allouer de la mémoire et du stockage.

Si Jellyfin est un service Linux stable sur un hôte dédié ou principalement consacré aux applications, la limite d’un conteneur est généralement suffisante. Si l’hôte est une plateforme d’expérimentation, si vous avez besoin d’une autre distribution Linux ou si vous souhaitez isoler les modifications de Jellyfin du noyau et de l’ensemble de paquets de l’hôte, la limite d’une machine virtuelle présente davantage d’intérêt.

L’accès au GPU est le premier obstacle pratique de compatibilité

Avec Docker sous Linux, Jellyfin peut recevoir l’accès à des périphériques de rendu tels que /dev/dri et utiliser la pile de pilotes de l’hôte. La documentation de Jellyfin sur les conteneurs décrit le mappage des périphériques pour l’accélération matérielle et précise également que l’utilisation de Jellyfin en conteneur sous Windows ou macOS n’est pas une solution prise en charge pour le transcodage accéléré matériellement.

Une machine virtuelle a besoin que l’hyperviseur expose un chemin GPU virtuel ou en passthrough, et le passthrough de l’intégralité du périphérique peut rendre l’accélérateur exclusif à cet invité. Cela peut être la meilleure solution pour séparer les pilotes ou utiliser un GPU dédié, mais cela augmente les dépendances liées à la configuration et à la récupération.

La comparaison de ZimaSpace entre l’accès aux périphériques de type conteneur et le passthrough vers une machine virtuelle montre la même distinction fondamentale : les nœuds de périphériques partagés de l’hôte et la propriété exclusive par l’invité répondent à des problèmes différents d’isolation des périphériques.

Le mappage du stockage est plus simple avec Docker jusqu’à ce que la machine virtuelle gère la couche de données

Docker fonctionne efficacement lorsque la configuration et le cache de Jellyfin sont stockés dans des chemins ou volumes persistants de l’hôte, et que les contenus multimédias sont montés via des bind mounts depuis des disques locaux ou un partage monté par le système d’exploitation. L’hôte voit d’abord le stockage ; le conteneur ne reçoit que les chemins dont il a besoin.

Dans une machine virtuelle, déterminez si les contenus multimédias seront accessibles via des disques virtuels, un passthrough direct du disque ou du contrôleur, ou un montage SMB/NFS à l’intérieur de l’invité. Une machine virtuelle peut rendre l’ensemble de la pile Jellyfin portable sous la forme d’un seul invité, mais rattacher plusieurs téraoctets de contenus multimédias à une image de disque virtuel peut transformer la sauvegarde et la migration en opérations bien plus lourdes que nécessaire.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Comparez l’étendue de la sauvegarde et de la restauration, pas les boutons de capture instantanée

Docker favorise de petites unités de sauvegarde : la définition Compose ou une autre définition de déploiement, ainsi que l’état persistant de Jellyfin. Recréez le conteneur, remontez les contenus multimédias et l’application peut fonctionner à nouveau sans conserver la couche d’exécution éphémère.

Une capture instantanée de machine virtuelle peut enregistrer commodément l’état de l’invité, mais elle ne constitue pas automatiquement une sauvegarde complète des contenus multimédias externes ni une sauvegarde cohérente à long terme de la base de données. L’avantage est opérationnel lorsque votre hyperviseur existant gère déjà correctement les sauvegardes, la réplication et les tests de restauration des invités ; sinon, la machine virtuelle ajoute une couche supplémentaire à récupérer.

Utilisez la surcharge comme critère de départage, pas comme verdict principal

Les conteneurs entraînent généralement moins de surcharge en mémoire et en stockage, car ils ne démarrent pas un autre système d’exploitation invité généraliste. Une machine virtuelle a besoin de mémoire vive pour le noyau et les services invités, ainsi que de disques virtuels pour le système d’exploitation. Pour un petit serveur toujours allumé, cette différence peut compter ; pour un hôte doté de suffisamment de mémoire vive, elle peut être négligeable par rapport aux exigences liées au GPU, au stockage et à la maintenance.

Ne choisissez pas Docker uniquement pour son efficacité dans les benchmarks si une machine virtuelle répond à un véritable besoin d’isolation ou de pilotes. De même, ne choisissez pas une machine virtuelle uniquement pour des raisons de « sécurité » si elle ne fait qu’envelopper les mêmes montages et identifiants non gérés dans un autre système d’exploitation.

Choisissez Docker, une machine virtuelle ou la troisième voie selon le rôle de votre hôte

Docker est préférable lorsque l’hôte est sous Linux, que vous recherchez une faible surcharge, que les chemins persistants sont faciles à documenter et que le GPU requis peut être mappé de manière fiable. Une machine virtuelle est préférable lorsque Jellyfin a besoin d’un système d’exploitation indépendant, d’une séparation plus forte du noyau ou d’une gestion du cycle de vie et de la propriété des périphériques par l’hyperviseur.

Docker dans une machine virtuelle Linux est préférable lorsque votre laboratoire domestique est déjà axé sur la virtualisation, mais que vous souhaitez tout de même déployer les applications comme des conteneurs à l’intérieur d’un invité déplaçable. Cette couche supplémentaire n’est justifiée que si la limite de la machine virtuelle a une fonction ; sinon, elle ajoute de la complexité sans nouvelle capacité.

Avant de choisir, effectuez un véritable transcodage matériel, redémarrez le déploiement et restaurez l’état persistant sur une cible propre. La solution qui réussit ces tests avec le moins de contraintes opérationnelles est le meilleur déploiement Jellyfin pour cet hôte.