Come configurare un server di registrazione e streaming Jibri per Jitsi Meet

Il manuale Docker di Jitsi documenta un'importante modifica alla distribuzione: a partire dalla versione stable-11146, i suoi container vengono eseguiti con un UID/GID non privilegiato pari a 1000 e le directory dei dati persistenti devono essere scrivibili da tale utente del container. Anche il servizio Jibri non necessita più di questa SYS_ADMINautorizzazione. Le guide precedenti che raccomandano container privilegiati o 777permessi ampi non devono essere copiate in una distribuzione corrente senza aver prima verificato le istruzioni specifiche della versione.

Questa procedura guidata utilizza Docker Compose per un'installazione self-hosted di Jitsi Meet già esistente. Segue un esempio puramente ipotetico: Riverview Team esegue già Jitsi all'indirizzo meet.example.net, memorizza la configurazione in /opt/jitsi-meet-cfg, e desidera che i moderatori registrino le riunioni localmente e occasionalmente le trasmettano in streaming a una destinazione RTMP. Questa è una configurazione di esempio, non una descrizione di un'installazione o di un test reale.

Nota illustrativa: le schermate seguenti sono esempi schematici e non rappresentano immagini di un server reale; l'output dei comandi e gli stati delle riunioni visualizzati sono a scopo puramente illustrativo.

Cosa fa Jibri e di cosa ha bisogno

Jibri è l'infrastruttura di trasmissione di Jitsi per la registrazione o lo streaming live di una conferenza. Si unisce a una riunione tramite una sessione browser, acquisisce l'audio e il video e poi codifica l'output. Una configurazione Jibri funzionante dipende quindi da un accordo tra il servizio web Jitsi, il server XMPP Prosody e Jicofo sull'account di registrazione interno e sulla stanza "brewery" di Jibri, dove si annunciano le istanze disponibili.

Utilizza un'installazione completa di Jitsi Meet di cui sei amministratore; Jibri non può essere collegato al servizio pubblico meet.jit.si come se fosse un tuo server. Il progetto Jibri originale descrive l'esecuzione su una macchina o macchina virtuale separata, senza carichi di lavoro non correlati che utilizzino i suoi dispositivi audio o video. La distribuzione ufficiale con Docker Compose include Jibri come servizio aggiuntivo. Per un'installazione di piccole dimensioni, questo può essere un container separato sull'host di Compose; per un utilizzo continuativo, assegnagli CPU, memoria e spazio su disco dedicati oppure posizionalo su un host con risorse adeguate.

Un'istanza di Jibri può gestire una sola sessione di registrazione o streaming alla volta. Se Riverview prevede sessioni simultanee, dovrebbe pianificare un pool di Jibri con più istanze e tenere conto della configurazione aggiuntiva di loopback audio descritta nel manuale di Jitsi. Aggiungere altri container senza dispositivi audio dedicati non rappresenta un piano di scalabilità completo.

Passaggio 1: Preparare l'ambiente Docker Jitsi Meet

Parti da una release ufficiale di Docker Jitsi Meet e dai relativi file Compose. Mantieni il .envfile e i file Compose della stessa release. Nel file di ambiente, abilita la registrazione:

ENABLE_RECORDING=1

La configurazione Compose di Jitsi utilizza account XMPP interni sia per Jibri che per la sessione del browser del registratore. Imposta password complesse e distinte per Jibri e il registratore e mantienile riservate. Per una nuova installazione, lo gen-passwords.shscript del progetto può generare le password interne del servizio. Questa operazione modifica il file di ambiente, quindi eseguine prima un backup. Se l'installazione di Jitsi è già in esecuzione, non rigenerare tutte le password indiscriminatamente: tutti i componenti in esecuzione devono ricevere le credenziali aggiornate corrispondenti durante un riavvio pianificato.

Nell'esempio di Riverview, ENABLE_RECORDING=1è l'opzione richiesta, mentre il modello di ambiente della release fornisce i nomi e i valori predefiniti per l'utente XMPP, l'utente del registratore, il MUC del birrificio, il percorso di archiviazione e altre opzioni. Non incollare le password in un problema pubblico, in uno screenshot del terminale o in una chat di riunione condivisa.

Passaggio 2: Creare una memoria persistente scrivibile

Le registrazioni devono sopravvivere alla sostituzione del container, quindi la configurazione Compose di Jitsi monta uno storage host persistente per Jibri. Nell'esempio CONFIG=/opt/jitsi-meet-cfg, la directory host è /opt/jitsi-meet-cfg/storage/jibri. Creala prima di avviare il servizio e rendila scrivibile dall'UID/GID 1000 del container:

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

L'elenco numerico dovrebbe mostrare il proprietario e il gruppo 1000. Utilizzare il percorso effettivo CONFIGdal file di configurazione dell'ambiente se diverso. Evitare di modificare ricorsivamente la proprietà dell'intera directory di configurazione di Jitsi; applicare la proprietà necessaria al percorso di archiviazione di Jibri e preservare le registrazioni esistenti quando si modifica un host già configurato. Sui sistemi SELinux, mantenere le impostazioni dell'etichetta del volume dal file Compose ufficiale corrispondente anziché rimuoverle.

La directory di registrazione del container è configurabile; l'esempio documentato nel manuale prevede JIBRI_RECORDING_DIRdi /storage/recordingsmontarla nella directory di archiviazione Jibri dell'host. Prima di modificarla, verifica il modello di ambiente della tua release. Assicurati che l'host disponga di spazio su disco libero sufficiente e di un piano di conservazione: un registratore funzionante può occupare un volume ridotto nel tempo.

Passaggio 3: Avvia Jibri con il file Compose corrispondente

Dalla directory contenente i file ufficiali di Jitsi Compose e il file di configurazione dell'ambiente, avviare lo stack di base con l'override di Jibri:

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

Il manuale ufficiale utilizza questo modello Compose per aggiungere Jibri alla distribuzione Docker. L'override di Jibri definisce l'immagine del container del servizio, la configurazione, i punti di montaggio dello storage e l'allocazione della memoria condivisa. Utilizza il file incluso nella release scelta; evita di mescolare una versione corrente jibri.ymlcon una precedente .envo un bundle Compose.

Verifica se il servizio Jibri rimane attivo e analizza i relativi log insieme a Jicofo e Prosody:

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

Un container in esecuzione è un controllo iniziale, non una prova che la conferenza possa essere registrata. Jibri deve autenticarsi all'host XMPP corretto e unirsi al MUC interno del birrificio previsto. Se i log mostrano errori di autenticazione, confrontare il dominio XMPP, il MUC interno, l'account Jibri, l'account del registratore e le password nel file di ambiente e nella configurazione del servizio generata. I valori devono corrispondere; la modifica della password di un solo componente interromperà l'handshake.

Passaggio 4: Testare una registrazione e uno streaming RTMP

Partecipa a una riunione di prova meet.example.netcon un account moderatore. Nel menu "Altre azioni" della riunione, verifica che le azioni di registrazione e streaming live siano disponibili. Avvia una breve registrazione, attendi il termine della sessione e controlla il percorso di archiviazione host configurato per individuare l'output. La registrazione dovrebbe rimanere presente anche dopo la ricreazione del container Jibri, poiché viene archiviata sul volume host montato anziché solo nel livello scrivibile del container.

Per lo streaming live, utilizzare l'URL di ingestione RTMP e la chiave di streaming forniti dal servizio di destinazione. Inserire i valori correnti del provider nel flusso di lavoro di streaming live di Jitsi e verificare lo stato di anteprima o di ricezione della destinazione. Le dashboard e le etichette dei provider possono cambiare, quindi utilizzare le istruzioni RTMP correnti della destinazione. Trattare la chiave di streaming come una password: non pubblicarla nella chat della riunione o negli screenshot degli articoli. La registrazione su memoria locale e l'invio di uno streaming live a un servizio RTMP sono funzioni di Jibri correlate, ma hanno destinazioni e controlli diversi.

Risoluzione dei problemi tramite il punto di guasto

• Non viene visualizzata alcuna registrazione o azione di streaming: verificare ENABLE_RECORDING=1che sia presente nel file di ambiente attivo e che lo stack Compose corrispondente sia stato ricreato dopo la modifica. Controllare la configurazione web, Prosody e Jicofo generata anziché modificare i file all'interno di un container in esecuzione; Docker rigenera la configurazione del servizio dagli input dell'host.
• L'azione viene visualizzata ma Jibri non riesce a connettersi: esamina i log di Jibri e Jicofo per individuare eventuali errori di autenticazione XMPP o MUC. Verifica che l'host interno, il dominio del registratore, il nome del birrificio e entrambe le password interne corrispondano alla stessa versione di Compose.
• Il container si arresta o si riavvia: controlla i log per individuare un percorso di archiviazione mancante o non scrivibile. Nelle immagini senza privilegi di root correnti, verifica che la directory montata sia scrivibile dall'utente UID/GID 1000. Controlla anche la memoria host e la configurazione della memoria condivisa fornita dal file Compose ufficiale di Jibri.
• La sessione si avvia ma non viene visualizzato alcun file di registrazione: verificare che la directory di registrazione configurata corrisponda al volume host e che la sessione sia stata arrestata/terminata correttamente. Controllare lo spazio libero su disco e i permessi dei file.
• La registrazione funziona ma lo streaming no: ricontrolla l'URL di ingestione RTMP e la chiave di streaming, i requisiti attuali della destinazione e il percorso di rete in uscita dell'host. Consulta i log di Jibri per individuare l'errore di streaming anziché aprire porte in entrata aggiuntive senza prove.

Quando una riunione funziona ma hai bisogno di più registrazioni simultanee, aumenta la capacità in modo mirato. Il limite di una sessione per istanza di Jibri implica che i processi simultanei richiedono più istanze; il manuale di Docker raccomanda inoltre di selezionare interfacce di loopback audio distinte per le diverse istanze. Prima di espandere il pool, testa un'istanza aggiuntiva e verifica che ciascuna istanza sia in grado di creare una registrazione separata.

Utilizzate questi riferimenti ufficiali

Segui le istruzioni relative alla tua implementazione anziché copiare le impostazioni da una versione di Jibri non correlata. Il manuale Docker di Jitsi documenta il flusso di lavoro di Compose, le variabili di registrazione, il percorso di archiviazione, i permessi dei container senza privilegi di root e le note aggiornate di Jibri. Il file README del progetto Jibri spiega il ruolo di Jibri, la limitazione a sessione singola e il modello di configurazione. La definizione del servizio e il modello di ambiente ufficiali di Jibri Compose sono la fonte di riferimento per i nomi delle variabili e i punti di montaggio specifici della release.