Jitsi Meet es un software de videoconferencia de código abierto que puede alojar usted mismo. Es una buena alternativa a servicios propietarios como Google Meet o Zoom.
Jitsi Meet se puede integrar con otras herramientas de código abierto como Nextcloud, Rocket.Chat o Synapse (implementación de Matrix) para brindarle una solución completa.
Con algunas limitaciones, Jitsi Meet se puede usar de forma gratuita en su servidor. Para funciones premium, puede optar por Jitsi como servicio de los desarrolladores de Jitsi. ¿También puede implementarlo en su propio servidor? Te ayudaré con la parte del alojamiento propio.
Implementar Jitsi Meet con Docker
Implementar Jitsi es increíblemente fácil con Docker. Le mostraré los pasos para la implementación de Jitsi. Cubriré tanto el proxy inverso como el método regular.
Cómo usar Nginx Reverse Proxy con múltiples aplicaciones Docker Aprenda cómo puede implementar múltiples servicios web en el mismo servidor usando el proxy inverso Nginx y los contenedores Docker.
Manual de LinuxDebdut Chakraborty 
Requisitos
Hay algunas cosas que deben solucionarse antes de continuar.
Conocimientos básicos de Docker y contenedores: Esto no es obligatorio, como todos nuestros tutoriales, pero es bueno tenerlo.
Un dominio personalizado: Esta implementación no será IP, es decir, lo guiaré a través de la implementación bajo un dominio real (o subdominio) con HTTPS. Las implementaciones como HTTP://[algún IP]:[algún puerto] están bien para realizar pruebas, pero no tienen ningún propósito en estas guías.
Un servidor Linux ya sea físico o en la nube: Recomiendo usar Linode pero puedes usar cualquier otro proveedor como DigitalOcean, Vultr o UpCloud. La implementación en AWS puede ser muy específica de la plataforma y no hablaré de eso aquí.
Según la recomendación oficial, un servidor con 4 GB de memoria con un procesador de doble núcleo sería adecuado para unos 10-20 usuarios.
Linodo | La nube abierta independiente para desarrolladores Nuestra misión es acelerar la innovación haciendo que la computación en la nube sea simple, asequible y accesible para todos.
Linode 
DigitalOcean:la nube para desarrolladoresAyuda a millones de desarrolladores a crear, probar, administrar y escalar fácilmente aplicaciones de cualquier tamaño, más rápido que nunca antes. 
Opcionalmente, nuestra configuración de proxy inverso: Si desea colocarlo detrás de un proxy inverso para que pueda implementar varios servicios web en el mismo servidor. Si Jitsi es la única aplicación que se ejecutará en el servidor, no necesita el proxy inverso.
Cambiando registros DNS
Tener un nombre de dominio no es suficiente. También debe asegurarse de que los registros DNS estén en su lugar. Para este tutorial, voy a utilizar un dominio openexperiment.in que he tenido por ahí durante bastante tiempo.
Asegúrese de cambiar todas las instancias del dominio de los ejemplos a su dominio.
Una vez que tenga un dominio e implemente un servidor (no con Jitsi, solo el servidor), recopile las direcciones IP del servidor (IPv4 e IPv6) y agregue registros A y AAAA para cada uno respectivamente. Una vez hecho esto, también deberá agregar un registro CNAME. Puede agregar un subdominio específico o, como yo, agregar una entrada comodín (si lo aloja en el dominio principal).
Vea la captura de pantalla a continuación si todavía está confundido. Borré las direcciones IP reales (soy muy reservado... shhh).
Es posible que deba esperar un tiempo para que los cambios de DNS surtan efecto. Puede verificar eso usando el comando ping.
ping el dominio hasta que vea la dirección IP de su servidor así -
❯ 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
También puede usar el comando dig para verificar los registros DNS.
dig openexperiment.in +nocmd +nocomments
Deberías ver algo como lo siguiente
❯ 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
Comprender los componentes de Jitsi Meet
Antes de continuar, creo que es útil saber cuáles son estos componentes y por qué son importantes, además de cuáles usará para esta implementación.
Si no le interesa esto, salte a la sección de implementación de este artículo.
jitsi/web:último: La interfaz de usuario web de Jitsi Meet, que ve en su navegador, se encuentra dentro de esta imagen. Junto con Nginx para el servidor web.
jitsi/prosodia:último: Este es el servidor XMPP, este es el responsable de las llamadas de audio/video o los chats de texto. Esto puede considerarse el corazón de Jitsi.
jitsi/jicofo:último: El componente foco del servidor XMPP, encargado de gestionar las videosesiones entre los participantes y el videobridge, es decir, es el que gestiona las conferencias. Este es otro componente obligatorio de Jitsi.
jitsi/jvb:último: Jitsi Videobridge es responsable de transmitir los canales de video entrantes a todos los participantes.
Estas son las partes obligatorias de una implementación operativa de Jitsi y solo las usaré para esta guía. Hay otros componentes como Jibri, Jigasi, pero como son opcionales, los dejaré fuera por ahora.
Suficiente lectura, es hora de un poco de trabajo práctico.
Si va a implementar esto junto con un proxy inverso, asegúrese de tenerlo configurado antes de acercarse a este. y contenedores docker.Manual de LinuxDebdut Chakraborty Clonar el repositorio de docker-jitsi-meet
Este repositorio contiene todos los archivos que vamos a necesitar para esta implementación (obviamente con algunas modificaciones).
Clona el repositorio y cambia tu PWD al directorio clonado.
git clone https://github.com/jitsi/docker-jitsi-meet jitsi
cd jitsi
Empezar a modificar las variables de entorno
Como está utilizando Docker, debe modificar algunas variables de entorno. Comience copiando el archivo de configuración de ejemplo.
cp env.example .env
Ahora abra el .env y mire las primeras 6 variables de entorno.
Dado que todos estos componentes son básicamente una especie de servidores que se ejecutan en contenedores, necesita una forma de asegurarse de que los servidores sean realmente quienes dicen ser. Estos secretos están ahí por esa razón. Los clientes deben autenticarse primero antes de establecer una conexión.
No tienes que establecer estos secretos por ti mismo. Ya hay un guión allí para hacerte la vida más fácil. Ejecute el siguiente comando mientras está dentro del directorio del repositorio
./gen-passwords.sh
Una vez ejecutado, puede volver a abrir .env archivo, y los secretos deben ser llenados.
No necesitará todos esos secretos para esta implementación, pero déjelos así, no es necesario eliminarlos ni comentarlos.
Ahora habrá tres subsecciones aquí, una para las asignaciones de variables comunes (proxy inverso o sin proxy inverso), otra para el proxy inverso y la última para no proxy inverso. Todos van al archivo .env.
Variables comunes (tanto para el proxy inverso como para el método de proxy no inverso)
Estas son las variables comunes a ambos métodos de implementación y las agrega en el archivo .env.
CONFIGURACIÓN: Tu puedes cambiar el valor de esto, pero no es necesario. El valor de esta variable es un directorio en su host, que se montará en enlace dentro de los contenedores para almacenar datos persistentes. Así que modificar esto depende totalmente de usted.
URL_PÚBLICA: El dominio en el que se alojará Jitsi (con el protocolo). En mi caso el valor es https://meet.openexperiment.in
ENABLE_AUTH: ¿Quieres autenticación? Con la autenticación, el usuario tendrá que ingresar un nombre de usuario y una contraseña antes de poder unirse o crear una reunión. Si es así, elimine el comentario de esta línea y asegúrese de que esté configurada en 1.
AUTO_TIPO: Si configura ENABLE_AUTH en 1, configure este como "interno". No repasaré la autenticación LDAP o JWT en este artículo.
RESTART_POLÍTICA: Política de reinicio de los contenedores. El valor predeterminado es unless-stopped . Prefiero always o on-failure .
TZ: Establezca esto en la zona horaria de su sistema. Dado que mis servidores se ejecutan en la zona horaria UTC, no tengo que cambiarla.
Variables para el método de proxy no inverso
Si no está utilizando un proxy inverso, debe agregar estas variables al archivo .env:
HTTP_PORT ,
HABILITAR_LETSENCRYPT: Establézcalo en 1, necesita HTTPS.
LETSENCRYPT_DOMAIN &LETSENCRYPT_EMAIL: El dominio en el que se alojará su instancia y su ID de correo electrónico para las notificaciones relacionadas con su certificado.
HABILITAR_HTTP_REDIRECTO: Establézcalo en 1, el tráfico HTTP debe retransmitirse a HTTPS.
HABILITAR_HSTS: Esto, en cierto modo, obligará a los navegadores a utilizar una conexión de confianza. Establézcalo en 1.
Variables requeridas para el proxy inverso
Si ha optado por el proxy inverso, debe agregar estas variables al archivo .env:
DESHABILITAR_HTTPS: Dado que HTTPS será manejado por el servidor web de su proxy inverso, no necesita tener HTTPS habilitado desde Jitsi.
HABILITAR_HTTP_REDIRECTO: No es necesario, establezca esto en 0. HTTP/HTTPS será manejado por nuestro proxy inverso.
HOST_VIRTUAL &LETSENCRYPT_HOST: Estas variables no están ahí por defecto. Agréguelos y, para los valores, use el nombre de dominio donde se alojará su instancia. Para obtener más información, lea mi artículo de veneración por poder.
[SOLO SI SE UTILIZA REVERSE PROXY] Modifique el archivo de redacción
Abra el archivo docker-compose.yml en tu editor de texto favorito.
La única definición de servicio que necesita edición es el servicio web. Modifíquelo de acuerdo con la siguiente lista
- Elimine la sección de puertos. Ya no necesita vincular ningún puerto desde su contenedor al host.
- Agregue otra red, la misma red que se usa en su configuración de proxy inverso.
- Defina la red al final del archivo de redacción así
networks:
net:
external: true
Asumiendo que el nombre de la red es net , cámbielo a lo que haya configurado en el suyo.
- Agregue las variables de entorno
VIRTUAL_HOST&LETSENCRYPT_HOSTasí
- VIRTUAL_HOST
- LETSENCRYPT_HOST
Implementar los contenedores
Una vez que haya terminado toda la edición, puede implementar Jitsi con docker-compose up -d comando.
Asegúrese de que sus contenedores de proxy inverso se estén ejecutando SI optó por el método de proxy inverso.
Ya casi ha terminado con la implementación de Jitsi Meet, excepto por el último paso, que es crear usuarios autenticados para su servidor Jitsi.
Creación de usuarios autenticados
Si habilitó la autenticación (con ENABLE_AUTH ), necesitará registrar a los usuarios antes de poder usar Jitsi.
Hacerlo es bastante simple. Dirígete al directorio del repositorio clonado y ejecuta un comando similar al siguiente
docker-compose exec prosody prosodyctl --config=/config/prosody.cfg.lua register [USERNAME] meet.jitsi [PASSWORD]
También puede eliminar a un usuario mediante unregister comando como el que he mostrado aquí:
docker-compose exec prosody prosodyctl --config=/config/prosody.cfg.lua unregister [USERNAME] meet.jitsi
Finalmente, puede continuar y verificar el front-end de Jitsi Meet en la URL designada en un navegador web:
¿Aún tienes preguntas o sugerencias? Por favor, siéntase libre de dejar un comentario.
Si le gusta este tutorial y le gustaría vernos producir más contenido útil, considere optar por la membresía Pro o hacer una donación única para apoyarnos :)