Установка Jitsi в Docker
Первым делом устанавливаем сервис Nginx Proxy Manager. Ссылка на инструкцию по установке NPM:
https://pixelfed.nbics.net/books/z-1-drugie-servisy/page/ustanovka-npm-v-docker
=======================================================
С помощью следующей команды скачиваем последний релиз набора конфигураций для установки Jifsi в Docker:
wget $(curl -s https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep 'zip' | cut -d\" -f4)В выводе будет показан процесс скачивания репозитория с GitHub. В конце появится примерно такая строка:
2024-11-15 17:32:48 (125 KB/s) - «stable-9823» сохранён [381175]
Нам важно то, что в кавычках, в данном случае это stable-9823 (цифры - это номер сборки, с течением времени этот номер увеличивается, поэтому следующий скачаннй релиз может быть с другим номером)
stable-9823 - это название архива с репозиторием, и его нужно распаковать.
Распаковываем так:
unzip stable-9823После распаковки нужно зайти в текущий каталог и посмотреть название распакованного каталога. Введём команду:
lsСреди других каталогов и файлов обратим внимание на следующий каталог:
jitsi-docker-jitsi-meet-19078a9
Это название состоит из неизменяемой части (jitsi-docker-jitsi-meet-), и части с 16-ричным кодом (в данном случае это 19078a9)
Правая часть (с кодом) будет другой после каждого обновления репозитория разработчиками, поэтому ориентируемся на неизменную часть названия.
Далее копируем полное название каталога и переходим в него:
cd jitsi-docker-jitsi-meet-19078a9Посмотрим, что есть в этом каталоге, с помощью команды:
ls -aВывод будет таким:
Среди каталогов и файлов выделен файл env.evample
Это файл с параметрами, в данном случае он не предназначен для работы, так как Docker его не распознает. Распознаваемый Докером файл должен называться .env
Поэтому копируем содержимое данного файла в новый файл с именем .env
Оставшийся файл нужен для восстановления, в случае неправильных настроек. Команда копирования:
cp env.example .envСнова вводим команду:
ls -aИ видим, что появился файл .env
В этом файле {.env} есть строки, задающие пароли для некоторых компонентов Jitsi, а точнее для функций этих компонентов. Сейчас переменные присуствуют в файле .env, но значения (пароли в данном случае) у них пустые.
Посмотрим содержимое файла командой:
nano .envИ прокрутим текст вниз до отображения этих параметров:
Как видим, значения действительно пустые. Самостоятельно пароли туда не будем вводить, а используем специальный скрипт. Файл со скриптом называется gen-passwords.sh
Он находится в том же каталоге с репозиторием, где мы сейчас находимся. Код скрипта можно посмотреть, но сейчас важно его просто запустить. Выйдем из программы nano и запустим скрипт следующей командой:
bash gen-passwords.shСнова откроем файл:
nano .envПрокрутим текст до тех же параметров, и видим вот что:
Таким образом, скрипт автоматически сгенерировал пароли для нужных параметров. Генерация происходит случайным образом, поэтому не стоит опасаться, что эти пароли будут генерироваться всегда одинаково.
Выходим из программы nano (клавиши Ctrl-X)
Выходим из каталога с репозиторием на уровень выше:
cd ..Теперь нужно создать каталоги на хостовой системе для конфигурационных файлов и других данных, которые будут наполняться во время работы Jitsi. Эта команда создаёт каталог .jitsi-meet-cfg (его название имеет вначале точку, а значит этот каталог скрытый), а также несколько подкаталогов внутри него.
mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}Команда создаёт каталог .jitsi-meet-cfg в том же каталоге, куда в данный момент указывает терминал. За это отвечают символы ~/
Но иногда советуют создавать этот каталог не в произвольном каталоге, а в каталоге /opt
В этом случае вся команда будет такой: sudo mkdir -p /opt/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
Я запущу прежнюю команду, создающую новый каталог в текущем каталоге. В итоге появится каталог .jitsi-meet-cfg с большим числом подкаталогов.
Заходим снова в каталог с репозиторием - jitsi-docker-jitsi-meet-19078a9
Сейчас нужно будет внести правки в файл .env
в DockerСсылка на установкуhttps://jitsi.github.io/handbook/docs/devops-guide/devops-guide-docker/
=============================================
Self-Hosting Guide - Docker
Quick start
In order to quickly run Jitsi Meet on a machine running Docker and Docker Compose, follow these steps:
Download and extract thelatest release.DO NOTclone the git repository. See below if you are interested in running test images:wget $(curl -s https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep 'zip' | cut -d\" -f4)Unzip the package:unzip <filename>Create a.envfile by copying and adjustingenv.example:cp env.example .envSet strong passwords in the security section options of.envfile by running the following bash script./gen-passwords.shCreate requiredCONFIGdirectoriesFor linux:
mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
For Windows:
echo web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri | % { mkdir "~/.jitsi-meet-cfg/$_" }
Rundocker compose up -dAccess the web UI athttps://localhost:8443(or a different port, in case you edited the.envfile).
HTTP (not HTTPS) is also available (on port 8000, by default), but that's e.g. for a reverse proxy setup; direct access via HTTP instead HTTPS leads to WebRTC errors such as Failed to access your microphone/camera: Cannot use microphone/camera for an unknown reason. Cannot read property 'getUserMedia' of undefined or navigator.mediaDevices is undefined.
IMPORTANT: When deploying Jitsi Meet for real use you must set the PUBLIC_URL env variable to the real domain where your setup is running.
If you want to use jigasi too, first configure your env file with SIP credentials and then run Docker Compose as follows:
docker compose -f docker-compose.yml -f jigasi.yml up
If you want to enable document sharing via Etherpad, configure it and run Docker Compose as follows:
docker compose -f docker-compose.yml -f etherpad.yml up
If you want to use jibri too, first configure a host as described in Jitsi Broadcasting Infrastructure configuration section and then run Docker Compose as follows:
docker compose -f docker-compose.yml -f jibri.yml up -d
or to use jigasi too:
docker compose -f docker-compose.yml -f jigasi.yml -f jibri.yml up -d
For the log analysis project, you will need both log-analyser.yml and grafana.yml files. This project allows you to analyze docker logs in grafana. If you want to run the log analyzer, run the Docker files as follows:
docker-compose -f docker-compose.yml -f log-analyser.yml -f grafana.yml up -d
Follow this document for detailed information on log analysis.
Updating
If you want to update, simply run
wget $(curl -s https://api.github.com/repos/jitsi/docker-jitsi-meet/releases/latest | grep 'zip' | cut -d\" -f4)
again (just like how you initially downloaded Jitsi). Then unzip and overwrite all when being asked:
unzip <filename>
Testing development / unstable builds
Download the latest code:
git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
The code in master is designed to work with the unstable images. Do not run it with release images.
Run docker compose up as usual.
Every day a new "unstable" image build is uploaded.
Building your own images
Download the latest code:
git clone https://github.com/jitsi/docker-jitsi-meet && cd docker-jitsi-meet
The provided Makefile provides a comprehensive way of building the whole stack or individual images.
To build all images:
make
To build a specific image (the web image for example):
make build_web
Once your local build is ready make sure to add JITSI_IMAGE_VERSION=latest to your .env file.
Security note
This setup used to have default passwords for internal accounts used across components. In order to make the default setup secure by default these have been removed and the respective containers won't start without having a password set.
Strong passwords may be generated as follows: ./gen-passwords.sh This will modify your .env file (a backup is saved in .env.bak) and set strong passwords for each of the required options. Passwords are generated using openssl rand -hex 16 .
DO NOT reuse any of the passwords.
Architecture
A Jitsi Meet installation can be broken down into the following components:
A web interfaceAn XMPP serverA conference focus componentA video router (could be more than one)A SIP gateway for audio callsA Broadcasting Infrastructure for recording or streaming a conference.
The diagram shows a typical deployment in a host running Docker. This project separates each of the components above into interlinked containers. To this end, several container images are provided.
External Ports
The following external ports must be opened on a firewall:
80/tcpfor Web UI HTTP (really just to redirect, after uncommentingENABLE_HTTP_REDIRECT=1in.env)443/tcpfor Web UI HTTPS10000/udpfor RTP media over UDP
Also 20000-20050/udp for jigasi, in case you choose to deploy that to facilitate SIP access.
E.g. on a CentOS/Fedora server this would be done like this (without SIP access):
sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --permanent --add-port=10000/udp
sudo firewall-cmd --reload
See the corresponding section in the debian/ubuntu setup guide.
Images
base: Debian stable base image with theS6 Overlayfor process control and theJitsi repositoriesenabled. All other images are based on this one.base-java: Same as the above, plus Java (OpenJDK).web: Jitsi Meet web UI, served with nginx.prosody:Prosody, the XMPP server.jicofo:Jicofo, the XMPP focus component.jvb:Jitsi Videobridge, the video router.jigasi:Jigasi, the SIP (audio only) gateway.jibri:Jibri, the broadcasting infrastructure.
Design considerations
Jitsi Meet uses XMPP for signaling, thus the need for the XMPP server. The setup provided by these containers does not expose the XMPP server to the outside world. Instead, it's kept completely sealed, and routing of XMPP traffic only happens on a user-defined network.
The XMPP server can be exposed to the outside world, but that's out of the scope of this project.
Configuration
The configuration is performed via environment variables contained in a .env file. You can copy the provided env.example file as a reference.
| ||
| ||
| ||
| ||
| ||
|
The mobile apps won't work with self-signed certificates (the default). See below for instructions on how to obtain a proper certificate with Let's Encrypt.
TLS Configuration
Let's Encrypt configuration
If you want to expose your Jitsi Meet instance to the outside traffic directly, but don't own a proper TLS certificate, you are in luck because Let's Encrypt support is built right in. Here are the required options:
| ||
| ||
|
In addition, you will need to set HTTP_PORT to 80 and HTTPS_PORT to 443 and PUBLIC_URL to your domain. You might also consider to redirect HTTP traffic to HTTPS by setting ENABLE_HTTP_REDIRECT=1.
Let's Encrypt rate limit warning: Let's Encrypt has a limit to how many times you can submit a request for a new certificate for your domain name. At the time of writing, the current limit is five new (duplicate) certificates for the same domain name every seven days. Because of this, it is recommended that you disable the Let's Encrypt environment variables from .env if you plan on deleting the .jitsi-meet-cfg folder. Otherwise, you might want to consider moving the .jitsi-meet-cfg folder to a different location so you have a safe place to find the certificate that already Let's Encrypt issued. Or do initial testing with Let's Encrypt disabled, then re-enable Let's Encrypt once you are done testing.
When you move away from LETSENCRYPT_USE_STAGING, you will have to manually clear the certificates from .jitsi-meet-cfg/web.
For more information on Let's Encrypt's rate limits, visit: https://letsencrypt.org/docs/rate-limits/
Using existing TLS certificate and key
If you own a proper TLS certificate and don't need a Let's Encrypt certificate, you can configure Jitsi Meet container to use it.
Unlike Let's Encrypt certificates, this is not configured through the .envfile, but by telling Jitsi Meet's web service to mount the following two volumes:
mount/path/to/your/cert.keyfile to/config/keys/cert.keymount pointmount/path/to/your/cert.fullchainfile to the/config/keys/cert.crtmount point.
Doing it in docker-compose.yml file should look like this:
services:
web:
...
volumes:
...
- /path/to/your/cert.fullchain:/config/keys/cert.crt
- /path/to/your/cert.key:/config/keys/cert.key
Features configuration (config.js)
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
Jigasi SIP gateway (audio only) configuration
If you want to enable the SIP gateway, these options are required:
| ||
| | |
| ||
| ||
|
Display Dial-In information
| ||
|
The JSON with the Dial-In numbers should look like this:
{"message":"Dial-In numbers:","numbers":{"DE": ["+49-721-0000-0000"]},"numbersEnabled":true}
Recording / live streaming configuration with Jibri
Details
If you want to enable Jibri these options are required:
|
Extended Jibri configuration:
| ||
| | |
| ||
| ||
| ||
| ||
| ||
|
Jitsi Meet configuration
Jitsi-Meet uses two configuration files for changing default settings within the web interface: config.js and interface_config.js. The files are located within the CONFIG/web/ directory configured within your environment file.
These files are re-created on every container restart. If you'd like to provide your own settings, create your own config files: custom-config.js and custom-interface_config.js.
It's enough to provide your relevant settings only, the docker scripts will append your custom files to the default ones!
Authentication
Authentication can be controlled with the environment variables below. If guest access is enabled, unauthenticated users will need to wait until a user authenticates before they can join a room. If guest access is not enabled, every user will need to authenticate before they can join.
If authentication is enabled, once an authenticated user logged in, it is always logged in before the session timeout. You can set ENABLE_AUTO_LOGIN=0 to disable this default auto login feature or you can set JICOFO_AUTH_LIFETIME to limit the session lifetime.
| ||
| ||
| ||
| ||
|
Internal authentication
The default authentication mode (internal) uses XMPP credentials to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to internal, then configure the settings you can see below.
Internal users must be created with the prosodyctl utility in the prosody container. In order to do that, first, execute a shell in the corresponding container:
docker compose exec prosody /bin/bash
Once in the container, run the following command to create a user:
prosodyctl --config /config/prosody.cfg.lua register TheDesiredUsername meet.jitsi TheDesiredPassword
Note that the command produces no output.
To delete a user, run the following command in the container:
prosodyctl --config /config/prosody.cfg.lua unregister TheDesiredUsername meet.jitsi
To list all users, run the following command in the container:
find /config/data/meet%2ejitsi/accounts -type f -exec basename {} .dat \;
Authentication using LDAP
You can use LDAP to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to ldap, then configure the settings you can see below.
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
Authentication using JWT tokens
You can use JWT tokens to authenticate users. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to jwt, then configure the settings you can see below.
| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
This can be tested using the jwt.io debugger. Use the following sample payload:
{
"context": {
"user": {
"avatar": "https://robohash.org/john-doe",
"name": "John Doe",
"email": "jdoe@example.com"
}
},
"aud": "my_jitsi_app_id",
"iss": "my_jitsi_app_id",
"sub": "meet.jitsi",
"room": "*"
}
Authentication using Matrix
For more information see the documentation of the "Prosody Auth Matrix User Verification" here.
| | |
| | |
| ||
|
Authentication using Hybrid Matrix Token
You can use Hybrid Matrix Token to authenticate users. It supports Matrix and JWT Token authentications on the same setup. To enable it you have to enable authentication with ENABLE_AUTH and set AUTH_TYPE to hybrid_matrix_token, then configure the settings you can see below.
For more information see the documentation of the "Hybrid Matrix Token" here.
| | |
| | |
| ||
| ||
| ||
| ||
| ||
|
External authentication
|
Shared document editing using Etherpad
You can collaboratively edit a document via Etherpad. In order to enable it, set the config options below and run Docker Compose with the additional config file etherpad.yml.
Here are the required options:
| |
Transcription configuration
If you want to enable the Transcribing function, these options are required:
| ||
| | |
| | |
| | |
| | |
| | |
| | |
| ||
| ||
|
For setting the Google Cloud Credentials please read https://cloud.google.com/text-to-speech/docs/quickstart-protocol> section "Before you begin" paragraph 1 to 5.
Sentry logging configuration
| | |
| | |
| | |
| ||
|
TURN server configuration
Configure external TURN servers.
| ||
| ||
| ||
| ||
| ||
|
Advanced configuration
These configuration options are already set and generally don't need to be changed.
| ||
| ||
| ||
| | |
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| | |
| ||
| ||
| ||
| | |
| ||
| | |
| | |
| | |
| |
Advanced Prosody options
| ||
| ||
| | |
| | |
|
Advanced Jicofo options
| ||
| ||
| | |
| | |
| | |
| ||
|
Advanced JVB options
| ||
| | |
| ||
| ||
| ||
| ||
| ||
|
Advanced Jigasi options
| ||
| ||
| ||
| ||
| ||
| | |
| ||
| ||
|
Running behind NAT or on a LAN environment
When running running in a LAN environment, or on the public Internet via NAT, the JVB_ADVERTISE_IPS env variable should be set. This variable allows to control which IP addresses the JVB will advertise for WebRTC media traffic. It is necessary to set it regardless of the use of a reverse proxy, since it's the IP address that will receive the media (audio / video) and not HTTP traffic, hence it's oblivious to the reverse proxy.
This variable used to be called DOCKER_HOST_ADDRESS but it got renamed for clarity and to support a list of IPs.
If your users are coming in over the Internet (and not over LAN), this will likely be your public IP address. If this is not set up correctly, calls will crash when more than two users join a meeting.
The public IP address is attempted to be discovered via STUN. STUN servers can be specified with the JVB_STUN_SERVERS option.
Due to a bug in the docker version currently in the Debian repos (20.10.5), Docker does not listen on IPv6 ports, so for that combination you will have to manually obtain the latest version.
Split horizon
If you are running in a split horizon environemt (LAN internal clients connect to a local IP and other clients connect to a public IP) you can specify multiple advertised IPs by separating them with commas:
JVB_ADVERTISE_IPS=192.168.1.1,1.2.3.4
Offline / airgapped installation
If your setup does not have access to the Internet you'll need to disable STUN on the JVB since discovering its own IP address will fail, but that is not necessary on that type of environment.
JVB_DISABLE_STUN=true
Accessing server logs
The default bahavior of docker-jitsi-meet is to log to stdout.
While the logs are sent to stdout, they are not lost: unless configured to drop all logs, Docker keeps them available for future retrieval and processing.
If you need to access the container's logs you have multiple options. Here are the main ones:
rundocker compose logs -t -f <service_name>from command line, where<service_name>is one ofweb,prosody,jvb,jicofo. This command will output the logs for the selected service to stdout with timestamps.use a standarddocker logging driverto redirect the logs to the desired target (for instancesyslogorsplunk).searchdocker hubfor a third partydocker logging driver pluginorwrite your own driver pluginif you have a very specific need.
For instance, if you want to have all logs related to a <service_name> written to /var/log/jitsi/<service_name> as json output, you could use docker-file-log-driver and configure it by adding the following block in your docker-compose.yml file, at the same level as the image block of the selected <service_name>:
services:
<service_name>:
image: ...
...
logging:
driver: file-log-driver
options:
fpath: "/jitsi/<service_name>.log"
If you want to only display the message part of the log in json format, simply execute the following command (for instance if fpath was set to /jitsi/jvb.log) which uses jq to extract the relevant part of the logs:
sudo cat /var/log/jitsi/jvb.log | jq -r '.msg' | jq -r '.message'
Build Instructions
Building your images allows you to edit the configuration files of each image individually, providing more customization for your deployment.
The docker images can be built by running the make command in the main repository folder. If you need to overwrite existing images from the remote source, use FORCE_REBUILD=1 make.
If you are on the unstable branch, build the images with FORCE_REBUILD=1 JITSI_RELEASE=unstable make.
You are now able to run docker compose up as usual.
Running behind a reverse proxy
By default this setup is using WebSocket connections for 2 core components:
Signalling (XMPP)Bridge channel (colibri)
Due to the hop-by-hop nature of WebSockets the reverse proxy must properly terminate and forward WebSocket connections. There 2 routes require such treatment:
/xmpp-websocket/colibri-ws
With nginx, these routes can be forwarded using the following config snippet:
location /xmpp-websocket {
proxy_pass https://localhost:8443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /colibri-ws {
proxy_pass https://localhost:8443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
In addition we need a route for /http-bind as XMPP over BOSH is still used by mobile clients:
location /http-bind {
proxy_pass https://localhost:8443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
With apache, mod_proxy and mod_proxy_wstunnel need to be enabled and these routes can be forwarded using the following config snippet:
<IfModule mod_proxy.c>
<IfModule mod_proxy_wstunnel.c>
ProxyTimeout 900
<Location "/xmpp-websocket">
ProxyPass "wss://localhost:8443/xmpp-websocket"
</Location>
<Location "/colibri-ws/">
ProxyPass "wss://localhost:8443/colibri-ws/"
</Location>
<Location "/http-bind">
ProxyPass "http://localhost:8443/http-bind"
</Location>
</IfModule>
</IfModule>
where https://localhost:8443/ is the url of the web service's ingress.
Disabling WebSocket connections
This is not the recommended setup.
If using WebSockets is not an option, these environment variables can be set to fallback to HTTP polling and WebRTC datachannels:
ENABLE_SCTP=1
ENABLE_COLIBRI_WEBSOCKET=0
ENABLE_XMPP_WEBSOCKET=0