Ricerca nel sito web

Come ospitare autonomamente Jitsi Meet con Docker [Guida passo passo]

Guida completa per principianti per distribuire un'istanza Jitsi Meet con Docker su un server Linux.

Jitsi Meet è un software di videoconferenza open source che puoi ospitare autonomamente. È una buona alternativa ai 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

Distribuire Jitsi è incredibilmente semplice con Docker. Ti mostrerò i passaggi per la distribuzione di Jitsi. Tratterò sia il proxy inverso che il metodo normale.

Prerequisiti

Ci sono alcune cose di cui occuparsi prima di procedere.

Conoscenza di base di Docker e dei contenitori: non è un must, come tutti i nostri tutorial, ma è bello averlo.

Un dominio personalizzato: questa distribuzione non sarà servita da IP, ovvero ti guiderò attraverso la distribuzione sotto un dominio (o sottodominio) effettivo con HTTPS. Distribuzioni come HTTP://[alcuni IP]:[alcune porte] vanno bene per i test, ma non servono ad alcuno scopo in queste guide.

Un server Linux fisico o nel cloud: consiglio di utilizzare Linode ma puoi utilizzare qualsiasi altro provider come DigitalOcean, Vultr o UpCloud. La distribuzione in AWS può essere molto specifica per la piattaforma e non ne parlerò qui.

Secondo le raccomandazioni ufficiali, un server con 4 GB di memoria e processore dual-core sarebbe adatto per circa 10-20 utenti.

Facoltativamente, la nostra configurazione del proxy inverso: se desideri 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. È necessario assicurarsi che siano presenti anche i record DNS. Per questo tutorial utilizzerò il dominio openexperiment.in che ho in giro da un bel po'.

Assicurati di modificare tutte le istanze del dominio dagli esempi al tuo dominio.

Una volta che hai un dominio e hai 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. Fatto ciò, dovrai anche aggiungere un record CNAME. Puoi aggiungere un sottodominio specifico o, come me, aggiungere una voce con carattere 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 affinché le modifiche DNS abbiano effetto. Puoi verificarlo utilizzando 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

Comprendere i componenti di Jitsi Meet

Prima di andare avanti, credo che sia utile sapere quali sono questi componenti e perché sono importanti, insieme a quali utilizzerai per questa distribuzione.

Se non ti interessa, passa ovviamente alla sezione di distribuzione di questo articolo.

jitsi/web:latest: L'interfaccia utente web di Jitsi Meet, che vedi sul tuo browser, si trova all'interno di questa immagine. Insieme a Nginx per il server web.

jitsi/prosody:latest: Questo è il server XMPP, questo è 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, è questo che gestisce le conferenze. Questo è un altro componente obbligatorio di Jitsi.

jitsi/jvb:latest: Jitsi Videobridge è responsabile della trasmissione dei canali video in entrata a tutti i partecipanti.

Queste sono le parti obbligatorie di una distribuzione operativa di Jitsi e le utilizzerò solo per questa guida. Ci sono altri componenti come Jibri, Jigasi, ma poiché sono opzionali, per ora li lascerò fuori.

Basta leggere, è tempo di lavorare sul campo.

Clona 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 la tua 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 file .env e osserva le prime 6 variabili di ambiente.

Poiché tutti questi componenti sono fondamentalmente una sorta di server in esecuzione in contenitori, è necessario un modo per assicurarsi che i server siano realmente chi dicono di essere. Questi segreti sono lì per questo motivo. I client devono autenticarsi prima di stabilire una connessione.

Non devi impostare questi segreti da solo. C'è già una sceneggiatura lì per semplificarti la vita. Esegui il comando seguente mentre ti trovi nella directory del repository

./gen-passwords.sh

Una volta eseguito, puoi riaprire il file .env e i segreti dovrebbero essere compilati.

Non avrai bisogno di tutti questi segreti per questa distribuzione, ma lasciali stare, non è necessario rimuoverli o commentarli.

Ora ci saranno tre sottosezioni qui, una per le assegnazioni delle variabili comuni (reverse proxy 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 quello non proxy inverso)

Ecco le variabili comuni a entrambi i metodi di distribuzione e aggiungile nel file .env.

CONFIG: Puoi puoi modificare il valore di questo, ma non è necessario. Il valore di questa variabile è una directory nel tuo host, che verrà montata tramite bind all'interno dei contenitori per archiviare dati persistenti. Quindi modificarlo dipende interamente da te.

PUBLIC_URL: il dominio Jitsi verrà ospitato (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". Non esaminerò l'autenticazione LDAP o JWT in questo articolo.

RESTART_POLICY: politica di riavvio dei contenitori. Il valore predefinito è a meno che non venga interrotto. Preferisco sempre o in caso di fallimento.

TZ: impostalo sul fuso orario del tuo sistema. Poiché i miei server funzionano nel fuso orario UTC, non devo modificarlo.

Variabili per il metodo proxy non inverso

Se non utilizzi 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 collegherà il tuo contenitore.

ENABLE_LETSENCRYPT: impostalo su 1, è necessario HTTPS.

LETSENCRYPT_DOMAIN e LETSENCRYPT_EMAIL: il dominio su cui verrà ospitata la tua istanza e il tuo ID e-mail per le notifiche relative al certificato.

ENABLE_HTTP_REDIRECT: impostalo su 1, il traffico HTTP deve essere inoltrato a HTTPS.

ENABLE_HSTS: questo, in un certo senso, obbligherà i browser a utilizzare una connessione attendibile. Impostalo su 1.

Variabili richieste per il proxy inverso

Se hai optato per il proxy inverso, dovresti aggiungere queste variabili al file .env:

DISABLE_HTTPS: poiché HTTPS sarà 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 e 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 la tua istanza. Per ulteriori informazioni leggi il mio articolo su revere proxy.

[SOLO SE SI UTILIZZA PROXY INVERSO] Modificare il file di composizione

Apri il file docker-compose.yml nel tuo editor di testo preferito.

L'unica definizione di servizio che necessita di modifiche è il servizio web. Modificarlo in base all'elenco seguente

networks:
  net:
    external: true

Supponendo che il nome della rete sia net, cambialo con quello che hai impostato.

- VIRTUAL_HOST
- LETSENCRYPT_HOST

Distribuire i contenitori

Una volta completate tutte le modifiche, puoi distribuire Jitsi con il comando docker-compose up -d.

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, ad eccezione dell'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.

Fare ciò è 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 utilizzando il comando unregister 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 esitate a lasciare un commento.

Se ti piace questo tutorial e vorresti vederci produrre altri contenuti utili, considera di optare per l'abbonamento Pro o fai una donazione una tantum per sostenerci :)

Articoli correlati: