Cómo configurar un servidor de grabación y transmisión Jibri para Jitsi Meet

El manual actual de Docker de Jitsi documenta un cambio importante en la implementación: desde la versión stable-11146, sus contenedores se ejecutan como un usuario sin privilegios (UID/GID 1000), y los directorios de datos persistentes deben ser escribibles por ese usuario del contenedor. El servicio Jibri tampoco necesita ya esta SYS_ADMINcapacidad. Las guías antiguas que recomiendan contenedores con privilegios o 777permisos amplios no deben copiarse en una implementación actual sin consultar las instrucciones específicas de la versión.

Este tutorial utiliza Docker Compose para una instalación autohospedada de Jitsi Meet. Sigue un ejemplo claramente hipotético: Riverview Team ya ejecuta Jitsi en meet.example.net, almacena la configuración en /opt/jitsi-meet-cfgy desea que los moderadores graben las reuniones localmente y, ocasionalmente, las transmitan a un destino RTMP. Esta es una configuración de ejemplo, no un informe de una instalación o prueba real.

Nota ilustrativa: Las vistas de pantalla que se muestran a continuación son ejemplos esquemáticos, no capturas de un servidor real; la salida de comandos y los estados de las reuniones que se muestran son ilustrativos.

Qué hace Jibri y qué necesita

Jibri es la infraestructura de transmisión de Jitsi para grabar o transmitir en directo una conferencia. Se une a una reunión a través de una sesión del navegador, captura el audio y el vídeo, y luego codifica la salida. Por lo tanto, una configuración de Jibri que funcione correctamente depende de que el servicio web de Jitsi, el servidor XMPP de Prosody y Jicofo acuerden la cuenta de grabación interna y la sala de Jibri donde se anuncian las instancias disponibles.

Utilice una instalación completa de Jitsi Meet que usted administre; Jibri no se puede conectar al servicio público meet.jit.si como si fuera su propio servidor. El proyecto Jibri original describe su ejecución en una máquina o máquina virtual independiente, sin ninguna carga de trabajo ajena que utilice sus dispositivos de pantalla o audio. El paquete de implementación oficial de Docker Compose incluye Jibri como un servicio adicional. Para una instalación pequeña, puede ser un contenedor independiente en el host de Compose; para un uso prolongado, asígnele CPU, memoria y capacidad de disco dedicadas o colóquelo en un host con los recursos adecuados.

Una instancia de Jibri puede gestionar una sesión de grabación o transmisión a la vez. Si Riverview prevé sesiones concurrentes, debería planificar un grupo de Jibri con varias instancias y tener en cuenta la configuración adicional de bucle de audio descrita en el manual de Jitsi. Añadir más contenedores sin dispositivos de audio exclusivos no constituye un plan de escalado completo.

Paso 1: Preparar el entorno Docker Jitsi Meet

Comience con una versión oficial de Docker Jitsi Meet y sus archivos Compose correspondientes. Mantenga el .envarchivo y los archivos Compose de la misma versión. En el archivo de entorno, habilite la grabación:

ENABLE_RECORDING=1

La configuración de Jitsi Compose utiliza cuentas XMPP internas tanto para Jibri como para la sesión del navegador de grabación. Establezca contraseñas seguras y distintas para Jibri y la sesión del navegador, y manténgalas privadas. Para una pila completamente nueva, el gen-passwords.shscript del proyecto puede generar las contraseñas internas del servicio. Esto modifica el archivo de entorno, por lo que debe realizar una copia de seguridad previamente. Si la pila de Jitsi ya está en funcionamiento, no regenere todas las contraseñas: todos los componentes en ejecución deben recibir las credenciales actualizadas correspondientes durante un reinicio planificado.

En el ejemplo de Riverview, ENABLE_RECORDING=1se requiere el interruptor, mientras que la plantilla de entorno de la versión proporciona los nombres y valores predeterminados para el usuario XMPP, el usuario de la grabadora, el MUC de la cervecería, la ruta de almacenamiento y otras opciones. No pegue contraseñas en un problema público, una captura de pantalla de terminal o un chat de reunión compartida.

Paso 2: Crear almacenamiento persistente con capacidad de escritura

Las grabaciones deben sobrevivir al reemplazo del contenedor, por lo que la configuración de Jitsi Compose monta almacenamiento persistente en el host para Jibri. Con el ejemplo CONFIG=/opt/jitsi-meet-cfg, el directorio del host es /opt/jitsi-meet-cfg/storage/jibri. Créelo antes de iniciar el servicio y hágalo escribible por el UID/GID 1000 del contenedor:

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 lista numérica debe mostrar el propietario y el grupo 1000. Si la ruta es diferente, utilice la ruta real CONFIGde su archivo de entorno. Evite cambiar recursivamente la propiedad de todo el directorio de configuración de Jitsi; aplique la propiedad necesaria a la ruta de almacenamiento de Jibri y conserve las grabaciones existentes al ajustar un host establecido. En sistemas SELinux, mantenga la configuración de la etiqueta de volumen del archivo Compose oficial correspondiente en lugar de eliminarla.

El directorio de grabación del contenedor es configurable; el ejemplo documentado en el manual JIBRI_RECORDING_DIRes /storage/recordings, montado debajo del directorio de almacenamiento Jibri del host. Verifique la plantilla de entorno de su versión antes de modificarla. Confirme que el host tenga suficiente espacio libre en disco y un plan de retención: un grabador en funcionamiento puede llenar un pequeño volumen con el tiempo.

Paso 3: Inicie Jibri con el archivo Compose correspondiente.

Desde el directorio que contiene los archivos oficiales de Jitsi Compose y el archivo de entorno configurado, inicie la pila base con la anulación de Jibri:

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

El manual oficial utiliza este patrón de Compose para añadir Jibri al despliegue de Docker. La configuración de Jibri define la imagen del contenedor del servicio, la configuración, los puntos de montaje del almacenamiento y la asignación de memoria compartida. Utilice el archivo incluido con la versión elegida; evite mezclar una versión actual jibri.ymlcon una anterior .envo con un paquete de Compose antiguo.

Comprueba si el servicio Jibri sigue activo y revisa sus registros junto con Jicofo y Prosody:

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

Un contenedor en ejecución es una verificación inicial, no una prueba de que la conferencia se pueda grabar. Jibri debe autenticarse en el host XMPP correcto y unirse al MUC interno de Brewery previsto. Si los registros muestran fallos de autenticación, compare el dominio XMPP, el MUC interno, la cuenta de Jibri, la cuenta del grabador y las contraseñas en el archivo de entorno y la configuración de servicio generada. Los valores deben coincidir; cambiar la contraseña de un solo componente interrumpirá el protocolo de enlace.

Paso 4: Pruebe una grabación y una transmisión RTMP.

Únase a una reunión de prueba meet.example.netcon una cuenta de moderador. En el menú "Más acciones" de la reunión, verifique que las acciones de grabación y transmisión en vivo estén disponibles. Comience con una grabación breve, espere a que finalice la sesión e inspeccione la ruta de almacenamiento del host configurada para ver el resultado. La grabación debería permanecer presente después de que se vuelva a crear el contenedor de Jibri, ya que se almacena en el volumen del host montado y no solo en la capa de escritura del contenedor.

Para una transmisión en vivo, utilice la URL de ingesta RTMP y la clave de transmisión proporcionadas por el servicio de destino. Ingrese los valores actuales del proveedor en el flujo de trabajo de transmisión en vivo de Jitsi y verifique el estado de vista previa o recepción del destino. Los paneles y etiquetas del proveedor pueden cambiar, así que utilice las instrucciones RTMP actuales del destino. Trate la clave de transmisión como una contraseña: no la publique en el chat de la reunión ni en las capturas de pantalla de los artículos. Grabar en el almacenamiento local y enviar una transmisión en vivo a un servicio RTMP son funciones relacionadas de Jibri, pero tienen destinos y verificaciones diferentes.

Solucionar problemas en el punto de fallo

• No aparece ninguna grabación ni transmisión: Confirme ENABLE_RECORDING=1que esté presente en el archivo de entorno activo y que la pila de Compose correspondiente se haya recreado después del cambio. Compruebe la configuración generada de web, Prosody y Jicofo en lugar de editar archivos dentro de un contenedor en ejecución; Docker regenera la configuración del servicio a partir de las entradas del host.
• La acción aparece, pero Jibri no puede unirse: revise los registros de Jibri y Jicofo en busca de errores de autenticación XMPP o MUC. Verifique el host interno, el dominio del grabador, el nombre de la cervecería y ambas contraseñas internas con la misma versión de Compose.
• El contenedor finaliza o se reinicia: revise sus registros para detectar si falta alguna ruta de almacenamiento o si esta no es editable. En las imágenes sin privilegios de administrador, verifique que el directorio montado sea editable por el UID/GID 1000. Compruebe también la memoria del host y la configuración de memoria compartida proporcionada por el archivo Jibri Compose oficial.
• La sesión se inicia, pero no aparece ningún archivo de grabación: Confirme que el directorio de grabación configurado se corresponde con el volumen del host y que la sesión se detuvo/finalizó correctamente. Compruebe el espacio libre en disco y los permisos de archivo.
• La grabación funciona, pero la transmisión falla: revise la URL de ingesta RTMP y la clave de transmisión, los requisitos actuales del destino y la ruta de red de salida del host. Consulte los registros de Jibri para detectar el fallo de transmisión en lugar de abrir puertos de entrada adicionales sin evidencia.

Cuando una reunión funciona pero se necesitan más grabaciones simultáneas, aumente la capacidad de forma planificada. El límite de una sesión por instancia de Jibri implica que las tareas concurrentes requieren más instancias; el manual de Docker también recomienda seleccionar interfaces de bucle de audio distintas para varias instancias. Pruebe una instancia adicional antes de ampliar el grupo y verifique que cada instancia pueda crear una grabación independiente.

Utilice estas referencias oficiales.

Siga las instrucciones que correspondan a su implementación en lugar de copiar la configuración de una versión de Jibri no relacionada. El manual de Jitsi Docker documenta el flujo de trabajo de Compose, las variables de registro, la ruta de almacenamiento, los permisos de contenedores sin privilegios de administrador y las notas actuales de Jibri. El archivo README del proyecto Jibri explica la función de Jibri, la limitación de sesión única y el modelo de configuración. La definición oficial del servicio Jibri Compose y la plantilla de entorno son la fuente de información fidedigna para los nombres de variables y los puntos de montaje específicos de cada versión.