Jitsi Meet на Ubuntu 22.04: пошаговая установка в Docker

Jitsi Meet — открытый сервер видеоконференций, который ставится на собственный VPS и заменяет внешние сервисы вроде Zoom и Google Meet. Решение об установке обычно уже принято, остаётся вопрос «как развернуть так, чтобы работало». Ниже — два рабочих сценария для Ubuntu 22.04 LTS: контейнерный через docker compose с автоматическим SSL Let's Encrypt и классическая установка пакета jitsi-meet из APT. Плюс детали, которые часто упускают из виду: выверенный набор портов UFW, настройка coturn для обхода NAT и базовое усиление защиты.

Jitsi Meet и подготовка сервера к установке

Зачем держать ВКС у себя: контроль над тем, где лежат записи и метаданные звонков, отсутствие лимитов на длительность и число встреч, размещение сервера в российском контуре под требования регуляторов. Архитектурно Jitsi Meet — связка компонентов: Prosody (XMPP-сервер сигнализации), Jicofo (конференц-фокус) и jitsi-videobridge2 (JVB, медиа-маршрутизатор) плюс веб-фронтенд. Схема пригодится при диагностике — каждый сбой локализуется в конкретном сервисе. Jitsi не транскодирует видео, а ретранслирует потоки между участниками (SFU-модель): нагрузка на CPU умеренная, а главный фактор качества — сеть и корректная работа UDP-трафика.

Системные требования под число участников

Ресурсы считаются от ожидаемого размера конференций. Одиночный сервер JVB на подходящем оборудовании обслуживает несколько сотен одновременных участников, но узким местом скорее станет исходящий канал.

Сценарий	vCPU	RAM	Диск	Сеть
До 25 участников (рабочие группы)	2	4 ГБ	20 ГБ SSD	100 Мбит/с
До 75 участников (вебинары отдела)	4	8 ГБ	40 ГБ SSD	300–500 Мбит/с
100–300 участников	8	16 ГБ	60 ГБ SSD	от 1 Гбит/с

Расчёт канала простой: один поток видео в HD — примерно 1,5–2,5 Мбит/с. При 50 активных камерах исходящий трафик легко уходит за сотни мегабит, поэтому критичнее ширина и стабильность канала, чем лишние ядра.

Под такую задачу удобна изолированная виртуальная машина с фиксированными ресурсами. Здесь подойдёт аренда виртуального выделенного сервера Cloud4Y — VPS/VDS с закреплёнными за вами CPU, RAM и диском, собственной ОС и публичным IP. Для медиасервера это важно вдвойне: «плавающая» производительность общего хостинга напрямую сказывается на качестве звонков, а в дата-центрах Cloud4Y ресурсы не зависят от соседей. Машины размещены в России, что закрывает и вопрос с контуром хранения данных.

Белый IP, домен, DNS-запись и hostname

Без публичного («белого») IP-адреса полноценный сервер ВКС не поднять — участникам нужно получить доступ к медиапортам снаружи. Дальше — домен или поддомен, например meet.example.com, и корректная DNS A-запись, указывающая на этот IP. Сертификат Let's Encrypt выпускается на доменное имя, так что без рабочего DNS двигаться нет смысла.

Перед установкой задайте hostname:

hostnamectl set-hostname meet.example.com

Затем пропишите соответствие в /etc/hosts строкой вида 127.0.0.1 meet.example.com meet и проверьте, что hostname -f возвращает полное доменное имя. Половина «загадочных» проблем с Prosody упирается в рассогласование hostname и домена в конфигах.

Развёртывание Jitsi Meet в Docker с SSL

Контейнерный путь — официальный репозиторий docker-jitsi-meet. Все компоненты (web, prosody, jicofo, jvb) запускаются как отдельные контейнеры из одного docker-compose.yml, а настройка вынесена в .env. Конфигурация отделена от хоста, обновление сводится к смене тега образа, откат — к возврату прежнего .env. Предполагается, что Docker Engine и плагин Compose уже стоят.

Конфигурация .env и запуск контейнеров

Клонируем релиз и готовим окружение:

git clone https://github.com/jitsi/docker-jitsi-meet
cd docker-jitsi-meet
cp env.example .env

Дальше — обязательный шаг, который часто забывают: генерация секретов для внутреннего взаимодействия компонентов.

./gen-passwords.sh

Скрипт перезапишет в .env значения вроде JICOFO_AUTH_PASSWORD и JVB_AUTH_PASSWORD случайными строками. Теперь задайте ключевые параметры:

CONFIG=~/.jitsi-meet-cfg — каталог на хосте, куда монтируются конфиги контейнеров;
PUBLIC_URL=https://meet.example.com — публичный адрес сервиса;
JVB_ADVERTISE_IPS=<белый_IP> — внешний IP, который videobridge сообщает клиентам (ключевой параметр, если сервер за NAT-ом).

Создайте каталоги конфигурации и поднимите стек:

mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb}
docker compose up -d

Состояние контейнеров проверяется через docker compose ps, логи компонента — через docker compose logs jvb. После старта веб-интерфейс уже доступен, но пока без доверенного сертификата.

Автоматический SSL Let's Encrypt в контейнере

В докеризованном Jitsi сертификат выпускается переменными окружения, а не хостовым скриптом:

ENABLE_LETSENCRYPT=1
LETSENCRYPT_DOMAIN=meet.example.com
LETSENCRYPT_EMAIL=admin@example.com

Контейнер web сам обратится к Let's Encrypt по ACME, получит и продлит сертификат. Обязательное условие — порты 80 и 443/TCP открыты снаружи: проверка домена идёт по HTTP. Если перед Jitsi уже стоит свой обратный прокси (nginx, Traefik) с терминацией TLS, встроенный Let's Encrypt отключают (ENABLE_LETSENCRYPT=0), а сертификат выпускают на уровне прокси — иначе два процесса конкурируют за 80-й порт.

После правки .env применяем изменения: docker compose down && docker compose up -d. Замок в адресной строке означает, что цепочка fullchain.pem/privkey.pem собрана корректно.

Установка через APT-репозиторий и аутентификация

Если контейнеры не нужны, Jitsi ставится пакетом из официального репозитория. На Ubuntu 22.04 этот путь работает «из коробки»: подходящая Java идёт зависимостью.

Репозиторий, пакет jitsi-meet и выпуск сертификата

Старые руководства с apt-key на современной Ubuntu ломаются. Правильный способ — ключ в отдельный keyring и репозиторий с указанием signed-by:

curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jitsi-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update

Сама установка:

sudo apt install jitsi-meet

Интерактивный инсталлятор спросит hostname (введите ваш домен) и тип сертификата. Выберите пункт о получении Let's Encrypt, затем запустите штатный скрипт:

sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

Он запросит email и оформит сертификат с автопродлением через certbot. Для покупного сертификата на этом шаге выбирают вариант с указанием путей к своим fullchain.pem и privkey.pem.

Аутентификация: модератор создаёт, гость подключается

По умолчанию комнату на публичном сервере может создать кто угодно — прямой путь к подключению посторонних. Рабочая схема: создавать конференции вправе только зарегистрированные пользователи, а гости свободно присоединяются к открытой комнате. Настраивается в Prosody.

В файле /etc/prosody/conf.avail/meet.example.com.cfg.lua основному VirtualHost меняем authentication = "anonymous" на internal_hashed и ниже добавляем гостевой VirtualHost:

VirtualHost "guest.meet.example.com"
    authentication = "anonymous"
    c2s_require_encryption = false

Затем в /etc/jitsi/meet/meet.example.com-config.js указываем anonymousdomain: 'guest.meet.example.com', а в /etc/jitsi/jicofo/jicofo.conf включаем аутентификацию по этому VirtualHost. Создаём модератора и перезапускаем сервисы:

sudo prosodyctl register admin meet.example.com надёжный_пароль
sudo systemctl restart prosody jicofo jitsi-videobridge2

Проверка: создайте комнату в обычном окне браузера — система попросит логин и пароль. Затем зайдите в ту же комнату из приватной вкладки: подключение пройдёт без пароля, как гость.

Сетевая настройка: порты UFW и обход NAT через TURN

Самая частая причина «чёрного экрана» и звонков без звука — закрытые медиапорты. Сигнализация ходит по 443, а видео и аудио — по UDP. Если этот трафик не пропущен, интерфейс открывается, участники видят друг друга в списке, но картинки и звука нет.

Открытие портов в UFW

Минимум для работы — три порта, полный набор нужен для TURN и резервных каналов:

80/TCP — проверка домена Let's Encrypt и редирект на HTTPS;
443/TCP — веб-интерфейс, сигнализация и TURN over TLS как запасной транспорт;
10000/UDP — основной медиапорт JVB, через него идёт весь голос и видео;
3478/UDP — STUN/TURN для определения внешнего адреса клиента;
5349/TCP — TURN over TLS (coturn), плюс резервный 4443/TCP, когда UDP заблокирован.

Команды для UFW:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 4443/tcp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

Не открывайте без необходимости весь диапазон 10000–20000/UDP — на одиночном сервере JVB использует один порт 10000, широкий диапазон нужен лишь в многомостовых конфигурациях.

Настройка coturn для работы за NAT

UDP 10000 нередко закрыт корпоративными фаерволами и не проходит через симметричный NAT — без TURN-сервера медиапоток не установится, и у участника остаётся чёрный квадрат. coturn решает это, ретранслируя трафик через TCP/443, открытый практически везде.

При установке jitsi-meet пакет jitsi-meet-turnserver обычно подтягивает и настраивает coturn автоматически. Стоит проверить ключевые строки в /etc/turnserver.conf:

listening-port=3478 и tls-listening-port=5349 — порты STUN и TURN over TLS;
cert и pkey — пути к тому же сертификату Let's Encrypt, что у Jitsi;
external-ip=<белый_IP> — внешний адрес, если сервер за NAT.

После правок: sudo systemctl restart coturn. Проверить TURN удобно тестом ICE на странице webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ — введите адрес turns:meet.example.com:5349 с учётными данными из конфига и убедитесь, что в ответе появляются кандидаты типа relay.

Безопасность, соответствие и диагностика

Публичный сервер ВКС доступен из интернета, и относиться к нему нужно соответственно.

Защита сервера и соответствие требованиям

Базовый набор мер против несанкционированного доступа:

обязательная аутентификация на создание комнат (настроена выше) — главный барьер против посторонних;
пароли на конференции и «лобби», где модератор подтверждает вход каждого участника;
регулярные обновления: apt update && apt upgrade или смена тегов образов для Docker;
ограничение доступа к служебным интерфейсам и логам на уровне фаервола.

Для компаний под регуляторными требованиями важен контур размещения. Jitsi на собственном сервере в российском дата-центре позволяет держать записи, метаданные и трафик в пределах РФ — аргумент при работе с персональными данными и требованиями 152-ФЗ, недостижимый при использовании внешних облачных ВКС.

Диагностика по логам и проверка медиатрафика

Диагноз ставится по логам конкретного компонента, а не угадыванием:

комната не собирается, участники не видят друг друга — Jicofo: journalctl -u jicofo -f. Частая причина — рассинхрон домена или ошибка аутентификации;
чёрный экран, нет видео и звука при рабочем интерфейсе — JVB и сеть: journalctl -u jitsi-videobridge2 -f. Почти всегда закрыт UDP 10000 или не задан JVB_ADVERTISE_IPS/external-ip за NAT;
не пускает в комнату, проблемы с логином — Prosody: /var/log/prosody/prosody.log.

Объективная проверка медиа: зайдите в конференцию с двух устройств в разных сетях (рабочий компьютер и телефон по мобильному интернету) — это сразу выявляет проблемы NAT, не видные при тесте «сам с собой». В Chrome откройте chrome://webrtc-internals и проверьте транспорт: host/srflx означает прямой UDP, relay — что трафик пошёл через TURN.

Главные выводы

Выбор между двумя путями сводится к тому, как вы эксплуатируете инфраструктуру. Контейнерный docker-jitsi-meet выигрывает там, где важны переносимость, предсказуемые обновления и быстрый откат: вся конфигурация в .env, а SSL поднимается переменными ENABLE_LETSENCRYPT. Установка из APT ближе тем, кто привык управлять сервисами на хосте напрямую и тонко править конфиги Prosody и Jicofo. Оба сценария требуют одного фундамента — белого IP, корректной DNS-записи и доверенного сертификата.

Дальше всё держится на сети и защите. Порты 443/TCP и 10000/UDP — необходимый минимум, но без coturn конференции не заработают у пользователей за корпоративным фаерволом и симметричным NAT, а это значительная часть аудитории. Обязательная аутентификация на создание комнат закрывает базовый риск посторонних, регулярные обновления снимают известные уязвимости, а российский контур отвечает на вопросы регуляторов. Когда видео не идёт, ответ почти всегда лежит в логах JVB и в том, дошёл ли UDP-трафик до клиента.

videoconferencing cloud server