Comment configurer un serveur d'enregistrement et de diffusion Jibri pour Jitsi Meet

Le manuel Docker actuel de Jitsi documente un changement important concernant le déploiement : depuis la version [version manquante] stable-11146, ses conteneurs s'exécutent avec un UID/GID 1000 non privilégié, et les répertoires de données persistantes doivent être accessibles en écriture par cet utilisateur. Le service Jibri n'a plus besoin de cette SYS_ADMINcapacité. Les anciens guides recommandant des conteneurs privilégiés ou 777des permissions étendues ne doivent pas être appliqués à un déploiement actuel sans avoir consulté les instructions spécifiques à cette version.

Ce guide utilise Docker Compose pour une installation Jitsi Meet auto-hébergée existante. Il s'appuie sur un exemple purement hypothétique : l'équipe Riverview exécute déjà Jitsi à l'adresse indiquée meet.example.net, stocke sa configuration dans le répertoire approprié /opt/jitsi-meet-cfget souhaite que les modérateurs enregistrent les réunions localement et les diffusent occasionnellement vers une destination RTMP. Il s'agit d'une configuration d'exemple, et non du compte rendu d'une installation ou d'un test réel.

Note d'illustration : Les captures d'écran ci-dessous sont des exemples schématiques et non des captures d'écran d'un serveur réel ; les résultats des commandes et les états des réunions affichés sont donnés à titre d'illustration.

Ce que fait Jibri et ce dont elle a besoin

Jibri est l'infrastructure de diffusion de Jitsi permettant d'enregistrer ou de diffuser en direct une conférence. Elle se connecte à une réunion via une session de navigateur, capture l'audio et la vidéo, puis encode le flux. Le bon fonctionnement de Jibri repose donc sur la concordance entre le service web Jitsi, le serveur XMPP Prosody et Jicofo concernant le compte d'enregistrement interne et la salle Jibri (« brasserie ») où les instances disponibles s'annoncent.

Utilisez une installation complète de Jitsi Meet que vous administrez ; Jibri ne peut pas être connecté au service public meet.jit.si comme s'il s'agissait de votre propre serveur. Le projet Jibri recommande de l'exécuter sur une machine ou une machine virtuelle distincte, sans aucune autre charge de travail utilisant ses périphériques d'affichage ou audio. Le déploiement officiel Docker Compose intègre Jibri en tant que service supplémentaire. Pour une installation de petite taille, cela peut être un conteneur séparé sur l'hôte Compose ; pour une utilisation prolongée, allouez-lui du processeur, de la mémoire et de l'espace disque dédiés, ou installez-le sur un hôte doté des ressources appropriées.

Une instance Jibri ne peut gérer qu'une seule session d'enregistrement ou de diffusion à la fois. Si Riverview prévoit des sessions simultanées, il est recommandé de prévoir un pool Jibri avec plusieurs instances et de prendre en compte la configuration de bouclage audio supplémentaire décrite dans le manuel de Jitsi. L'ajout de conteneurs supplémentaires sans périphériques audio dédiés ne constitue pas une solution de mise à l'échelle complète.

Étape 1 : Préparer l’environnement Docker Jitsi Meet

Utilisez une version officielle de Docker Jitsi Meet et ses fichiers Compose correspondants. Conservez le .envfichier et les fichiers Compose de la même version. Dans le fichier d'environnement, activez l'enregistrement :

ENABLE_RECORDING=1

La configuration Compose de Jitsi utilise des comptes XMPP internes pour Jibri et pour la session du navigateur d'enregistrement. Définissez des mots de passe robustes et distincts pour Jibri et l'enregistreur, et conservez-les confidentiels. Pour une nouvelle installation, le gen-passwords.shscript du projet peut générer les mots de passe des services internes. Ce script modifie le fichier d'environnement ; il est donc impératif d'en effectuer une sauvegarde au préalable. Si l'installation Jitsi est déjà en cours d'exécution, ne régénérez pas systématiquement tous les mots de passe : les composants en cours d'exécution doivent tous recevoir les identifiants mis à jour correspondants lors d'un redémarrage planifié.

Dans l'exemple de Riverview, ENABLE_RECORDING=1il s'agit du commutateur requis, tandis que le modèle d'environnement de la version fournit les noms et les valeurs par défaut pour l'utilisateur XMPP, l'utilisateur de l'enregistreur, le MUC de la brasserie, le chemin de stockage et d'autres options. Ne collez pas les mots de passe dans un problème public, une capture d'écran de terminal ou une conversation de réunion partagée.

Étape 2 : Créer un stockage persistant accessible en écriture

Les enregistrements doivent être conservés même après le remplacement du conteneur. C'est pourquoi la configuration Compose de Jitsi monte un stockage hôte persistant pour Jibri. Dans cet exemple CONFIG=/opt/jitsi-meet-cfg, le répertoire hôte est ` /opt/jitsi-meet-cfg/storage/jibri<chemin_vers_l'hôte>`. Créez-le avant de démarrer le service et rendez-le accessible en écriture par l'UID/GID 1000 du conteneur.

sudo mkdir -p /opt/jitsi-meet-cfg/storage/jibri
sudo chown 1000:1000 /opt/jitsi-meet-cfg/storage/jibri
sudo chmod 750 /opt/jitsi-meet-cfg/storage/jibri
ls -ldn /opt/jitsi-meet-cfg/storage/jibri

La liste numérique doit indiquer le propriétaire et le groupe 1000. CONFIGSi le chemin diffère de celui de votre fichier d'environnement, utilisez-le. Évitez de modifier récursivement le propriétaire de l'ensemble du répertoire de configuration Jitsi ; appliquez le propriétaire nécessaire au chemin de stockage Jibri et conservez les enregistrements existants lors de la modification d'un hôte établi. Sur les systèmes SELinux, conservez les paramètres d'étiquette de volume du fichier Compose officiel correspondant au lieu de les supprimer.

Le répertoire d'enregistrement du conteneur est configurable ; l'exemple documenté dans le manuel JIBRI_RECORDING_DIRest /storage/recordingsmonté sous le répertoire de stockage Jibri de l'hôte. Consultez le modèle d'environnement de votre version avant toute modification. Assurez-vous que l'hôte dispose d'un espace disque libre suffisant et d'un plan de rétention : un enregistreur en activité peut saturer un petit volume au fil du temps.

Étape 3 : Lancez Jibri avec le fichier Compose correspondant

Depuis le répertoire contenant les fichiers officiels de Jitsi Compose et le fichier d'environnement configuré, démarrez la pile de base avec la substitution Jibri :

docker compose -f docker-compose.yml -f jibri.yml up -d

Le manuel officiel utilise ce modèle Compose pour ajouter Jibri au déploiement Docker. La configuration Jibri définit l'image du conteneur du service, sa configuration, les points de montage de stockage et l'allocation de mémoire partagée. Utilisez le fichier fourni avec la version choisie ; évitez de mélanger une version actuelle jibri.ymlavec une version plus ancienne .envou un bundle Compose.

Vérifiez si le service Jibri reste opérationnel et consultez ses journaux conjointement avec ceux de Jicofo et Prosody :

docker compose ps jibri
docker compose logs --tail=100 jibri jicofo prosody

Le lancement d'un conteneur constitue une vérification initiale, mais ne garantit pas l'enregistrement de la conférence. Jibri doit s'authentifier auprès du serveur XMPP approprié et rejoindre le groupe de communication multilingue (MUC) interne prévu. En cas d'échec d'authentification, comparez le domaine XMPP, le MUC interne, le compte Jibri, le compte d'enregistrement et les mots de passe entre le fichier d'environnement et la configuration de service générée. Ces valeurs doivent correspondre ; la modification du mot de passe d'un seul composant interrompt l'établissement de la connexion.

Étape 4 : Tester un enregistrement et un flux RTMP

Rejoignez une réunion test meet.example.netavec un compte modérateur. Dans le menu « Plus d'actions » de la réunion, vérifiez que l'enregistrement et la diffusion en direct sont disponibles. Lancez un court enregistrement, attendez la fin de la session et vérifiez le chemin de stockage configuré sur l'hôte pour trouver le fichier de sortie. L'enregistrement devrait rester présent après la recréation du conteneur Jibri, car il est stocké sur le volume hôte monté et non uniquement dans la couche accessible en écriture du conteneur.

Pour une diffusion en direct, utilisez l'URL d'ingestion RTMP et la clé de flux fournies par le service de destination. Saisissez les valeurs actuelles du fournisseur dans le flux de travail de diffusion en direct de Jitsi et vérifiez l'état de prévisualisation ou de réception de la destination. Les tableaux de bord et les libellés des fournisseurs peuvent changer ; utilisez donc les instructions RTMP actuelles de la destination. Traitez la clé de flux comme un mot de passe : ne la publiez pas dans le chat des réunions ni dans les captures d'écran d'articles. L'enregistrement sur un stockage local et l'envoi d'un flux en direct vers un service RTMP sont des fonctions Jibri liées, mais elles ont des destinations et des vérifications différentes.

Dépannage par point de défaillance

• Aucune action d'enregistrement ou de diffusion n'apparaît : vérifiez ENABLE_RECORDING=1que la configuration est présente dans le fichier d'environnement actif et que la pile Compose correspondante a été recréée après la modification. Consultez la configuration web, Prosody et Jicofo générée au lieu de modifier les fichiers dans un conteneur en cours d'exécution ; Docker régénère la configuration des services à partir des entrées de l'hôte.
• L'action apparaît, mais Jibri ne parvient pas à se connecter : consultez les journaux Jibri et Jicofo pour détecter les erreurs d'authentification XMPP ou MUC. Vérifiez que l'hôte interne, le domaine de l'enregistreur, le nom de la brasserie et les deux mots de passe internes correspondent à la même version de Compose.
• Le conteneur s'arrête ou redémarre : vérifiez ses journaux pour détecter un chemin de stockage manquant ou inaccessible en écriture. Sur les images actuelles sans privilèges root, assurez-vous que le répertoire monté est accessible en écriture par l'UID/GID 1000. Vérifiez également la mémoire de l'hôte et la configuration de la mémoire partagée fournie par le fichier Jibri Compose officiel.
• La session démarre, mais aucun fichier d'enregistrement n'apparaît : vérifiez que le répertoire d'enregistrement configuré correspond bien au volume hôte et que la session s'est arrêtée/terminée correctement. Vérifiez l'espace disque disponible et les permissions des fichiers.
• L'enregistrement fonctionne, mais la diffusion en continu échoue : vérifiez l'URL d'ingestion RTMP et la clé de flux, les exigences actuelles de la destination et le chemin réseau sortant de l'hôte. Consultez les journaux Jibri pour identifier la cause de l'échec de la diffusion en continu au lieu d'ouvrir des ports entrants supplémentaires sans preuve.

Lorsqu'une réunion fonctionne mais que vous avez besoin de davantage d'enregistrements simultanés, augmentez la capacité de manière ciblée. La limite d'une session par instance imposée par Jibri implique que les tâches simultanées nécessitent plus d'instances ; le manuel Docker recommande également de sélectionner des interfaces de bouclage audio distinctes pour plusieurs instances. Testez une instance supplémentaire avant d'étendre le pool et vérifiez que chaque instance peut effectuer un enregistrement distinct.

Utilisez ces références officielles

Suivez les instructions correspondant à votre déploiement plutôt que de copier les paramètres d'une version Jibri non compatible. Le manuel Docker de Jitsi décrit le flux de travail Compose, l'enregistrement des variables, le chemin de stockage, les permissions des conteneurs sans privilèges root et les notes Jibri actuelles. Le fichier README du projet Jibri explique le rôle de Jibri, la limitation à une seule session et son modèle de configuration. La définition de service et le modèle d'environnement officiels de Jibri Compose font foi pour les noms de variables et les points de montage spécifiques à chaque version.