Quven Server tourne désormais dans un conteneur

Un conteneur ressemble à une boîte neutre jusqu’au moment où quelque chose a besoin du matériel. Le serveur démarre, la bibliothèque est analysée, les contrôles de santé sont au vert, puis le premier film exige un transcodage et la carte graphique s’avère n’exister qu’en dehors du conteneur. À ce moment-là, vous lisez de la documentation sur les permissions des périphériques au lieu de regarder quoi que ce soit.

Nous voulions que la prise en charge de Docker signifie davantage qu’un Quven qui démarre par hasard dans une image. Le conteneur doit se comporter comme n’importe quel autre Quven Server : détectable sur le réseau domestique, lié au même compte, conservant son état entre les redémarrages, respectant la bibliothèque et capable d’indiquer quel composant matériel effectue le travail. Il est désormais public.

Publier une image ne nous suffisait pas

Un registre accepte tout ce qui arrive au bout d’une compilation, ce qui ne suffit pas à en faire une version publiée. L’image de Quven est construite pour Linux AMD64 et ARM64, publiée sous une seule coordonnée versionnée, signée avec Cosign et accompagnée d’une attestation SPDX, et le manifeste public enregistre l’empreinte de l’index de l’image et de chaque plateforme, détail qui permet de prouver ce qui s’exécute réellement. Cette précision compte le jour où un conteneur est recréé sur une autre machine, car une étiquette de version indique ce que vous avez demandé et une empreinte indique ce qui est réellement arrivé.

L’environnement Compose désigne l’étiquette latest, et ce choix est délibéré. docker compose pull et docker compose up -d apportent chaque version et ses corrections à votre serveur, alors qu’un numéro de version figé empêcherait une correction ultérieure de l’atteindre. Vous savez toujours quelle version est arrivée, puisque chaque manifeste enregistre son empreinte.

La bibliothèque entre, mais elle n’est pas confiée

Un conteneur se remplace facilement, une bibliothèque personnelle beaucoup moins, et la configuration par défaut part de cette différence. Quven conserve sa base de données et sa configuration dans un volume persistant, avec les journaux à côté. Le répertoire multimédia est le seul endroit où il écrit dans votre bibliothèque, et la seule chose qu’il y dépose est un sous-titre qu’il a généré pour un film, à côté de ce film, tandis que le processus lui-même s’exécute sans capacités Linux, ne peut pas élever ses propres privilèges et voit un système de fichiers racine en lecture seule. Ces précautions ne rendent pas sûr un hôte mal administré. Elles donnent toutefois à une installation ordinaire des limites raisonnables avant que quiconque ait réfléchi au durcissement.

Le cycle de vie reste également sans surprise. Recréez le service et l’état est toujours présent. Changez l’image et les chemins des médias restent en place. Revenez en arrière, et l’empreinte précédente désigne toujours exactement ce qui s’exécutait auparavant.

L’accélération matérielle ne tient pas en une case à cocher

Un conteneur voit-il la carte graphique de l’hôte ? Pas de lui-même. NVIDIA, VA-API et V4L2 exposent des interfaces différentes, et le décodage HEVC du Raspberry Pi utilise l’API Request sans état, qui en constitue une quatrième : un montage de périphérique unique censé les couvrir toutes paraît pratique et échoue au premier fichier difficile.

Le paquet publié traite donc les profils matériels comme des alternatives. Commencez par le service de base. Si la lecture par le processeur couvre déjà votre bibliothèque, vous pouvez vous arrêter là. Si l’hôte dispose d’une interface que vous avez vérifiée, ajoutez le profil NVIDIA, Intel/AMD ou ARM correspondant, avec uniquement les périphériques nécessaires. Une valeur manquante échoue avant le démarrage au lieu d’exposer silencieusement l’ensemble de /dev. C’est moins pratique qu’un interrupteur accelerate=true, mais beaucoup plus compréhensible lorsque quelque chose change après une mise à jour du noyau ou d’un pilote.

Testé avec l’image publique

Pour ARM64, nous avons téléchargé l’image publique multi-architecture exacte sur un Raspberry Pi 4, lié un vrai serveur et diffusé en HLS authentifié, avec les profils Compose publiés, ceux-là mêmes que vous téléchargeriez. Le décodage et l’encodage H.264 passaient par V4L2, tandis qu’une source HEVC utilisait le décodeur Request du Pi avec un encodage H.264 matériel et produisait environ une seconde et demie de sortie pour chaque seconde mesurée, et lors d’une lecture manuelle plus longue, la mémoire tampon restait nettement en avance sur la personne qui regardait. Bien que le Pi soit un petit ordinateur peu coûteux, ses blocs matériels accomplissaient le travail pour lequel ils ont été conçus.

Une autre carte ARM ou un NAS peut toutefois exposer des interfaces différentes, et le guide le précise : contrôlez ce qui est réellement actif sur la machine avant de choisir un profil.

Téléchargez une version publiée, pas une promesse

Le parcours rapide est volontairement court. Téléchargez le fichier Compose et le modèle d’environnement, faites pointer QUVEN_MEDIA_DIR vers la bibliothèque, puis validez la configuration, démarrez-la et liez le serveur. Les profils matériels facultatifs viennent ensuite, un par famille de matériel, de sorte que vous n’exécutez que les commandes qui concernent votre machine.

L’image correspond à l’édition Serveur seul. Les clients natifs assurent toujours l’expérience locale, et avec Pro le client web hébergé peut atteindre un serveur lié par l’intermédiaire du relais géré. Docker change l’endroit où vit le serveur, et rien d’autre. Commencez par le téléchargement Docker de la page Téléchargement de Quven, puis suivez le guide complet d’installation avec Docker.

Questions fréquentes