Jitsi Meet è un software di videoconferenza open source che puoi ospitare autonomamente. È una buona alternativa a servizi proprietari come Google Meet o Zoom.
Jitsi Meet può essere integrato con altri strumenti open source come Nextcloud, Rocket.Chat o Synapse (implementazione Matrix) per offrirti una soluzione completa.
Con alcune limitazioni, Jitsi Meet può essere utilizzato gratuitamente sul proprio server. Per le funzionalità premium, puoi optare per Jitsi as a Service dagli sviluppatori Jitsi. Puoi anche distribuirlo sul tuo server? Ti aiuterò con la parte di self-hosting.
Distribuzione di Jitsi Meet con Docker
La distribuzione di Jitsi è incredibilmente facile con Docker. Ti mostrerò i passaggi per la distribuzione di Jitsi. Tratterò sia il proxy inverso che il metodo normale.
Come utilizzare il proxy inverso Nginx con più app DockerScopri come distribuire più servizi Web sullo stesso server utilizzando il proxy inverso Nginx e i contenitori Docker.
Linux HandbookDebdut Chakraborty 
Prerequisiti
Ci sono alcune cose che devono essere risolte prima di procedere.
Conoscenza di base di Docker e container: Questo non è un must, come tutti i nostri tutorial, ma è bello da avere.
Un dominio personalizzato: Questa distribuzione non sarà servita da IP, ovvero ti guiderò attraverso la distribuzione in un dominio (o sottodominio) effettivo con HTTPS. Distribuzioni come HTTP://[alcuni IP]:[alcune porte] vanno bene per il test, ma non servono a nessuno scopo in queste guide.
Un server Linux fisico o nel cloud: Consiglio di usare Linode ma puoi usare qualsiasi altro provider come DigitalOcean, Vultr o UpCloud. La distribuzione in AWS può essere molto specifica per la piattaforma e non ne parlerò qui.
Come da raccomandazione ufficiale, un server con 4 GB di memoria con processore dual-core sarebbe adatto a circa 10-20 utenti.
linode | The Independent Open Cloud for DevelopersLa nostra missione è accelerare l'innovazione rendendo il cloud computing semplice, conveniente e accessibile a tutti.
Linode 
DigitalOcean – Il cloud per sviluppatoriAiutando milioni di sviluppatori a creare, testare, gestire e ridimensionare facilmente applicazioni di qualsiasi dimensione, più velocemente che mai. 
Facoltativamente, la nostra configurazione del proxy inverso: Se vuoi metterlo dietro un proxy inverso in modo da poter distribuire diversi servizi Web sullo stesso server. Se Jitsi è l'unica applicazione che verrà eseguita sul server, non è necessario il proxy inverso.
Modifica dei record DNS
Avere un nome di dominio non è sufficiente. Devi assicurarti che anche i record DNS siano a posto. Per questo tutorial, userò un dominio openexperiment.in che ho in giro da un po' di tempo.
Assicurati di modificare tutte le istanze del dominio dagli esempi al tuo dominio.
Una volta che hai un dominio e distribuito un server (non con Jitsi, solo il server), raccogli gli indirizzi IP del server (entrambi IPv4 e IPv6) e aggiungi rispettivamente i record A e AAAA per ciascuno. Al termine, dovrai anche aggiungere un record CNAME. Puoi aggiungere un sottodominio specifico o, come me, aggiungere una voce jolly (se lo stai ospitando sul dominio principale).
Guarda lo screenshot qui sotto se sei ancora confuso. Ho offuscato gli indirizzi IP effettivi (sono molto riservato ... shhh).
Potrebbe essere necessario attendere un po' di tempo prima che le modifiche DNS abbiano effetto. Puoi verificarlo usando il comando ping.
ping il dominio finché non vedi l'indirizzo IP del tuo server in questo modo -
❯ ping openexperiment.in -4
PING openexperiment.in (xxx.xxx.xxx.xxx) 56(84) bytes of data.
^C64 bytes from xxx.xxx.xxx.xxx: icmp_seq=1 ttl=55 time=36.6 ms
--- openexperiment.in ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 36.610/36.610/36.610/0.000 ms
Puoi anche usare il comando dig per controllare i record DNS.
dig openexperiment.in +nocmd +nocomments
Dovresti vedere qualcosa di simile al seguente
❯ dig openexperiment.in +nocmd +nocomments
;openexperiment.in. IN A
openexperiment.in. 2970 IN A xxx.xxx.xxx.xxx
;; Query time: 1 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sun Mar 07 11:38:20 IST 2021
;; MSG SIZE rcvd: 62
Capire i componenti di Jitsi Meet
Prima di andare avanti, credo sia utile sapere quali sono questi componenti e perché sono importanti, insieme a quelli che utilizzerai per questa distribuzione.
Se non ti interessa, vai ovviamente alla sezione relativa alla distribuzione di questo articolo.
jitsi/web:latest: L'interfaccia utente web di Jitsi Meet, che vedi sul tuo browser, è all'interno di questa immagine. Insieme a Nginx per il server web.
jitsi/prosody:latest: Questo è il server XMPP, questo è il responsabile delle chiamate audio/video o delle chat di testo. Questo può essere considerato il cuore di Jitsi.
jitsi/jicofo:latest: La componente focus del server XMPP, responsabile della gestione delle sessioni video tra i partecipanti e il videobridge, in altre parole, è ciò che gestisce le conferenze. Questo è un altro componente obbligatorio di Jitsi.
jitsi/jvb:latest: Il Jitsi Videobridge è responsabile dell'inoltro dei canali video in entrata a tutti i partecipanti.
Queste sono le parti obbligatorie di una distribuzione Jitsi operativa e le userò solo per questa guida. Ci sono altri componenti come Jibri, Jigasi, ma poiché sono opzionali, li lascerò fuori per ora.
Basta leggere, è ora di fare un po' di lavoro pratico.
Se hai intenzione di distribuirlo insieme a un proxy inverso, assicurati di averlo configurato prima di avvicinarti a questo. Come utilizzare il proxy inverso Nginx con più app Docker Scopri come distribuire più servizi Web sullo stesso server utilizzando il proxy inverso Nginx e contenitori docker.Linux HandbookDebdut Chakraborty Clone il repository docker-jitsi-meet
Questo repository contiene tutti i file di cui avremo bisogno per questa distribuzione (con ovviamente alcune modifiche).
Clona il repository e cambia il tuo PWD nella directory clonata.
git clone https://github.com/jitsi/docker-jitsi-meet jitsi
cd jitsi
Inizia a modificare le variabili di ambiente
Poiché stai utilizzando Docker, devi modificare alcune variabili di ambiente. Inizia copiando il file di configurazione di esempio.
cp env.example .env
Ora apri il .env e guarda le prime 6 variabili di ambiente.
Poiché tutti questi componenti sono fondamentalmente una sorta di server in esecuzione in container, è necessario un modo per assicurarsi che i server siano veramente chi dicono di essere. Questi segreti sono lì per questo motivo. I client devono prima autenticarsi prima di stabilire una connessione.
Non devi impostare questi segreti da solo. C'è già un copione lì per semplificarti la vita. Esegui il comando seguente mentre sei all'interno della directory del repository
./gen-passwords.sh
Una volta eseguito, puoi riaprire il .env file e i segreti dovrebbero essere compilati.
Non avrai bisogno di tutti quei segreti per questa distribuzione, ma lasciali stare, non è necessario rimuoverli o commentarli.
Ora ci saranno tre sottosezioni qui, una per le assegnazioni di variabili comuni (proxy inverso o nessun proxy inverso), un'altra per il proxy inverso e l'ultima per nessun proxy inverso. Tutti vanno al file .env.
Variabili comuni (sia per il metodo proxy inverso che per il metodo proxy non inverso)
Ecco le variabili comuni a entrambi i metodi di distribuzione e le aggiungi nel file .env.
CONFIGURAZIONE: puoi cambia il valore di questo, ma non è necessario. Il valore di questa variabile è una directory nel tuo host, che verrà montata all'interno dei contenitori per memorizzare i dati persistenti. Quindi la modifica dipende interamente da te.
URL_PUBLIC: Il dominio su cui sarà ospitato Jitsi (con il protocollo). Nel mio caso il valore è https://meet.openexperiment.in
ENABLE_AUTH: Vuoi l'autenticazione? Con l'autenticazione, l'utente dovrà inserire un nome utente e una password prima di poter partecipare o creare una riunione. In tal caso, decommenta questa riga e assicurati che sia impostata su 1.
AUTH_TYPE: Se imposti ENABLE_AUTH su 1, imposta questo su "interno". In questo articolo non esaminerò l'autenticazione LDAP o JWT.
RESTART_POLICY: Riavvia la politica dei contenitori. L'impostazione predefinita è unless-stopped . Preferisco always o on-failure .
TZ: Impostalo sul fuso orario del tuo sistema. Poiché i miei server funzionano nel fuso orario UTC, non devo cambiarlo.
Variabili per il metodo proxy non inverso
Se non stai usando il proxy inverso, dovresti aggiungere queste variabili al file .env:
HTTP_PORT , HTTPS_PORT: Cambiali rispettivamente in 80 e 443. Queste sono le porte a cui si legherà il tuo container.
ENABLE_LETSENCRYPT: Impostalo su 1, hai bisogno di HTTPS.
LETSENCRYPT_DOMAIN &LETSENCRYPT_EMAIL: Il dominio su cui sarà ospitata l'istanza e il tuo ID email per le notifiche relative ai certificati.
ENABLE_HTTP_REDIRECT: Impostalo su 1, il traffico HTTP deve essere inoltrato a HTTPS.
ENABLE_HSTS: Ciò, in un certo senso, costringerà i browser a utilizzare una connessione affidabile. Impostalo su 1.
Variabili richieste per reverse proxy
Se hai optato per il proxy inverso, dovresti aggiungere queste variabili al file .env:
DISABLE_HTTPS: Poiché HTTPS verrà gestito dal server Web del proxy inverso, non è necessario che HTTPS sia abilitato da Jitsi stesso.
ENABLE_HTTP_REDIRECT: Non necessario, impostalo su 0. HTTP/HTTPS verrà gestito dal nostro proxy inverso.
VIRTUAL_HOST &LETSENCRYPT_HOST: Queste variabili non sono presenti per impostazione predefinita. Aggiungi questi e, per i valori, utilizza il nome di dominio in cui verrà ospitata l'istanza. Per ulteriori informazioni leggi il mio articolo sul revere proxy.
[SOLO SE SI USA REVERSE PROXY] Modifica il file di composizione
Apri il file docker-compose.yml nel tuo editor di testo preferito.
L'unica definizione di servizio che deve essere modificata è il servizio Web. Modificalo secondo il seguente elenco
- Rimuovi la sezione delle porte. Non è più necessario associare alcuna porta dal container all'host.
- Aggiungi un'altra rete, la stessa rete utilizzata nella configurazione del proxy inverso.
- Definisci la rete alla fine del file di composizione in questo modo
networks:
net:
external: true
Supponendo che il nome della rete sia net , cambialo con quello che hai impostato.
- Aggiungi le variabili d'ambiente
VIRTUAL_HOST&LETSENCRYPT_HOSTcosì
- VIRTUAL_HOST
- LETSENCRYPT_HOST
Distribuisci i container
Una volta terminate tutte le modifiche, puoi distribuire Jitsi con docker-compose up -d comando.
Assicurati che i contenitori del proxy inverso siano in esecuzione SE hai optato per il metodo del proxy inverso.
Hai quasi finito con la distribuzione di Jitsi Meet, fatta eccezione per l'ultimo passaggio che consiste nel creare utenti autenticati per il tuo server Jitsi.
Creazione di utenti autenticati
Se hai abilitato l'autenticazione (con ENABLE_AUTH ), dovrai registrare gli utenti prima di poter utilizzare Jitsi.
Farlo è abbastanza semplice. Vai alla directory del repository clonato ed esegui un comando simile al seguente
docker-compose exec prosody prosodyctl --config=/config/prosody.cfg.lua register [USERNAME] meet.jitsi [PASSWORD]
Puoi anche rimuovere un utente usando unregister comando come ho mostrato qui:
docker-compose exec prosody prosodyctl --config=/config/prosody.cfg.lua unregister [USERNAME] meet.jitsi
Infine, puoi andare avanti e controllare il front-end di Jitsi Meet sull'URL designato in un browser web:
Hai ancora domande o suggerimenti? Non esitare a lasciare un commento.
Se ti piace questo tutorial e vorresti vederci produrre altri contenuti così utili, ti preghiamo di considerare di optare per l'abbonamento Pro o di fare una donazione una tantum per sostenerci :)