Установка Nginx Proxy Manager
Первым делом устанавливаем сервис Nginx Proxy Manager. Ссылка на инструкцию по установке NPM:
Установка NPM
=======================================================
Начальные настройки
С помощью следующей команды скачиваем последний релиз набора конфигураций для установки 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
Откроем файл для ознакомления с некоторыми параметрами и редактирования:
nano .env
Файл .env представляет собой набор переменных с приравненных к ним значениям. То есть, схема файла - это набор пар "ключ=значение". Сами переменные определяются в файлах типа docker-compose.yml
В файле .env просто задаются значения для этих переменных. Эти значения уже подхватываются Докер Композером (Docker Compose) и применяются в качестве параметров для тех или иных конфигов внутри контейнеров.
Смотрим на строки, находящиеся почти вначале файла .env
Нам сейчас важны несколько параметров:
CONFIG: Директория, где будут храниться все конфигурационные файлы. По умолчанию используется ~/.jitsi-meet-cfg. (Вспоминаем, что можно создать и другой каталог, например, /opt но при этом его нужно обязательно указать и тут ). Я оставлю каталог по умолчанию, единственное - укажу тут не относительный, а абсолютный путь до каталога. Например, в моём тестовом варианте это будет CONFIG=/home/astra/.jitsi-meet-cfg
HTTP_PORT: Порт, через который будет доступен HTTP. По умолчанию — 8000, который будет перенаправлен на HTTPS. Если этот порт у вас ничем не занят, оставляем его тут как есть.
HTTPS_PORT: Порт, через который будет доступен HTTPS. По умолчанию — 8443. В данном случае этот параметр закомментируем.
TZ: Часовой пояс системы. По умолчанию установлен на UTC. Можно указать другой пояс, например, для московского времени (TZ=Europe/Moscow)
PUBLIC_URL: Публичный URL для веб-сервиса. Если используется нестандартный HTTPS порт, он должен быть указан в URL (например, https://meet.example.com:8443). В нашем случае порт указывать не нужно (!), так как будет подключён сервис Nginx Proxy Manager, использующий 443 порт. Поэтому указываем только сам адрес (обязательно с https, так как через Nginx proxy manager будет создан сертификат). Например, https://jitsi.nbics.net
JVB_ADVERTISE_IPS: IP-адреса, которые будут публиковаться JVB (Jitsi Video Bridge). То есть, JVB делает доступной информацию о своих IP-адресах для клиентов, чтобы они могли подключиться. В данном параметре можно указать несколько IP через запятую. В данном случае указываем внешний IP (белый статический).
Параметры PUBLIC_URL и JVB_ADVERTISE_IPS необходимо раскомментировать (!)
Вот пример:
Чуть ниже есть ещё параметры. Они связаны с созданием сертификатов Letsencrypt. В данной конфигурации они не используются, так как сертификат будет создан через Nginx Proxy manager. Поэтому не будем раскомментировать их, и оставим как есть.
Тем не менее ознакомимся с их назначением:
ENABLE_LETSENCRYPT: Включает генерацию сертификатов Let's Encrypt.
LETSENCRYPT_DOMAIN: Домен, для которого будет сгенерирован сертификат.
LETSENCRYPT_EMAIL: Электронная почта для получения важных уведомлений о аккаунте (обязательно).
LETSENCRYPT_USE_STAGING: Использует тестовый сервер Let's Encrypt, чтобы избежать ограничений по количеству запросов во время тестирования.
Следующая (интересующая нас) группа параметров связана с аутентификацией пользователей.
ENABLE_AUTH: Включает аутентификацию (требует логин и пароль для присоединения к конференции).
ENABLE_GUESTS: Включает доступ гостей, если аутентификация включена, позволяет пользователям ждать в лобби.
AUTH_TYPE: Тип аутентификации: internal (встроенная), jwt, ldap или matrix.
Раскомментируем эти параметры, чтобы включить аутентификацию. При этом обратите внимание, что в данной конфигурации используется встроенная аутентификация. Это значит, что после установки Jitsi нужно будет зайти внутрь контейнера и с помощью специальной команды создавать пользователей (вместе с паролями).
Должно получиться так:
==================================================
Настройка записи и трансляции
Далее, в тот же файл .env добавим строки для настройки записи и трансляции. Саму запись и трансляции будет обеспечивать контейнер, в котором находится компонент Jitsi под названием Jibri.
Суть работы Jibri в том, что он прикидывается пользователем, который заходит в комнату, где ведётся конференция, и записывает на видео всё, что происходит в браузере. Браузер у Jibri отдельный, это Chrome, который находится в контейнере вместе с Jibri. Для Jibri не нужен реальный монитор, на котором отображается содержимое браузера, всё происходит виртуально (с помощью виртуального дисплея). Jibri может либо сохранять записанный видеофайл на сервер (для этого есть кнопка "Запись" в интерфейсе Jitsi), либо передавать видео в онлайн режиме на какой-либо видеохостинг, например в PeerTube или другой сервис, поддерживающий протокол RTMP (для этого в интерфейсе Jitsi есть кнопка "Трансляция").
Чтобы обеспечить правильную работу Jibri, в файл .env нужно добавить следующие строки:
#-----------------------------------------------------------------
# JIBRI
#-----------------------------------------------------------------
ENABLE_RECORDING=1
XMPP_RECORDER_DOMAIN=recorder.jitsi.nbics.net
ENABLE_HTTP_REDIRECT=0
XMPP_HIDDEN_DOMAIN=recorder.jitsi.nbics.net
JIBRI_RECORDER_USER=recorder
JIBRI_RECORDING_DIR=/config/recordings
JIBRI_FINALIZE_RECORDING_SCRIPT_PATH=/config/finalize.sh
JIBRI_XMPP_USER=jibri
JIBRI_STRIP_DOMAIN_JID=muc
JIBRI_BREWERY_MUC=jibribrewery
JIBRI_PENDING_TIMEOUT=90
JIBRI_LOGS_DIR=/config/logs
В строке XMPP_RECORDER_DOMAIN=recorder.jitsi.nbics.net адрес ставим свой, по такому принципу:
recorder.свой.домен
То есть, сначала идёт recorder, точка, и после точки домен, привязанный к вашему экземпляру Jitsi.
Главное, чтобы в настройках файла .env для Jitsi значение переменной XMPP_RECORDER_DOMAIN соответствовало реальному домену плюс поддомен recorder.
Если тут домен задан неправильно, то запись появится, но аудио и видео-потоки захватываться не будут. На итоговом видео отобразится конференция с именами пользователей и значками с отключенным у них микрофоном.
Все эти строки можно вставить в любое место в файле, я их вставлю перед параметрами аутентификации. Получится так:
Краткое описание используемых параметров для настройки Jibri:
Параметр ENABLE_RECORDING отвечает за включение функции записи: значение 1 включает запись, а 0 отключает её.
Параметр XMPP_RECORDER_DOMAIN определяет домен XMPP-сервера для учётной записи, которая сохраняет записи, в данном случае это recorder.jitsi.nbics.net.
JIBRI_RECORDER_USER задаёт имя пользователя XMPP, используемое для записи, в данном случае — recorder.
Директория, куда Jibri сохраняет записи, задаётся параметром JIBRI_RECORDING_DIR (по умолчанию /config/recordings).
Путь к скрипту, выполняемому после завершения записи, указывается в параметре JIBRI_FINALIZE_RECORDING_SCRIPT_PATH, в данном случае это /config/finalize.sh. Этот скрипт может использоваться для обработки записанного файла, например, его перемещения или загрузки.
JIBRI_XMPP_USER задаёт имя пользователя Jibri на XMPP-сервере, с помощью которого осуществляется взаимодействие с Jitsi Meet, в данном случае используется учётная запись jibri.
Параметр JIBRI_STRIP_DOMAIN_JID указывает домен, используемый для участников конференции, и обычно имеет значение muc для multi-user chat.
Комната на XMPP-сервере, в которой Jibri ожидает задания, задаётся параметром JIBRI_BREWERY_MUC, в данном случае это jibribrewery. Параметр JIBRI_PENDING_TIMEOUT определяет время ожидания (в секундах) перед тем, как задание признаётся недействительным, если не удалось подключиться к комнате, в данном случае это 90 секунд.
Наконец, параметр JIBRI_LOGS_DIR указывает директорию для сохранения логов Jibri, обычно это /config/logs.
Эти параметры вместе определяют, как Jibri взаимодействует с сервером Jitsi Meet, обрабатывает записи, управляет учётными записями XMPP и сохраняет логи.
===================================================
Дополнительные настройки
В самом конце файла .env нужно раскомментировать параметр RESTART_POLICY=unless-stopped
Это позволит автоматически перезапускать контейнеры при перезагрузке сервера или после какого-либо сбоя. При этом остановить контейнеры вручную можно, в этом случае перезапуска не будет.
Результат раскомментирования будет таким:
===================================================
Запуск контейнеров
После всех настроек пришло время запустить контейнеры с компонентами Jitsi.
Это можно сделать так (просто пример, выполнять не следует):
sudo docker compose up -d
В этом запустится Jitsi в стандартной конфигурации, без контейнера с Jibri. Так как Jibri имеет отдельный файл для Docker Compose, то запускать будем оба файла - стандартный и с конфигурацией Jibri:
sudo docker compose -f docker-compose.yml -f jibri.yml up -d
Не забываем, что для Docker Compose, установленного как отдельный компонент (например, в Astra Linux), команда вместо пробела должна иметь тире (docker-compose)
После запуска начнут скачиваться образы для контейнеров (если образов ещё нет на компьютере):
В итоге всё должно выглядеть вот так (16-ричные идентификаторы только могут быть другими):
Образы скачаны.
Создана внутренняя сеть для общения контейнеров между собой. Сеть получила название jitsi-docker-jitsi-meet-19078a9_meet.jitsi
На основе образов созданы их рабочие экземпляры (контейнеры) со следующими названиями:
jitsi-docker-jitsi-meet-19078a9-prosody-1
jitsi-docker-jitsi-meet-19078a9-jvb-1
jitsi-docker-jitsi-meet-19078a9-jicofo-1
jitsi-docker-jitsi-meet-19078a9-jibri-1
jitsi-docker-jitsi-meet-19078a9-web-1
===================================================
Настройка Nginx Proxy Manager
Теперь Jitsi доступен в браузере по адресу http://<ip-сервера>:8000
Но в таком варианте он нормально работать не будет. Интерфейс увидим, но общаться в конференциях не получится.
Нужен https, а для этого придётся получить сертификат.
Зарегистрируем домен в Nginx Proxy Manager и через этот же сервис получим сертификат.
Заходим в NPM по адресу http://<ip-сервера>:81 , используя заранее созданную учётку:
Во вкладке Hosts выбираем пункт Proxy Hosts:
Жмём кнопку Add Proxy Host. Появится такое окно:
Заполняем.
Domain Names - имя домена, по которому будет октрываться Jitsi (это то имя, которое вписано в несколько параметров настроек в файле .env)
http - так и оставляем
Forward Hostname/IP - сюда вписываем внешний адрес нашего сервера
ВНИМАНИЕ!! Внешний Ip-адрес можно вписать, если в роутере проброшен порт 8000, а также фаервола либо нет, либо там также открыт порт 8000.
Если порт 8000 не проброшен на роутере, или доступ к серверу осуществляется только из внутренней сети, в поле Forward Hostname/IP укажите внутренний IP-адрес сервера или его шлюза Docker.
Чтобы узнать ip шлюза Docker, нужно ввести следующую команду
docker network inspect bridge | grep Gateway
Обычно это 172.17.0.1
Forward Port - порт будет 8000, так как Jitsi по протоколу http открывается именно на этом порту.
Нижем включаем все галочки. Контролируем, чтобы Websockets Support (поддержка веб-сокетов) была включена, иначе вход в конференцию может блокироваться для участников.
В том же окне переходим на вкладку SSL. В поле SSL Certificate (нажимаем на само поле) выбираем пункт Request a new SSL Certificate. Включаем галочки, которые показаны на скрине, и нажимаем Save.
Через короткое время создастся сертификат, и можно заходить в Jitsi по имени домена.
=======================================
Создание пользователей
Среди контейнеров с компонентами Jitsi, есть контейнер с названием jitsi-docker-jitsi-meet-19078a9-prosody-1
Именно в этот контейнер надо зайти, и с помощью специальной команды создать там нового пользователя. Так как каждый контейнер - это отдельная операционная система (только без ядра), то вход в контейнер представляет собой вход в операционную систему.
Сейчас на компьютере с Jitsi установлен сервис Portainer, представляющий собой графический веб-интерфейс для удобного мониторинга и управления Докер-инфраструктурой. Поэтому в контейнер можно зайти не только путём использования команд терминала, но и через Portainer.
Опишу оба способа.
Первый способ. Вход через терминал. Для этого вводим следующую команду:
sudo docker exec -it jitsi-docker-jitsi-meet-19078a9-prosody-1 /bin/bash
Эта команда запускает режим терминала внутри контейнера jitsi-docker-jitsi-meet-19078a9-prosody-1
Поэтому все наши дальнейшие действия будут касаться непосредственно операционной системы внутри контейнера. Хостовая система затрагиваться не будет.
Второй способ. Вход в контейнер через Portainer. Если Portainer ещё не установлен, смотрим как это сделать по этой ссылке
Установка Portainer в Docker
Открываем Portainer по адресу http://<ip-сервера>:порт
Переходим на вкладку Stacks (слева):
В правой части интерфейса теперь выбираем стек с Jitsi, в моём случае он называется jitsi-docker-jitsi-meet-19078a9
Видим список контейнеров. Нужен предпоследний контейнер, с компонентом Prosody.
Заходим в параметры этого контейнера (нажав на его имя). Внизу видим вкладке. Нам нужна вкладка "Console".
Жмём на эту вкладку. Внизу видим кнопку Connect.
Нажимаем кнопку Connect. В итоге оказываемся внутри контейнера.
Итак, одним из двух упомянутых способов вошли в контейнер. Теперь нужно в терминале вписать команду для создания нового пользователя.
Например, я хочу создать пользователя с именем admin и паролем 123456789
Для этого запускаю в терминале контейнера следующую команду:
prosodyctl --config /config/prosody.cfg.lua register admin meet.jitsi 123456789
prosodyctl - Утилита для управления XMPP-сервером Prosody, используемая для выполнения задач, таких как регистрация пользователей, управление модулями и конфигурацией.
--config /config/prosody.cfg.lua - Указывает конкретный файл конфигурации Prosody, который будет использоваться. Это важно, если сервер работает с нестандартным расположением файла конфигурации.
register - Команда для регистрации нового XMPP-пользователя в указанном домене.
admin - это придуманное нами имя для нового пользователя (локальная часть JID — Jabber ID). Является уникальным идентификатором внутри домена.
meet.jitsi - Домен, к которому будет привязан пользователь. В случае Jitsi Meet, это стандартное имя домена, используемое внутри контейнера.
123456789 - придуманный пароль для пользователя
Обратите внимание, что команда не выводит в терминал никаких данных.
Команда для удаления пользователя:
prosodyctl --config /config/prosody.cfg.lua unregister admin meet.jitsi
Команда для вывода списка пользователей:
find /config/data/meet%2ejitsi/accounts -type f -exec basename {} .dat \;
После применения этих команд перезагружать контейнер не требуется.
Чтобы выйти из контейнера при первом способе (вход в контейнер через терминал) нужно ввести команду
exit
Чтобы в Portainer выйти из контейнера, надо нажать кнопку Disconnect (см. предыдущий скриншот)
===================================
Отображение кнопки запуска-останова трансляции
Jibri позволяет делать не только запись видео на сервер, но и транслировать это видео в реальном времени на какой-либо сторонний хостинг. Но несмотря на все проделанные настройки и запуск Jibri, трансляция по умолчанию недоступна в интерфейсе Jitsi, так как там нет соответствующей кнопки. Чтобы кнопка появилась, её надо указать в настройках непосредственно интерфейса.
Ранее мы специально создали каталог .jitsi-meet-cfg, чтобы пробрасывать на хостовую систему файлы, требуемые для нормальной работы контейнеров. В этих файлах содержатся конфиги, логи, видеозаписи, и прочее.
Среди всех подкаталогов для этого основного каталога есть подкаталог web. Зайдём туда.
В моём случае это /home/user/.jitsi-meet-cfg/web. В данном каталоге нам нужен файл config.js
Если сейчас внести изменения в этот файл, пользы никакой не будет, так как при перезапуске контейнеров восстанавливается его исходное содержимое. А перезапуск контейнеров нужен применения изменений. Такой замкнутый круг. Но есть выход - нужно создать пользовательскую копию этого файла (custom-config.js), со всем их содержимым, и редактировать уже эту копию. Тогда результаты правки файла сохранятся.
Копию создадим следующим образом (находясь в каталоге .jitsi-meet-cfg/web):
cp config.js custom-config.js
В файле custom-config.js в блоке config.liveStreaming в параметре enabled вместо false поставим значение true. В итоге блок должен выглядеть так:
config.liveStreaming = {
enabled: true,
dataPrivacyLink: 'https://policies.google.com/privacy',
helpLink: 'https://jitsi.org/live',
termsLink: 'https://www.youtube.com/t/terms',
validatorRegExpString: '^[a-zA-Z0-9]{3,}$'
};
Выходим из каталога с конфигурациями и снова заходим в каталог с репозиторием:
cd jitsi-docker-jitsi-meet-19078a9
После этих манипуляций надо перезагрузить контейнеры. Я перезагружаю всё следующими командами (down - останавливает контейнеры, up -d запускает их в фоновом режиме):
docker compose -f docker-compose.yml -f jibri.yml down
docker compose -f docker-compose.yml -f jibri.yml up -d
В итоге, в интерфейсе Jitsi появится кнопка "Начать трансляцию".
Для того, чтобы начать трансляцию на PeerTube нужно взять ссылку для трансляции (адрес+ключ) и вставить в окно запроса при нажатии кнопки в Jitsi.
Общая схема ссылки такая: rtmp://<ваш_сервер>/live/<ключ_трансляции>
Пример:
rtmp://peertube.nbics.net:1935/live/c63fc311-6b2e-4d1e-a5e8-2aea969da857
==============================================
JWT-аутентификация
Применять только для особых случаев (например, для работы Jitsi совместно с Jitsi Admin)
В jitsi есть четыре режима аутентификации:
internal, jwt, ldap, matrix
Режим internal (встроенный) был описан выше. Режимы ldap и matrix в этой инструкции применяться не будут. А вот режим jwt в данном случае будет задействован для подключения сервера с Jitsi к админке (Jitsi Admin).
Теория JWT-аутентификации для Jitsi - здесь https://pixelfed.nbics.net/books/u-1-jitsi-meet-jitsi-admin/page/teoriia-jwt-autentifikacii
Смена режима аутентификации с internal на jwt достаточно проста.
В файле .env нужно поменять значение параметра AUTH_TYPE с internal на jwt.
Кроме того, ниже по тексту в блоке # JWT authentication раскомментируем параметры JWT_APP_ID и JWT_APP_SECRET.
JWT_APP_ID - это уникальный идентификатор приложения, которое генерирует токены.
JWT_APP_SECRET - это секретный ключ
А значения для них меняем на произвольные.
JWT_APP_ID=<любое, желательно осмысленное имя>
JWT_APP_SECRET=<любой достаточно сложный ключ>
Для JWT_APP_SECRET ключ можно, например, сгенерировать с помощью следующей команды:
openssl rand -base64 32
Пример результата:
dYhH7LZ7_R7pQwZbx73sFzWfBFGKrA2T8D8LuHt6xl8
В файле .env все настройки для jwt-аутентификации будут выглядеть примерно так:
После этих манипуляций надо перезагрузить контейнеры:
docker compose -f docker-compose.yml -f jibri.yml down
docker compose -f docker-compose.yml -f jibri.yml up -d
- Уникальный логин или пароль
- Запрос на почту 
Топовые видеокарты (80 ГБ VRAM) – максимальная производительность
Эти видеокарты – серверные (требуют PCIe 4.0 x16 и мощное охлаждение).
Полупрофессиональные видеокарты (48 ГБ VRAM) – для мощных серверов
Оптимальные игровые видеокарты (24 ГБ VRAM) – лучший баланс
Бюджетные видеокарты (16 ГБ VRAM) – для небольших моделей
Итог: какую выбрать?
Если важна скорость и мощность → RTX 4090 (24 ГБ) (оптимум для LLM 13B, 30B с Offload).
Схема виджетов4.jpg
