База знаний (кластер NBICS)

Теперь введите свой логин и пароль, который вам выдал администратор сервера, и нажмите кнопку "Войти". [image: 1764878167697-jitsi-create-7.jpg]

Человек, которому вы отправили личное сообщение, при отправке своего сообщения в чат, теперь может выбрать - отправлять своё сообщение вам, или написать что-то в общий чат. [image: 1764877916654-j-37.png]

Чтобы добавлять комментарии, нужно авторизоваться. Причём благодаря тому, что PeerTube - это федеративный сервис, ваш аккаунт не обязательно должен быть привязан к этому серверу с PeerTube. Вы можете быть зарегистрированы на другом сервере с PeerTube, и даже в других федеративных сервисах (социальные сети, сервисы микроблогов, форумы, и прочее). Единственный нюанс - сервер с PeerTube, видео которого вы хотите прокомментировать, должен быть настроен на федерацию администратором сервера. Иначе возможность комментирования будет только у пользователей данного конкретного сервера. [image: 1764854522764-pt-25.jpg]

Полное и безопасное удаление Docker Engine с Debian 12 (Bookworm) и Debian 13 (Trixie) — включая все компоненты, конфиги, образы, контейнеры, тома и кэш. Внимание: Это полное удаление. Все данные контейнеров, образы, тома будут безвозвратно удалены. Шаг 1: Остановить и удалить все контейнеры # Остановить все запущенные контейнеры sudo docker stop $(sudo docker ps -q) 2>/dev/null || true # Удалить ВСЕ контейнеры (включая остановленные) sudo docker rm $(sudo docker ps -aq) 2>/dev/null || true -q — только ID, без лишнего вывода || true — игнорировать ошибки, если Docker не установлен Шаг 2: Удалить все образы, тома, сети, кэш # Удалить ВСЕ образы sudo docker rmi $(sudo docker images -aq) 2>/dev/null || true # Удалить ВСЕ неиспользуемые тома sudo docker volume prune -f # Удалить ВСЕ неиспользуемые сети sudo docker network prune -f # Удалить весь кэш сборки sudo docker builder prune -af Опция -f — без подтверждения Опция -a — удалить все, включая используемые (осторожно!) Шаг 3: Удалить Docker и все связанные пакеты # Основные пакеты Docker sudo apt-get purge -y docker-ce docker-ce-cli containerd.io \ docker-buildx-plugin docker-compose-plugin # Дополнительные пакеты (если были установлены) sudo apt-get purge -y docker-scan-plugin docker-ce-rootless-extras # Удалить зависимости, которые больше не нужны sudo apt-get autoremove -y purge — удаляет пакеты + конфигурационные файлы Шаг 4: Удалить официальный репозиторий Docker # Удалить файл репозитория sudo rm -f /etc/apt/sources.list.d/docker.list # Удалить GPG-ключ sudo rm -f /etc/apt/keyrings/docker.asc Шаг 5: Удалить все данные Docker (образы, контейнеры, тома, конфиги) # Основная директория данных Docker sudo rm -rf /var/lib/docker # Конфигурация containerd sudo rm -rf /var/lib/containerd # Логи sudo rm -rf /var/log/docker* sudo rm -rf /var/log/containerd* # Конфиги systemd (если есть) sudo rm -rf /etc/docker sudo rm -rf /etc/containerd # Плагин compose (если установлен отдельно) sudo rm -rf ~/.docker/cli-plugins/docker-compose Внимание: /var/lib/docker — все ваши образы, тома, контейнеры. После удаления — восстановление невозможно. Шаг 6: Очистить кэш apt sudo apt-get clean sudo apt-get update Шаг 7: Перезагрузить систему (рекомендуется) sudo reboot Чтобы убедиться, что systemd не держит старые юниты. Проверка: Docker полностью удалён? # Должны выдать "command not found" docker --version docker-compose --version containerd --version # Не должно быть процессов ps aux | grep -i docker ps aux | grep -i containerd # Не должно быть юнитов sudo systemctl status docker sudo systemctl status containerd Итог: Что удалено? Компонент Путь Удалено? Пакеты docker-ce, containerd.io и др. Да (purge) Репозиторий /etc/apt/sources.list.d/docker.list Да GPG-ключ /etc/apt/keyrings/docker.asc Да Данные /var/lib/docker Да Конфиги /etc/docker, /etc/containerd Да Логи /var/log/docker* Да Плагины ~/.docker/cli-plugins Да Юниты systemd docker.service, containerd.service Да Полный скрипт удаления (одной командой) #!/bin/bash set -e echo "Полное удаление Docker с Debian 12/13..." # 1. Остановить и удалить контейнеры sudo docker stop $(sudo docker ps -q) 2>/dev/null || true sudo docker rm $(sudo docker ps -aq) 2>/dev/null || true # 2. Удалить образы, тома, сети, кэш sudo docker rmi -f $(sudo docker images -aq) 2>/dev/null || true sudo docker volume prune -f 2>/dev/null || true sudo docker network prune -f 2>/dev/null || true sudo docker builder prune -af 2>/dev/null || true # 3. Удалить пакеты sudo apt-get purge -y docker-ce docker-ce-cli containerd.io \ docker-buildx-plugin docker-compose-plugin \ docker-scan-plugin docker-ce-rootless-extras 2>/dev/null || true sudo apt-get autoremove -y # 4. Удалить репозиторий и ключ sudo rm -f /etc/apt/sources.list.d/docker.list sudo rm -f /etc/apt/keyrings/docker.asc # 5. Удалить все данные sudo rm -rf /var/lib/docker /var/lib/containerd sudo rm -rf /var/log/docker* /var/log/containerd* sudo rm -rf /etc/docker /etc/containerd sudo rm -rf ~/.docker/cli-plugins # 6. Очистить кэш sudo apt-get clean sudo apt-get update echo "Docker полностью удалён." echo "Рекомендуется перезагрузить систему: sudo reboot" Сохраните как uninstall-docker.sh, сделайте исполняемым: chmod +x uninstall-docker.sh sudo ./uninstall-docker.sh

Чтобы установить Docker на Debian, можно воспользоваться двумя вариантами - официальным скриптом установки, либо вручную установить с помощью команд. Официальный скрипт установки: curl -fsSL https://get.docker.com | sh Часть Что делает curl Утилита для скачивания данных по HTTP/HTTPS -f Fail silently — не показывать ошибки HTTP (404 и т.д.) -s Silent — не показывать прогресс-бар -S Показывать ошибки, если они есть (вместе с -s) -L Follow redirects — переходить по редиректам https://get.docker.com URL официального установочного скрипта Docker | sh Запустить полученный текст как bash-скрипт Ручная установка: # Обновите список пакетов и установите необходимые зависимости: sudo apt-get update sudo apt-get install ca-certificates curl gnupg # Создайте директорию для ключей apt и добавьте официальный GPG-ключ Docker: sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc # Добавьте Docker репозиторий в источники apt: echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # Обновите список пакетов и установите Docker: sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # Проверьте, что Docker установлен корректно, запустив тестовый контейнер: sudo docker run hello-world Описание команд ручной установки: Команда Что делает sudo apt-get update Обновляет кэш пакетов из репозиториев Debian. Нужно для актуальных версий. sudo apt-get install ca-certificates curl gnupg Устанавливает: - ca-certificates — сертификаты для HTTPS. - curl — скачивание файлов/ключей. - gnupg — работа с GPG (не обязателен здесь, ключ в .asc). Команда Что делает sudo install -m 0755 -d /etc/apt/keyrings Создаёт /etc/apt/keyrings с правами drwxr-xr-x (рекомендация Debian 12+). sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc Скачивает GPG-ключ Docker в /etc/apt/keyrings/docker.asc. - -f — ошибка при неудаче. - -s — тихо. - -S — показ ошибок. - -L — редиректы. sudo chmod a+r /etc/apt/keyrings/docker.asc Делает ключ читаемым для всех (-rw-r--r--). Требует apt. echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null Разбор: $(dpkg --print-architecture) → архитектура (amd64, arm64 и т.д.). $(. /etc/os-release && echo "$VERSION_CODENAME") → codename: bookworm (Debian 12) или trixie (Debian 13). signed-by=... → ссылка на ключ. stable → стабильная ветка. sudo tee /etc/apt/sources.list.d/docker.list → запись в файл. Команда Что делает sudo apt-get update Обновляет кэш с новым репозиторием Docker. sudo apt-get install ... Устанавливает: - docker-ce — Docker Engine. - docker-ce-cli — CLI. - containerd.io — containerd. - docker-buildx-plugin — buildx. - docker-compose-plugin — docker compose v2.

Шаг 1: Подготовка системы # Обновляем список пакетов и систему sudo apt update sudo apt upgrade -y # Устанавливаем базовые утилиты, которые могут пригодиться sudo apt install -y curl wget gnupg software-properties-common # Для Debian 13 так: sudo apt install -y curl wget gnupg ca-certificates apt-transport-https Шаг 2: Настраиваем репозиторий Backports # Добавляем репозиторий backports echo "deb http://deb.debian.org/debian bookworm-backports main" | sudo tee /etc/apt/sources.list.d/bookworm-backports.list # Настраиваем приоритеты, чтобы избежать проблем с экспериментальными пакетами sudo tee /etc/apt/preferences.d/90-bookworm-backports << EOF Package: * Pin: release a=bookworm-backports Pin-Priority: 500 Package: incus* Pin: release a=bookworm-backports Pin-Priority: 1000 Package: * Pin: release a=experimental Pin-Priority: 1 EOF # Обновляем список пакетов с учетом новых репозиториев sudo apt update Шаг 3: Установка Incus (без QEMU) # Устанавливаем Incus без рекомендательных пакетов (исключаем QEMU) sudo apt install -t bookworm-backports incus --no-install-recommends -y # Для Debian 13: sudo apt install incus --no-install-recommends -y Шаг 4: Запуск службы Incus # Запускаем службу Incus sudo systemctl start incus incus.socket # Включаем автозапуск sudo systemctl enable incus incus.socket # Проверяем статус sudo systemctl status incus Шаг 5: Настройка Incus # Запускаем инициализацию с настройками по умолчанию sudo incus admin init --auto Что делает --auto: Создает storage pool default с бэкендом dir Создает сетевой мост incusbr0 с NAT Включает IPv6 Настраивает API на локальный socket Шаг 6: Проверка установки # Проверяем, что демон работает sudo systemctl status incus # Проверяем список контейнеров (должен быть пустым) sudo incus list # Проверяем информацию о сервере sudo incus info Шаг 7: Настройка прав пользователя (опционально) Чтобы не использовать sudo для каждой команды, добавьте своего пользователя в группу incus: # Добавляем текущего пользователя в группу incus sudo usermod -a -G incus-admin $USER # Применяем изменения группы (или перелогиньтесь) newgrp incus-admin # Проверяем группы # Должны видеть incus-admin в списке groups # Проверяем, что теперь можно работать без sudo incus list Шаг 8: Запуск первого контейнера # Запускаем контейнер с Ubuntu 22.04 incus launch images:ubuntu/22.04 test-container # Проверяем, что контейнер запустился incus list # Заходим в контейнер incus exec test-container -- bash # Внутри контейнера можно проверить систему cat /etc/os-release exit Полезные команды для начала работы # Просмотр доступных образов incus image list images: | head -20 # Создание контейнера с конкретным дистрибутивом incus launch images:debian/12 my-debian incus launch images:alpine/3.18 my-alpine # Остановка контейнера incus stop test-container # Удаление контейнера incus delete test-container # Просмотр информации о хранилище incus storage list # Просмотр сетевых настроек incus network list Если нужна поддержка виртуальных машин (позже) # Установка QEMU для поддержки ВМ sudo apt install -t bookworm-backports qemu-system-x86 -y # Теперь можно запускать виртуальные машины incus launch images:ubuntu/22.04 my-vm --vm Возможные проблемы и решения Проблема: Команда incus не найдена # Перезагружаем или перелогиниваемся sudo reboot # или newgrp incus Проблема: Нет доступа к socket # Проверяем группу пользователя groups $USER # Если нет incus, добавляем и перелогиниваемся sudo usermod -a -G incus $USER newgrp incus Проверка успешной установки После выполнения всех шагов у вас должен быть: Работающая команда incus Контейнер test-container в статусе "RUNNING" Доступ к Incus без sudo (если настроили группу) Как узнать на каком порту слушает incus Способ 1: Команда incus config # Показывает текущий адрес и порт incus config show | grep https_address # Или конкретно incus config get core.https_address Способ 2: Системные утилиты # Показывает все слушающие порты sudo netstat -tlnp | grep incus # Или с помощью ss (более современная) sudo ss -tlnp | grep incus # Ищем процесс incus sudo lsof -i -P -n | grep incus Способ 3: Проверка через systemd # Смотрим статус службы sudo systemctl status incus # Или смотрим сокеты sudo systemctl list-sockets | grep incus Способ 4: Если Incus не слушает порт # Проверяем текущую конфигурацию incus config show # Если порт не настроен, устанавливаем sudo incus config set core.https_address ":8443" # Перезапускаем sudo systemctl restart incus # Проверяем снова sudo ss -tlnp | grep 8443 Способ 5: Проверка всех сетевых соединений # Показывает все открытые порты sudo netstat -tulpn # Или только TCP порты sudo netstat -tlnp Пример вывода когда всё работает: $ sudo ss -tlnp | grep incus LISTEN 0 128 0.0.0.0:8443 0.0.0.0:* users:(("incus",pid=1234,fd=10)) Это значит Incus слушает на порту 8443 на всех интерфейсах. Если порт не настроен: # Настраиваем порт sudo incus config set core.https_address "0.0.0.0:8443" # Или только локальный доступ sudo incus config set core.https_address "127.0.0.1:8443" # Перезапускаем sudo systemctl restart incus # Проверяем sudo ss -tlnp | grep incus Краткая памятка: # УСТАНОВИТЬ порт (работает) ✅ sudo incus config set core.https_address ":8443" # ПРОВЕРИТЬ что слушает (работает) ✅ sudo ss -tlnp | grep incus # ПОСМОТРЕТЬ конфигурацию (только с sudo) ✅ sudo incus config show

В этом случае вы не сможете увидеть ваши и чужие сообщения в комнатах, где участвуете в общении. Также другие люди (да и вы сами) будут видеть перед каждым вашим сообщением значок - красный щит с восклицательным знаком. Это значит, что никто не сможет понять вы это или нет, даже если видят ваш ник и аватар. [image: 1764848663988-9fs58.jpg] ======================================== Инструкция завершена.

Список децентрализованных сервисов **Пользовательские сервисы ** Стандартный пользователь для большинства сервисов: Логин - nbics.net Пароль - nbics.net ** - Уникальный логин или пароль ** Краткие руководства пользователя - здесь № **Название-ссылка ** Назначение **Способ входа ** 01 NBICS.NET Цифровая мастер-платформа Стандартный пользователь 02 Element Федеративный мессенджер Стандартный пользователь 03 Jitsi Видеоконференции с шифрованием Стандартный пользователь **04 ** PeerTube Федеративный видеохостинг Стандартный пользователь **05 ** NextCloud Облачное хранилище файлов Стандартный пользователь **06 ** HumHub Социальная сеть для команд Стандартный пользователь **07 ** RoundCube Веб-интерфейс для почты Стандартный пользователь **08 ** BookStack Система документации и вики Стандартный пользователь **09 ** Mastodon Федеративный аналог Twitter Стандартный пользователь **10 ** PixelFed Федеративный фотохостинг Логин - nbics.net@wekan.nbics.net (пароль - nbics.net) **11 ** NodeBB Федеративный форум (логин - nbics.net) пароль - Nbics.net **12 ** Diagrams.net Создание диаграмм и схем Свободный доступ **13 ** OnlyOffice Офисный пакет Логин - nbics.net@nbics.net (пароль - nbics.net) **14 ** WordPress CMS для сайтов и блогов Логин - nbics Пароль - nbics.net_nbics.net **15 ** XWiki Федеративная вики-платформа Стандартный пользователь **16 ** Friendica Федеративная социальная сеть Логин - nbics (пароль - nbics.net) **17 ** Dolibarr ERP/CRM для бизнеса Стандартный пользователь **18 ** Redmine Управление проектами Стандартный пользователь 19 Wekan Канбан-доска В качестве способа авторизации выбрать - LDAP Логин - nbics.net@wekan.nbics.net (пароль - nbics.net) **20 ** **Mattermost ** Совместная работа в команде Стандартный пользователь **21 ** **Paperless-ngx ** Управление документацией Стандартный пользователь =========================== **Служебные сервисы (для разработчиков и администраторов) ** Стандартный пользователь для большинства сервисов: Логин - nbics.net Пароль - nbics.net ** - Запрос на почту diskokniga@yandex.ru ** - Уникальный логин или пароль **№ ** Название-ссылка Назначение **Способ входа ** **2 ** GitLab Репозитории и CI/CD Стандартный пользователь **3 ** Gitea Лёгкая альтернатива GitLab Стандартный пользователь **4 ** Webmin Веб-интерфейс для администрирования сервера Служебный вход **5 ** Quant-UX Прототипирование и UX-тестирование Логин - nbics.net@wekan.nbics.net (пароль - nbics.net) **6 ** Node-RED Графический редактор для автоматизации Свободный доступ **7 ** Code-server VS Code в браузере Стандартный пользователь **8 ** Portainer Управление контейнерами Docker Служебный вход **9 ** Matrix Synapse Сервер для мессенджера Element Серверная часть, вход служебный

Характеристики серверов Тип 1 - Тестовый (5 - 10 пользователей) Характеристика Значение ОЗУ 8 - 16 ГБ CPU 2 ядра (Intel Core i3-10100 / AMD Ryzen 3 3200G) Хранилище HDD 100 - 250 ГБ Интернет 25-50 Мбит/с (download/upload) Статический адрес У провайдера интернета Доменное имя Reg.ru и т.д. ================================ Тип 2 - Минимальный (10 - 50 пользователей) Характеристика Значение ОЗУ 16 ГБ CPU 2- 4 ядра (Intel Core i5-10400 / AMD Ryzen 5 3400G) Хранилище HDD 250-500 ГБ Интернет 50-100 Мбит/с (download/upload) Статический адрес У провайдера интернета Доменное имя Reg.ru и т.д. ================================ Тип 3 - Средний (50 - 100 пользователей) Характеристика Значение ОЗУ 32 ГБ CPU 6-8 ядер (Intel Core i7-11700 / AMD Ryzen 7 5800X) Хранилище HDD 500 ГБ -1 ТБ Интернет 100 - 250 Мбит/с (download/upload) Статический адрес У провайдера интернета Доменное имя Reg.ru и т.д. ================================ Тип 4 - VIP (100+ пользователей) Характеристика Значение ОЗУ 64 ГБ CPU 12-16 ядер (Intel Core i9-12900K / AMD Ryzen 9 5950X) Хранилище HDD 1-4 ТБ + SSD 250 - 500 ГБ - 1 ТБ Интернет 500 Мбит/с (download/upload) Статический адрес У провайдера интернета Доменное имя Reg.ru и т.д. ================================ Тип 5 - SuperVIP (1000+ пользователей) Характеристика Значение ОЗУ 128 ГБ DDR5 CPU Intel Xeon W-3375 (38 ядер) / AMD EPYC 7313P (16 ядер) Хранилище SSD 2 ТБ NVMe + HDD 8 ТБ (RAID опционально) Интернет 1 Гбит/с (1000 Мбит/с, download/upload) Статический адрес У провайдера интернета Доменное имя Reg.ru и т.д. ================================================================= Дополнительно для сервера SuperVIP - видеокарты, ускоряющие работу локального искусственного интеллекта: -------------------------------------------------------------------------------------------------------------------------------------------------------- Топовые видеокарты (80 ГБ VRAM) – максимальная производительность Видеокарта Максимальная LLM, которую потянет NVIDIA H100 80GB (4,3 млн ₽) DeepSeek 67B, LLaMA 2 65B, GPT-3.5 (с отличной скоростью) NVIDIA A100 80GB (1,97 млн ₽) DeepSeek 67B, LLaMA 2 65B (чуть медленнее H100) Эти видеокарты – серверные (требуют PCIe 4.0 x16 и мощное охлаждение). Используются в дата-центрах, оптимальны для обучения и работы крупных LLM. Полупрофессиональные видеокарты (48 ГБ VRAM) – для мощных серверов Видеокарта Максимальная LLM, которую потянет NVIDIA RTX 6000 Ada (920 тыс. ₽) DeepSeek 33B, LLaMA 2 30B (с комфортной скоростью) Промежуточный вариант между A100 и RTX 4090. Хорош для средних моделей (но DeepSeek 67B уже не потянет). Оптимальные игровые видеокарты (24 ГБ VRAM) – лучший баланс Видеокарта Максимальная LLM, которую потянет RTX 4090 24GB (170–200 тыс. ₽) DeepSeek 13B, LLaMA 2 13B (нормальная скорость) Лучший вариант для мощного ИИ на личном сервере. LLaMA 2 30B потянет с Offload (RAM), но медленно. Бюджетные видеокарты (16 ГБ VRAM) – для небольших моделей Видеокарта Максимальная LLM, которую потянет RTX 4080 16GB (130 тыс. ₽) DeepSeek 7B, LLaMA 2 7B (комфортно) RTX 4070 Ti 16GB (95 тыс. ₽) DeepSeek 7B, LLaMA 2 7B (чуть медленнее 4080) Для полноценных LLM мало VRAM – для больших моделей нужен Offload (RAM), что сильно замедляет работу. Итог: какую выбрать? ​ Если важна скорость и мощность → RTX 4090 (24 ГБ) (оптимум для LLM 13B, 30B с Offload). Если бюджет ограничен → RTX 4080 (16 ГБ) (но модели 13B+ работать будут медленно). Если нужен серверный уровень → NVIDIA A100 80GB (но цена 1,97 млн ₽).

Списки виджетов (все увиденные) Базовый виджет для регистрации Бюджетный словарь Вебинары Видео контрол ВКС Внешняя ссылка График по документам Интерактивное обучение Карта для работы с документами Каталог конфигураций Книга Компании Контакты Контролл чата Круговая диаграмма Круговая диаграмма для работы с документами Медиа файлы Новости ОЛАП по документам Оператор Панель графиков Панель информации 1.2 Плагин перезапуска медиа сервера Планирование Просмотр файлов Профиль пользователя Редактор разметки Сводная панель Система координат Сотар панель СОТАР-панель v2.0 Управление образовательной Фильтр документов GIS Карта HTML-редактор OLAP-браузер (сводная таблица) Page Constructor ProductCatalog ProductCatalogManager ProductCatalogSeller ProjectsCompetition ShoppingCart 3D конструктор Интеграция с ардуином Мои данные Панель информации Панель информации 1.1 Управление сайтами =============================================

Схемы виджетов [image: 1764748362002-sxema-vidzetov4.jpg] Схема виджетов4.jpg

Конфигурации сервера для NBICS [image: 1764748171007-roc4.jpg] [image: 1764748195641-dfe2.jpg] [image: 1764748217867-1.jpg] [image: 1764748239648-jqq3.jpg]

Установка 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 Вывод будет таким: [image: 1764662963286-jitsi.jpg] Среди каталогов и файлов выделен файл env.evample Это файл с параметрами, в данном случае он не предназначен для работы, так как Docker его не распознает. Распознаваемый Докером файл должен называться .env Поэтому копируем содержимое данного файла в новый файл с именем .env Оставшийся файл нужен для восстановления, в случае неправильных настроек. Команда копирования: cp env.example .env Снова вводим команду: ls -a И видим, что появился файл .env [image: 1764662990120-jitsi2.jpg] В этом файле {.env} есть строки, задающие пароли для некоторых компонентов Jitsi, а точнее для функций этих компонентов. Сейчас переменные присуствуют в файле .env, но значения (пароли в данном случае) у них пустые. Посмотрим содержимое файла командой: nano .env И прокрутим текст вниз до отображения этих параметров: [image: 1764663014478-jitsi3.jpg] Как видим, значения действительно пустые. Самостоятельно пароли туда не будем вводить, а используем специальный скрипт. Файл со скриптом называется gen-passwords.sh Он находится в том же каталоге с репозиторием, где мы сейчас находимся. Код скрипта можно посмотреть, но сейчас важно его просто запустить. Выйдем из программы nano и запустим скрипт следующей командой: bash gen-passwords.sh Снова откроем файл: nano .env Прокрутим текст до тех же параметров, и видим вот что: [image: 1764663037021-jitsi4.jpg] Таким образом, скрипт автоматически сгенерировал пароли для нужных параметров. Генерация происходит случайным образом, поэтому не стоит опасаться, что эти пароли будут генерироваться всегда одинаково. Выходим из программы 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 с большим числом подкаталогов. [image: 1764663079390-jitsi5.jpg] Заходим снова в каталог с репозиторием - jitsi-docker-jitsi-meet-19078a9 Сейчас нужно будет внести правки в файл .env Откроем файл для ознакомления с некоторыми параметрами и редактирования: nano .env Файл .env представляет собой набор переменных с приравненных к ним значениям. То есть, схема файла - это набор пар "ключ=значение". Сами переменные определяются в файлах типа docker-compose.yml В файле .env просто задаются значения для этих переменных. Эти значения уже подхватываются Докер Композером (Docker Compose) и применяются в качестве параметров для тех или иных конфигов внутри контейнеров. Смотрим на строки, находящиеся почти вначале файла .env [image: 1764663100901-jitsi6.jpg] Нам сейчас важны несколько параметров: 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 необходимо раскомментировать (!) Вот пример: [image: 1764663125672-jitsi27.jpg] Чуть ниже есть ещё параметры. Они связаны с созданием сертификатов Letsencrypt. В данной конфигурации они не используются, так как сертификат будет создан через Nginx Proxy manager. Поэтому не будем раскомментировать их, и оставим как есть. [image: 1764663135829-jitsi8.jpg] Тем не менее ознакомимся с их назначением: ENABLE_LETSENCRYPT: Включает генерацию сертификатов Let's Encrypt. LETSENCRYPT_DOMAIN: Домен, для которого будет сгенерирован сертификат. LETSENCRYPT_EMAIL: Электронная почта для получения важных уведомлений о аккаунте (обязательно). LETSENCRYPT_USE_STAGING: Использует тестовый сервер Let's Encrypt, чтобы избежать ограничений по количеству запросов во время тестирования. Следующая (интересующая нас) группа параметров связана с аутентификацией пользователей. [image: 1764663147478-jitsi9.jpg] ENABLE_AUTH: Включает аутентификацию (требует логин и пароль для присоединения к конференции). ENABLE_GUESTS: Включает доступ гостей, если аутентификация включена, позволяет пользователям ждать в лобби. AUTH_TYPE: Тип аутентификации: internal (встроенная), jwt, ldap или matrix. Раскомментируем эти параметры, чтобы включить аутентификацию. При этом обратите внимание, что в данной конфигурации используется встроенная аутентификация. Это значит, что после установки Jitsi нужно будет зайти внутрь контейнера и с помощью специальной команды создавать пользователей (вместе с паролями). Должно получиться так: [image: 1764663158563-jitsi10.jpg] ================================================== Настройка записи и трансляции Далее, в тот же файл .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. Если тут домен задан неправильно, то запись появится, но аудио и видео-потоки захватываться не будут. На итоговом видео отобразится конференция с именами пользователей и значками с отключенным у них микрофоном. Все эти строки можно вставить в любое место в файле, я их вставлю перед параметрами аутентификации. Получится так: [image: 1764663196287-jitsi12.jpg] Краткое описание используемых параметров для настройки 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 Это позволит автоматически перезапускать контейнеры при перезагрузке сервера или после какого-либо сбоя. При этом остановить контейнеры вручную можно, в этом случае перезапуска не будет. [image: 1764663210531-jitsi13.jpg] Результат раскомментирования будет таким: [image: 1764663217996-jitsi14.jpg] =================================================== Запуск контейнеров После всех настроек пришло время запустить контейнеры с компонентами 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) После запуска начнут скачиваться образы для контейнеров (если образов ещё нет на компьютере): [image: 1764663254805-jitsi15.jpg] В итоге всё должно выглядеть вот так (16-ричные идентификаторы только могут быть другими): [image: 1764663265497-jitsi16.jpg] Образы скачаны. Создана внутренняя сеть для общения контейнеров между собой. Сеть получила название 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 , используя заранее созданную учётку: [image: 1764663295592-jitsi17.jpg] Во вкладке Hosts выбираем пункт Proxy Hosts: [image: 1764663303789-jitsi18.jpg] Жмём кнопку Add Proxy Host. Появится такое окно: [image: 1764663311836-jitsi18.jpg] Заполняем. 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 (поддержка веб-сокетов) была включена, иначе вход в конференцию может блокироваться для участников. [image: 1764663329700-jitsi20.jpg] В том же окне переходим на вкладку SSL. В поле SSL Certificate (нажимаем на само поле) выбираем пункт Request a new SSL Certificate. Включаем галочки, которые показаны на скрине, и нажимаем Save. [image: 1764663339455-jitsi21.jpg] Через короткое время создастся сертификат, и можно заходить в 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 (слева): [image: 1764663805105-jitsi22.jpg] В правой части интерфейса теперь выбираем стек с Jitsi, в моём случае он называется jitsi-docker-jitsi-meet-19078a9 Видим список контейнеров. Нужен предпоследний контейнер, с компонентом Prosody. [image: 1764663816052-jitsi23.jpg] Заходим в параметры этого контейнера (нажав на его имя). Внизу видим вкладке. Нам нужна вкладка "Console". [image: 1764663824672-jitsi24.jpg] Жмём на эту вкладку. Внизу видим кнопку Connect. [image: 1764663866043-jitsi25.jpg] Нажимаем кнопку Connect. В итоге оказываемся внутри контейнера. [image: 1764663874699-jitsi26.jpg] Итак, одним из двух упомянутых способов вошли в контейнер. Теперь нужно в терминале вписать команду для создания нового пользователя. Например, я хочу создать пользователя с именем 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 [image: 1764663950100-jitsi31.jpg] В итоге, в интерфейсе 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-аутентификации будут выглядеть примерно так: [image: 1764663982420-jitsi32.jpg] После этих манипуляций надо перезагрузить контейнеры: docker compose -f docker-compose.yml -f jibri.yml down docker compose -f docker-compose.yml -f jibri.yml up -d

Установка Portainer в Docker (Вариант 2) Portainer в Docker — самый правильный и современный вариант 2025 года (одним файлом docker-compose.yml + HTTPS + Nginx Proxy Manager / Caddy) «Золотой стандарт» 2025 года — именно так ставят 99 % людей: mkdir -p ~/portainer && cd ~/portainer # docker-compose.yml — вечная классика 2025 cat > docker-compose.yml << 'EOF' version: "3.9" services: portainer: image: portainer/portainer-ce:latest container_name: portainer restart: unless-stopped security_opt: - no-new-privileges:true volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - data:/data ports: - "9000:9000" # веб-интерфейс - "9443:9443" # HTTPS (встроенный в Portainer) - "8000:8000" # для Edge Agent (если будешь подключать удалённые хосты) environment: - TZ=Europe/Moscow # (Опционально) Caddy — сразу HTTPS на 443 → Portainer caddy: image: caddy:2-alpine restart: unless-stopped ports: - "80:80" - "443:443" - "443:443/udp" volumes: - ./Caddyfile:/etc/caddy/Caddyfile - caddy_data:/data - caddy_config:/config volumes: data: caddy_data: caddy_config: EOF # Caddyfile — автоматический Let’s Encrypt cat > Caddyfile << 'EOF' portainer.твой-домен.рф { reverse_proxy localhost:9443 tls admin@твой-домен.рф } EOF docker compose up -d Готово! Через 30–60 секунд будет доступно сразу два адреса: https://portainer.твой-домен.рф — с нормальным сертификатом https://IP-сервера:9443 — встроенный HTTPS Portainer http://IP-сервера:9000 — старый порт (можно закрыть) Первый вход (2025) Логин: admin Пароль: минимум 12 символов Сразу снимай галочку «Send anonymous usage statistics» Полезные команды 2025 # Обновить Portainer до последней версии docker compose pull && docker compose up -d # Полные логи docker compose logs -f portainer # Полный бэкап (одна команда) docker run --rm -v portainer_data:/data -v $(pwd):/backup alpine tar -czf /backup/portainer-backup-$(date +%F).tar.gz -C /data . # Восстановление docker compose down docker run --rm -v portainer_data:/data -v ./portainer-backup-2025-12-01.tar.gz:/backup.tar.gz alpine sh -c "tar -xzf /backup.tar.gz -C /data --strip-components=1" docker compose up -d Полное удаление (если вдруг надо) cd ~/portainer docker compose down -v --remove-orphans docker volume rm portainer_data portainer_caddy_data portainer_caddy_config docker rmi portainer/portainer-ce caddy:2-alpine

Установка NPM в Docker Nginx Proxy Manager - это веб-сервер с графическим интерфейсом, доступным через браузер. После установки интерфейс (админка) доступен на 81 порту. ======================================= Создаём каталог nginx_prm sudo mkdir nginx_prm Переходим в этот каталог cd nginx_prm Создаём файл docker-compose.yml sudo touch docker-compose.yml Открываем созданный файл: sudo nano docker-compose.yml Вставляем туда следующее содержимое: services: app: image: jc21/nginx-proxy-manager:latest restart: unless-stopped ports: - "80:80" - "443:443" - "81:81" - "10000:10000" volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt Среди пробрасываемых портов есть порт 10000, тут он для примера, как дополнительный порт, не входящий в список основных портов. Но если Nginx Proxy Manager будет использоваться, допустим, для Jitsi Meet, то этот порт следует оставить. Не забываем открыть эти порты в фаерволе и роутере (если есть). Запускаем командой: sudo docker compose up -d Данная команда применяется в случае, если Docker Compose установлен как плагин для Docker. Либо запускаем такой командой (в случае, если Docker Compose установлен как отдельный компонент, что актуально, например, для Astra Linux SE): sudo docker-compose up -d ========================= Переходим по адресу http://<ip-адрес>:81 (или http://localhost:81) [image: 1764661560846-npm.jpg] По умолчанию в Nginx Proxy Manager логин (e-mail) и пароль следующие: Логин: admin@example.com Пароль: changeme После входа сразу будет предложено сменить имя, ник, и адрес почты. Имя и ник позволяется оставить таким как есть, а адрес почты менять обязательно. Адрес не проверяется на существование, поэтом можно вписывать любой. После замены входных данных, нажимаем Save. [image: 1764661643968-npm2.jpg] В следующем окне предлагается сменить пароль. В верхнем поле вводим текущий пароль (changeme), в полях ниже - новый пароль , с подтверждением. Жмём кнопку Save. [image: 1764661654843-npm3.jpg] После этого появится интерфейс Nginx Proxy Manager. вверху есть вкладки. В основном наиболее востребована вкладка Hosts. Нажав на неё появится меню. Первый пункт меню (Proxy Hosts) открывает окно для привязки доменов к приложениям а также для создания сертификатов. [image: 1764661665716-npm4.jpg] В терминале выходим из каталога: cd ..

Ссылки на официальную документацию сервисов Название веб-сервиса Ссылка на документацию Portainer https://docs.portainer.io/ Webmin https://webmin.com/docs/ Code-server https://coder.com/docs Penpot https://help.penpot.app/ Drone https://docs.drone.io/ Gitea https://docs.gitea.com/ Jitsi Meet https://jitsi.github.io/handbook/docs/intro PeerTube https://docs.joinpeertube.org/ Matrix Synapse https://element-hq.github.io/synapse/latest/welcome_and_overview.html NextCloud https://docs.nextcloud.com/ HumHub https://docs.humhub.org/ NodeBB https://docs.nodebb.org/ OnlyOffice https://helpcenter.onlyoffice.com/index.aspx Mailcow https://docs.mailcow.email/ BookStack https://www.bookstackapp.com/docs/ Wiki.js https://docs.requarks.io/ Erachain https://docs.erachain.org/ru Ollama https://github.com/ollama/ollama/blob/main/docs/api.md OpenVidu https://docs.openvidu.io BigBlueButton https://docs.bigbluebutton.org/

20 - Аналитическое полотно Аналитическое полотно Чтобы открыть аналитическое полотно, выберите вкладку «Тепловые карты» (Heatmaps) на странице обзора прототипа. Затем выберите одну из тепловых карт или нажмите кнопку «Аналитическое полотно» (Analytic Canvas) в правом углу. На панели инструментов аналитического полотна вы можете выбрать различные инструменты для визуализации поведения пользователей. Что такое тепловые карты Тепловые карты кликов визуализируют, где пользователи кликали. Чем чаще пользователи кликают в определённой области, тем «горячее» (краснее) она становится. Таким образом, элементы в этой области, вероятно, важны для пользователя. Тепловые карты кликов При анализе тепловых карт кликов их следует рассматривать в контексте ваших сценариев использования. Перед созданием интерфейса вы определили и приоритизировали задачи пользователей и разработали интерфейс соответственно. Основные элементы должны быть легко находимыми, и вы ожидаете, что ими будут часто пользоваться. Если основные элементы «горячие», ваша гипотеза, скорее всего, верна, и пользователи ведут себя так, как вы ожидали. Если основные элементы «холодные», это обычно указывает на проблему: пользователи могут не находить элементы или не хотят использовать функцию. Неожиданные горячие области указывают на то, что пользователи ведут себя иначе, чем вы предполагали. Поддерживается пять типов тепловых карт кликов: Все клики (All Clicks) дают хорошее представление о наиболее активных зонах вашего дизайна, а также помогают легко обнаружить области, которые не привлекли внимания пользователей. Первый клик (First Click) помогает понять, какие элементы больше всего привлекают внимание пользователей и куда они кликнули сразу после загрузки экрана. Первые три клика (First three Clicks) расширяют первый клик до трёх. Элементы, которые не были задействованы в течение трёх кликов, могут быть сложными для обнаружения пользователем. Пропущенные клики (Missed Clicks) показывают клики по неактивным элементам, например, когда пользователи кликают на фон экрана. Это может указывать на то, что пользователи допустили ошибку и не поняли предполагаемого взаимодействия. Тепловые карты курсора Тепловые карты курсора работают иначе, чем тепловые карты кликов. Чем дольше курсор находится над определённой областью экрана, тем «горячее» она становится. Исследования показывают некоторую корреляцию между движением курсора и взглядом пользователя. Это означает, что длительное наведение над конкретной областью может указывать на сильный интерес пользователя, но также может означать, что пользователь просто не двигал мышь. Часто эти тепловые карты являются результатом «паттерна чтения», который обычно принимает форму буквы F. Путь пользователя Путь пользователя (User Journey) показывает, как пользователи перемещались по прототипу. По умолчанию различные пути объединяются, и общие маршруты отображаются более тёплым цветом. Вы можете отключить опцию объединения на панели свойств, чтобы показать индивидуальные потоки. В разделе свойств также можно увидеть список всех пользовательских тестов. Вы можете переключать видимость и запускать записи экрана. Видимость прокрутки Видимость прокрутки (Scroll Visibility) показывает для каждого экрана, какие части экрана были видны пользователям. Это важно для длинных экранов. Части ниже «сгиба» (нижней границы экрана) обычно просматриваются реже и отображаются более холодными цветами. Видимость прокрутки помогает определить, исследовали ли пользователи весь экран. Время прокрутки Время прокрутки (Scroll Time) показывает, на каких частях экрана пользователи провели больше всего времени. Чем больше времени пользователи проводят в определённой секции, тем теплее становится цвет. Просмотры экрана Тепловая карта просмотров (Screen Views) показывает, сколько раз экран был просмотрен пользователями по сравнению с другими экранами. Холодные цвета указывают на то, что большинство пользователей не видели экран, что может быть признаком проблем с навигацией. Время пребывания Время пребывания (Dwell Time) указывает, сколько времени пользователи провели на экране. Например, если на экране нужно заполнить форму, он обычно будет «горячим». Ключевые показатели элементов При выборе виджета или экрана вы также можете увидеть определённые KPI, связанные с этим виджетом. Эти KPI включают: Клики по виджету Клики по виджету (Widget Clicks) показывают, сколько раз на определённый виджет кликнули. Этот KPI напрямую связан с тепловыми картами. Индикатор показывает абсолютное число кликов, а положение кольца — отношение к другим виджетам в прототипе. Пример: Во время теста 5 пользователей совершили 100 кликов. Виджет A был кликнут 20 раз. Относительная частота составляет 20%. Первые клики Первые клики по виджету (First Clicks) показывают, сколько раз на определённый виджет кликнули сразу после загрузки экрана. Первые клики показывают, какие элементы больше всего привлекают внимание пользователей. Индикатор показывает абсолютное число, а положение визуализирует отношение к загрузкам экрана. Пример: На экране два элемента, A и B. Экран был загружен 10 раз, и 4 раза сразу после этого кликнули на элемент B. Относительная частота составляет 40%. Время до клика Время до клика (Time before Click) показывает, сколько секунд в среднем пользователи тратили до первого взаимодействия с данным элементом. Обычно элементы вверху экрана имеют меньшее время, чем элементы внизу. Пример: Экран загружен, и через 10 секунд пользователь взаимодействует с элементом A. Во втором тесте пользователь кликнул на элемент через 2 секунды. Среднее время до клика составляет 15 секунд. Охват тестирования Охват тестирования (Test Coverage) показывает, сколько раз экран был протестирован. Этот показатель указывает, насколько легко найти экран. Индикатор показывает абсолютное число тестов экрана в центре, а положение кольца — относительное соотношение тестов. Пример: Ваш прототип имеет два экрана и был протестирован двумя пользователями. Первый пользователь видел оба экрана, второй — только первый. Это означает, что было два теста. Относительная частота первого экрана — 100%, так как его видел каждый пользователь, а второго — 50%. Время пребывания Среднее время пребывания (Dwell Time) показывает, сколько времени пользователи в среднем провели на экране. Высокое значение может указывать на то, что пользователям пришлось выполнить много взаимодействий, например, заполнить форму. Однако это также может означать проблемы, например, с поиском нужных элементов. Индикатор показывает абсолютное время пребывания и соотносит его с общей продолжительностью теста. Пример: Было проведено пять тестов, каждый длился ровно 60 секунд. Пользователи провели 20, 30, 30, 30 и 40 секунд на первом экране. Среднее время пребывания — 30 секунд, а относительное — 50% ((20 + 30 + 30 + 30 + 40) / (5*60)). Просмотры экрана Просмотры экрана (Screen Views) показывают, сколько раз экран был показан. Если это число значительно выше, чем «Тестовые просмотры», это указывает на то, что пользователи часто возвращались к этому экрану. Индикатор показывает абсолютное число в центре, а положение кольца — относительную частоту. Пример: Ваш прототип имеет два экрана и был протестирован двумя пользователями. Первый пользователь видел оба экрана, второй — только первый. Это означает, что было три загрузки экрана. Относительная частота первого экрана — 67%, второго — 33%. Клики по фону экрана Клики по фону экрана (Screen Background Clicks) показывают, сколько раз пользователи кликнули по экрану, а не по виджету. Высокое число часто указывает на проблемы, например, пользователи ожидают, что некоторые элементы будут кликабельными. Индикатор показывает абсолютное число, а положение — относительную частоту относительно всех кликов по экрану. Пример: Во время теста на экране A три пользователя совершили 100 событий. 10 событий были на экране A. Относительная частота — 10%. Клики по виджетам экрана Клики по виджетам экрана (Screen Widget Clicks) показывают, сколько раз пользователи кликнули по элементам. Это число указывает, сколько «работы» пользователи выполнили на определённом экране. Индикатор показывает абсолютное число, а положение — относительную частоту относительно всех кликов по экрану. Пример: Во время теста на экране A три пользователя совершили 100 событий. 90 событий были на пяти виджетах экрана. Относительная частота — 90%.