Перенос старого OpenVidu на новый сервер

Admin

На сервере установлен OpenVidu скорее всего второй версии, а сейчас третья. На одном самописном сервисе (расположеннном на другом сервере) этот старый OpenVidu уже интегрирован в интерфейс, и если прописать в том сервере просто новый OpenVidu новой версии, всё поломается так как возможно API поменялся у OpenVidu.
Могу ли я этот старый OpenVidu скопировать (он в Докере), и перенести на другой сервер?

Admin

Да, в большинстве случаев старый OpenVidu (вероятно 2.x) можно скопировать и запустить на другом сервере без серьёзных проблем, если вы перенесёте всё правильно. Это один из самых надёжных способов сохранить совместимость со старым клиентским кодом, не трогая фронтенд/мобильные приложения.

Что именно нужно перенести (самый надёжный вариант)

Директория установки (обычно /opt/openvidu или та, куда вы ставили)
- .env файл — там все важные настройки (пароли, домен, сертификаты, coturn и т.д.)
- docker-compose.yml (или несколько файлов)
- Папка с кастомными сертификатами, если не Let's Encrypt
- Папки с данными, если они не внутри контейнеров (редко, но бывает)

Docker images (самый простой и надёжный способ — не тянуть их заново с интернета, вдруг старая версия уже недоступна)

На старом сервере:

docker images | grep openvidu   # посмотреть, какие у вас образы

# Сохраняем все нужные образы в один файл (~5–10 ГБ)
docker save \
  openvidu/openvidu-server:2.x.x \
  openvidu/openvidu-coturn:… \
  openvidu/openvidu-proxy:… \
  openvidu/openvidu-recording:… \
  $(другие образы, которые используются) \
  -o openvidu-images.tar

Перенос
- Скопируйте .tar файл + всю папку /opt/openvidu (или где у вас лежало) на новый сервер (rsync, scp, tar + перенос)
- На новом сервере:
```
# Загружаем образы
docker load -i openvidu-images.tar

# Разворачиваем в ту же директорию
cd /opt/openvidu
docker compose up -d
```
Дополнительно (важно!)
- Сетевые настройки — новый сервер должен иметь публичный IP или хотя бы тот же домен, что был настроен в .env (OPENVIDU_DOMAIN_OR_PUBLIC_IP)
- Порты — 4443, 3478 (coturn), иногда 80/443 для proxy
- Сертификаты — если самоподписанные или свои — перенесите их. Если Let's Encrypt — лучше сгенерировать заново (или перенести acme.json, если использовался certbot/другой клиент)
- Coturn credentials — если у вас динамические учётные данные — они хранятся в redis → их нужно сохранить (или просто пересоздать)

Альтернативные варианты (если не хочется тащить образы)

На новом сервере ставите точно ту же версию OpenVidu, что была на старом (например 2.28.0, 2.30.0 и т.д.)
Копируете только .env и docker-compose файлы
Запускаете → почти всегда работает, если версии совпадают

Резюме — что лучше всего сделать прямо сейчас

На старом сервере выполните docker compose config > docker-compose-resolved.yml — сохраните итоговый конфиг
Сделайте docker save всех openvidu-* образов
Перенесите папку с установкой + tar-архив
На новом сервере — load + docker compose up -d
Проверьте логи: docker compose logs -f openvidu-server

Если всё поднимется и https://новый-домен:4443 отвечает — скорее всего ваш старый клиентский код продолжит работать без изменений.

Удачи с миграцией! Если после переноса будут конкретные ошибки в логах — присылайте, разберём.

Admin

А зачем отдельно по новой устанавливать старую версию, разве она не в контейнерах?

Admin

Ты абсолютно прав — всё уже в контейнерах, и именно поэтому перенос старой версии обычно самый простой и надёжный способ.

Отдельная «новая установка старой версии» нужна только в одном из двух случаев:

Ты не хочешь/не можешь перенести готовые образы с текущего сервера
(например, сервер очень далеко, канал связи плохой, образы огромные, или ты просто хочешь почистить старый сервер полностью). Тогда на новом сервере проще заново скачать те же самые теги (например openvidu/openvidu-server:2.28.0), чем тащить 5–10 ГБ архива.
Ты случайно удалишь старые образы на старом сервере или захочешь развернуть такую же версию где-то ещё в будущем → тогда придётся тянуть из Docker Hub.

Но в твоём случае (когда старая версия уже стоит и работает) — самый правильный и самый быстрый путь именно копирование готовых контейнеров + конфигурации, а не повторная установка.

Почему перенос работает почти всегда идеально

Образы (openvidu/openvidu-server:2.xx.x, coturn, proxy и т.д.) — это полностью самодостаточные артефакты. Если ты их сохранишь (docker save) и загрузишь на новом сервере (docker load), Docker не будет даже пытаться тянуть ничего из интернета.
Конфигурация живёт в .env + docker-compose.yml (+ иногда override-файлы) → копируешь папку — и всё.
Данные (если есть записи, redis-состояние и т.п.) тоже либо внутри volume'ов, либо ты их тоже копируешь.

Краткий план «самый надёжный и быстрый» (ещё раз)

На старом сервере:

# 1. Сохраняем все образы OpenVidu в один файл
docker save $(docker images | grep openvidu | awk '{print $1":"$2}' | grep -v '<none>') -o openvidu-old.tar

# 2. Архивируем всю установку
tar -czf openvidu-install.tar.gz /opt/openvidu   # или где у тебя лежит

На новом сервере:

# 1. Загружаем образы
docker load -i openvidu-old.tar

# 2. Распаковываем конфиг
tar -xzf openvidu-install.tar.gz -C /

# 3. Исправляем, если нужно (IP, домен, сертификаты)
cd /opt/openvidu
nano .env   # ← здесь чаще всего меняют OPENVIDU_DOMAIN_OR_PUBLIC_IP

# 4. Запускаем
docker compose up -d

Если образы на Docker Hub всё ещё доступны для твоей конкретной версии 2.x (а судя по текущему состоянию репозитория — многие 2.2x и 2.3x теги до сих пор лежат), то можно и без docker save/load — просто скопировать .env + compose-файлы и выполнить ./openvidu install или docker compose pull && docker compose up -d. Но перенос образов надёжнее, особенно если версия уже не самая свежая в 2.x ветке.

Короче: контейнеры — это и есть преимущество. Переноси их — и не устанавливай заново, если не хочешь лишних движений.

Admin

Какая ещё информация нужна, чтобы понять - можно ли в Ubuntu 20.04 перенести контейнеры и настройки Openvidu?
vsmuser@host271:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
vsmuser@host271:~$ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d2cc3c52ff58 openvidu/openvidu-server:2.19.0 "/usr/local/bin/entr…" 2 years ago Up 6 months openvidu_openvidu-server_1
a429573679bb openvidu/openvidu-proxy:7.0.0 "/docker-entrypoint.…" 2 years ago Up 6 months openvidu_nginx_1
a2c054c958b0 openvidu/openvidu-coturn:5.0.0 "docker-entrypoint.s…" 2 years ago Up 6 months openvidu_coturn_1
7c30af1f67fa kurento/kurento-media-server:6.16.0 "/entrypoint.sh" 2 years ago Up 6 months (healthy) openvidu_kms_1
3c2b4d790aaf openvidu/openvidu-redis:3.0.0 "docker-entrypoint.s…" 2 years ago Restarting (1) 35 seconds ago openvidu_redis_1
ef32dba82193 b9cede6abb23 "bash" 5 years ago Exited (127) 5 years ago xenodochial_leakey
1fbf87f8dd52 b9cede6abb23 "bash" 5 years ago Exited (127) 5 years ago wonderful_wilbur
9664fc1ac1b7 b9cede6abb23 "bash" 5 years ago Exited (0) 5 years ago dazzling_wescoff
vsmuser@host271:~$ docker -v
Docker version 20.10.7, build 20.10.7-0ubuntu5~18.04.3
vsmuser@host271:~$

Admin

Да, перенос OpenVidu 2.19.0 с Ubuntu 18.04 на Ubuntu 20.04 (и даже на 22.04 / 24.04) вполне реален и в большинстве случаев проходит без проблем, потому что всё работает внутри Docker-контейнеров.

Вот что уже известно из твоего вывода и что критично:

Что есть	Значение	Вывод / что нужно проверить дополнительно
ОС старого сервера	Ubuntu 18.04.6 LTS	Старый, но Docker 20.10.7 на нём работает нормально
Docker версия	20.10.7	Достаточно свежая для 2021–2022 годов, совместима с образами 2.19.0
OpenVidu версия	2.19.0 (openvidu-server)	Это классический CE на Kurento (kms 6.16.0)
Kurento	6.16.0	Работает в Docker, архитектура amd64
Другие сервисы	proxy:7.0.0, coturn:5.0.0, redis:3.0.0	Стандартный стек OpenVidu ~2.19
redis	Restarting (1)	Уже сломан сейчас — но для миграции не критично, если не нужны сохранённые сессии

Самые важные вещи, которые ещё стоит посмотреть / предоставить

Выполни на старом сервере эти команды и пришли вывод (можно самые важные строки):

Точная папка установки и наличие .env
```
ls -la /opt/openvidu    # или /usr/local/openvidu, или где у тебя лежит
cat /opt/openvidu/.env | grep -vE '^#|^$'   # самые важные настройки
```
Особенно важно:
- OPENVIDU_DOMAIN_OR_PUBLIC_IP=
- OPENVIDU_SECRET=
- DOMAIN_OR_PUBLIC_IP= (иногда дублируется)
- CERTIFICATE_TYPE= (selfsigned / letsencrypt / owncert)
- LETSENCRYPT_EMAIL= (если Let's Encrypt)
Все используемые образы (чтобы знать, что именно сохранять)
```
docker images | grep -E 'openvidu|kurento'
```
Ожидаемый список примерно такой:
- openvidu/openvidu-server:2.19.0
- openvidu/openvidu-proxy:7.0.0
- openvidu/openvidu-coturn:5.0.0
- kurento/kurento-media-server:6.16.0
- openvidu/openvidu-redis:3.0.0 (или redis:alpine/стандартный)
docker-compose файл(ы)
```
cat /opt/openvidu/docker-compose.yml   # или docker-compose.override.yml если есть
```
Это самый главный файл — без него придётся угадывать порты, volumes, networks и переменные.
Volumes (где лежат данные, сертификаты, записи)
```
docker volume ls | grep openvidu
docker inspect openvidu_openvidu-server_1 | grep -i mount   # или любой другой контейнер
```
Обычно важны:
- /opt/openvidu/recordings (если запись включена)
- /opt/openvidu/cert (если свои сертификаты)
На новом сервере — какая версия Ubuntu?
Самое главное — пришли cat /etc/os-release с нового сервера.
- Ubuntu 20.04 → почти 100% успех
- Ubuntu 22.04 → очень вероятно успех (Docker Engine ставится без проблем)
- Ubuntu 24.04 → тоже работает, но Docker может быть версии 24.x–28.x (совместимость с очень старыми образами обычно сохраняется)

Краткий вердикт на текущий момент

Можно — с вероятностью 90–95% просто docker save всех нужных образов → перенести .tar + всю папку /opt/openvidu → на новом сервере docker load + поправить в .env IP/домен → docker compose up -d
Самые частые проблемы при переносе на новую ОС:
1. Неправильно указан OPENVIDU_DOMAIN_OR_PUBLIC_IP → OpenVidu не стартует или WebRTC не работает
2. Сертификаты Let's Encrypt не валидны для нового IP/домена → нужно перегенерировать
3. Порты 4443, 3478/UDP, 80/443 заняты на новом сервере
4. Redis не стартует → но он stateless в типичной установке OpenVidu 2.x, можно просто пересоздать

Если пришлёшь 1–5 пункты выше (особенно .env без секретов + docker-compose.yml + ubuntu-версия нового сервера), то можно будет сказать уже почти точно «да/нет + что именно поправить».

Admin

vsmuser@host271:~$ ls -la /opt/openvidu # или /usr/local/openvidu, или где у тебя лежит
total 1175800
drwxr-xr-x 10 root root 4096 Mar 14 19:20 .
drwxr-xr-x 9 root root 4096 Oct 28 2021 ..
drwxr-xr-x 2 root root 4096 Sep 7 2021 cdr
drwxrwxrwx 9 root root 4096 Mar 14 14:00 certificates
drwxr-xr-x 2 root root 4096 Sep 7 2021 custom-layout
drwxr-xr-x 2 root root 4096 Sep 7 2021 custom-nginx-vhosts
-rw-r--r-- 1 root root 4294 Sep 8 2021 docker-compose.yml
-rw-r--r-- 1 root root 8828 Apr 26 2023 .env
-rw-r--r-- 1 root root 8826 Apr 26 2023 .env2
-rw-r--r-- 1 root root 16384 Feb 7 2022 .env.swp
drwxr-xr-x 2 root root 4096 Sep 7 2021 kms-crashes
drwxr-xr-x 2 root root 53248 Mar 14 02:00 kurento-logs
-rw-r--r-- 1 root root 8828 Aug 21 2023 open_env
-rwxr-xr-x 1 root root 9042 Sep 7 2021 openvidu
-rw-r--r-- 1 root root 1203681626 Mar 14 19:22 openvidu-report-14-03-2026-19-20.txt
drwxr-xr-x 2 root root 4096 Sep 7 2021 owncert
drwxrwxrwx 1498 root root 163840 Oct 24 16:24 recordings
vsmuser@host271:~$ cat /opt/openvidu/.env | grep -vE '^#|^$' # самые важные настройки
DOMAIN_OR_PUBLIC_IP=media2.nbics.net
OPENVIDU_SECRET=frogsEatenUnicornes
CERTIFICATE_TYPE=letsencrypt
LETSENCRYPT_EMAIL=ser1410u@yandex.ru
OPENVIDU_RECORDING=true
OPENVIDU_RECORDING_DEBUG=false
OPENVIDU_RECORDING_PATH=/opt/openvidu/recordings
OPENVIDU_RECORDING_CUSTOM_LAYOUT=/opt/openvidu/custom-layout
OPENVIDU_RECORDING_PUBLIC_ACCESS=true
OPENVIDU_RECORDING_NOTIFICATION=publisher_moderator
OPENVIDU_RECORDING_AUTOSTOP_TIMEOUT=120
OPENVIDU_STREAMS_VIDEO_MAX_RECV_BANDWIDTH=2000
OPENVIDU_STREAMS_VIDEO_MIN_RECV_BANDWIDTH=75
OPENVIDU_STREAMS_VIDEO_MAX_SEND_BANDWIDTH=2000
OPENVIDU_STREAMS_VIDEO_MIN_SEND_BANDWIDTH=75
OPENVIDU_STREAMS_FORCED_VIDEO_CODEC=VP8
OPENVIDU_STREAMS_ALLOW_TRANSCODING=true
OPENVIDU_WEBHOOK=false
OPENVIDU_WEBHOOK_EVENTS=[sessionCreated,sessionDestroyed,participantJoined,participantLeft,webrtcConnectionCreated,webrtcConnectionDestroyed,recordingStatusChanged,filterEventDispatched,mediaNodeStatusChanged,nodeCrashed]
OPENVIDU_SESSIONS_GARBAGE_INTERVAL=900
OPENVIDU_SESSIONS_GARBAGE_THRESHOLD=3600
OPENVIDU_CDR=false
OPENVIDU_CDR_PATH=/opt/openvidu/cdr
vsmuser@host271:~$ docker images | grep -E 'openvidu|kurento'
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/json: dial unix /var/run/docker.sock: connect: permission denied
vsmuser@host271:~$ sudo docker images | grep -E 'openvidu|kurento'
openvidu/openvidu-server 2.19.0 fdaba96b7b5e 4 years ago 516MB
openvidu/openvidu-coturn 5.0.0 72040febf801 4 years ago 32.2MB
openvidu/openvidu-proxy 7.0.0 b5c9bcab046f 4 years ago 137MB
openvidu/openvidu-recording 2.19.0 91eb86667498 4 years ago 1.09GB
openvidu/openvidu-redis 3.0.0 fa510d55f34a 4 years ago 31.6MB
kurento/kurento-media-server 6.16.0 63c5a7f5e0ba 5 years ago 675MB
openvidu/openvidu-coturn 1.0.0 1f8dc80ef6f5 5 years ago 283MB
openvidu/openvidu_coturn 1.0.0 51b569988a12 5 years ago 177MB
openvidu/openvidu-call 2.15.0 442234dcff2c 5 years ago 99.2MB
openvidu/openvidu-server 2.15.0 2742903db35c 5 years ago 481MB
openvidu/openvidu-recording 2.15.0 48af9f7dad9d 5 years ago 908MB
openvidu/openvidu-proxy 3.0.0 1bf7994b4926 5 years ago 93.9MB
kurento/kurento-media-server 6.14.0 c195eb150fce 5 years ago 651MB
openvidu/openvidu-redis 1.0.0 81db390c4d8f 5 years ago 31.6MB
openvidu/openvidu-coturn <none> b9cede6abb23 5 years ago 177MB
openvidu/openvidu-recording 2.9.0 5cd3d1a3e9c6 6 years ago 890MB
vsmuser@host271:~$ cat /opt/openvidu/docker-compose.yml # или docker-compose.override.yml если есть
# ------------------------------------------------------------------------------
#
# DO NOT MODIFY THIS FILE !!!
#
# Configuration properties should be specified in .env file
#
# Application based on OpenVidu should be specified in
# docker-compose.override.yml file
#
# This docker-compose file coordinates all services of OpenVidu CE Platform
#
# This file will be overridden when update OpenVidu Platform
#
# Openvidu Version: 2.19.0
#
# Installation Mode: On Premises
#
# ------------------------------------------------------------------------------
version: '3.1'
services:
    openvidu-server:
        image: openvidu/openvidu-server:2.19.0
        restart: on-failure
        network_mode: host
        entrypoint: ['/usr/local/bin/entrypoint.sh']
        volumes:
            - /var/run/docker.sock:/var/run/docker.sock
            - ${OPENVIDU_RECORDING_PATH}:${OPENVIDU_RECORDING_PATH}
            - ${OPENVIDU_RECORDING_CUSTOM_LAYOUT}:${OPENVIDU_RECORDING_CUSTOM_LAYOUT}
            - ${OPENVIDU_CDR_PATH}:${OPENVIDU_CDR_PATH}
        env_file:
            - .env
        environment:
            - SERVER_SSL_ENABLED=false
            - SERVER_PORT=5443
            - KMS_URIS=["ws://localhost:8888/kurento"]
            - COTURN_REDIS_IP=127.0.0.1
            - COTURN_REDIS_PASSWORD=${OPENVIDU_SECRET}
            - COTURN_IP=${COTURN_IP:-auto-ipv4}
        logging:
            options:
                max-size: "${DOCKER_LOGS_MAX_SIZE:-100M}"
    kms:
        image: ${KMS_IMAGE:-kurento/kurento-media-server:6.16.0}
        restart: always
        network_mode: host
        ulimits:
          core: -1
        volumes:
            - /opt/openvidu/kms-crashes:/opt/openvidu/kms-crashes
            - ${OPENVIDU_RECORDING_PATH}:${OPENVIDU_RECORDING_PATH}
            - /opt/openvidu/kurento-logs:/opt/openvidu/kurento-logs
        environment:
            - KMS_MIN_PORT=40000
            - KMS_MAX_PORT=57000
            - GST_DEBUG=${KMS_DOCKER_ENV_GST_DEBUG:-}
            - KURENTO_LOG_FILE_SIZE=${KMS_DOCKER_ENV_KURENTO_LOG_FILE_SIZE:-100}
            - KURENTO_LOGS_PATH=/opt/openvidu/kurento-logs
        logging:
            options:
                max-size: "${DOCKER_LOGS_MAX_SIZE:-100M}"
    redis:
        image: openvidu/openvidu-redis:3.0.0
        restart: always
        network_mode: host
        environment:
            - REDIS_PASSWORD=${OPENVIDU_SECRET}
        logging:
            options:
                max-size: "${DOCKER_LOGS_MAX_SIZE:-100M}"
    coturn:
        image: openvidu/openvidu-coturn:5.0.0
        restart: on-failure
        network_mode: host
        environment:
            - REDIS_IP=127.0.0.1
            - DB_NAME=0
            - DB_PASSWORD=${OPENVIDU_SECRET}
        command:
            - --log-file=stdout
            - --listening-port=3478
            - --fingerprint
            - --lt-cred-mech
            - --min-port=57001
            - --max-port=65535
            - --realm=openvidu
            - --verbose
            - --user=abcdef:abcde
        logging:
            options:
                max-size: "${DOCKER_LOGS_MAX_SIZE:-100M}"
    nginx:
        image: openvidu/openvidu-proxy:7.0.0
        restart: on-failure
        network_mode: host
        volumes:
            - ./certificates:/etc/letsencrypt
            - ./owncert:/owncert
            - ./custom-nginx-vhosts:/etc/nginx/vhost.d/
            - ${OPENVIDU_RECORDING_CUSTOM_LAYOUT}:/opt/openvidu/custom-layout
        environment:
            - DOMAIN_OR_PUBLIC_IP=${DOMAIN_OR_PUBLIC_IP}
            - CERTIFICATE_TYPE=${CERTIFICATE_TYPE}
            - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
            - PROXY_HTTP_PORT=${HTTP_PORT:-}
            - PROXY_HTTPS_PORT=${HTTPS_PORT:-}
            - ALLOWED_ACCESS_TO_DASHBOARD=${ALLOWED_ACCESS_TO_DASHBOARD:-}
            - ALLOWED_ACCESS_TO_RESTAPI=${ALLOWED_ACCESS_TO_RESTAPI:-}
            - PROXY_MODE=CE
            - WITH_APP=true
            - SUPPORT_DEPRECATED_API=${SUPPORT_DEPRECATED_API:-true}
            - REDIRECT_WWW=${REDIRECT_WWW:-false}
            - WORKER_CONNECTIONS=${WORKER_CONNECTIONS:-10240}
            - PUBLIC_IP=${PROXY_PUBLIC_IP:-auto-ipv4}
        logging:
            options:
                max-size: "${DOCKER_LOGS_MAX_SIZE:-100M}"
vsmuser@host271:~$ docker volume ls | grep openvidu
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/volumes: dial unix /var/run/docker.sock: connect: permission denied
vsmuser@host271:~$ sudo docker volume ls | grep openvidu
vsmuser@host271:~$ sudo docker inspect openvidu_openvidu-server_1 | grep -i mount # или любой другой контейнер
        "MountLabel": "",
        "Mounts": [
vsmuser@host271:~$

Admin

Да, перенос возможен и с очень высокой вероятностью пройдёт успешно — твоя конфигурация OpenVidu 2.19.0 на Kurento (KMS 6.16.0) полностью контейнеризирована, использует network_mode: host и bind-mount'ы на хост-директории. Это делает миграцию на Ubuntu 20.04 (и даже 22.04) довольно прямолинейной.

Почему совместимость хорошая

Все ключевые компоненты (openvidu-server:2.19.0, kurento/kurento-media-server:6.16.0, coturn:5.0.0, proxy:7.0.0, redis:3.0.0) — это Docker-образы на базе старых Ubuntu (обычно 16.04/18.04 внутри контейнера), но они не зависят от версии хоста, кроме Docker Engine и ядра Linux.
Docker 20.10.7 (у тебя сейчас) → на Ubuntu 20.04 официально ставится Docker 24.x–26.x (2024–2025 годы), но старые образы (4–5 лет) продолжают работать без проблем (linux/amd64, glibc-совместимость).
Kurento 6.16.0 в Docker успешно запускается на хостах Ubuntu 20.04/22.04 — нет известных критических проблем с этим стеком (из форумов и доков).
network_mode: host + порты напрямую на хосте → меньше сюрпризов с сетью по сравнению с bridge-сетями.

Что нужно сделать на новом сервере (Ubuntu 20.04)

Установить Docker + docker-compose
На 20.04 лучше ставить свежий Docker из официального репозитория (не из apt Ubuntu, там старая версия):

sudo apt update && sudo apt install ca-certificates curl gnupg lsb-release
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

→ Теперь docker compose (без дефиса) будет работать.

Перенос данных
- Скопируй всю папку /opt/openvidu на новый сервер (rsync или scp -r).
  Особенно важны:
  - .env (твой основной конфиг)
  - docker-compose.yml
  - certificates/ (Let's Encrypt здесь)
  - recordings/ (если нужны старые записи)
  - custom-layout/, owncert/, kurento-logs/ (если используешь)
- Обязательно поправь в .env на новом сервере:
```
DOMAIN_OR_PUBLIC_IP=media2.nbics.net   # если домен остаётся тот же — оставь
# или новый IP, если домен меняется
```
  Если домен/сертификат привязан к старому IP → Let's Encrypt перестанет работать → нужно будет перегенерировать сертификаты (или временно переключить на CERTIFICATE_TYPE=selfsigned для теста).
Сохранение и загрузка образов (самый надёжный способ — без риска, что старые теги пропадут с Docker Hub)
На старом сервере:
```
sudo docker save \
  openvidu/openvidu-server:2.19.0 \
  openvidu/openvidu-coturn:5.0.0 \
  openvidu/openvidu-proxy:7.0.0 \
  openvidu/openvidu-recording:2.19.0 \
  openvidu/openvidu-redis:3.0.0 \
  kurento/kurento-media-server:6.16.0 \
  -o openvidu-2.19-images.tar
```
Перенеси .tar (~2–3 ГБ) на новый сервер.

На новом:
```
sudo docker load -i openvidu-2.19-images.tar
```
(Если не хочешь тащить — просто sudo docker compose pull после копирования compose-файла — образы 2.19.0 до сих пор доступны на hub.docker.com)
Запуск
```
cd /opt/openvidu
sudo docker compose up -d
```
Проверь:
- sudo docker compose logs -f — смотри ошибки
- https://media2.nbics.net:4443 (или твой порт) — должен ответить OpenVidu (status OK)
- sudo docker ps — все 5 контейнеров (openvidu-server, kms, redis, coturn, nginx) Up и healthy

Возможные мелкие проблемы и как фиксить

Let's Encrypt не валидируется → временно CERTIFICATE_TYPE=selfsigned, потом ./openvidu restart после правки .env на правильный домен/IP.
Порты заняты (4443, 3478/UDP, 80/443) → убей конфликтующие сервисы.
Redis restarting (как сейчас) → норм для stateless, просто перезапустится. Если нужны сессии — redis данные не сохраняются по умолчанию (нет volume для /data).
KMS не стартует (редко) → проверь ulimits в docker-compose (уже есть ulimits: core: -1), и логи kms.
WebRTC не работает → убедись, что DOMAIN_OR_PUBLIC_IP — это публичный адрес, видимый клиентам.

Если после запуска будут ошибки в логах (особенно kms или openvidu-server) — пришли их, разберём конкретно.

В 95% случаев после этих шагов твой старый клиентский сервис продолжит работать без изменений в коде. Удачи!

Admin

Ubuntu 22.04 - можно ставить? Или всё же 20.04

Admin

Да, на Ubuntu 22.04 можно ставить и запускать твой старый OpenVidu 2.19.0 (с Kurento 6.16.0 в Docker) — это вполне реально и в большинстве случаев работает без серьёзных проблем.
Но 20.04 будет надёжнее и проще, особенно если хочешь минимизировать любые потенциальные сюрпризы.

Сравнение 20.04 vs 22.04 для твоего случая

Аспект	Ubuntu 20.04 (рекомендую)	Ubuntu 22.04 (можно, но с нюансами)
Совместимость с Docker-образами 2019–2021 гг.	Отличная (Docker 20–26.x, glibc 2.31)	Хорошая, но иногда мелкие баги с очень старыми образами (glibc 2.35)
Kurento 6.16.0 в Docker	Запускается без вопросов (много примеров на 20.04)	Запускается, но есть редкие жалобы на потребление UDP-портов или мелкие краши (чаще в кастомных сборках)
OpenVidu CE 2.19 в Docker	Полностью протестировано сообществом	Работает (Docker Compose + host network), но официально OpenVidu перешёл на 22.04 только в более новых AMI/версиях
Docker Engine версия	Легко ставится свежий (24–26.x)	Ещё свежее (26–28.x), но это не проблема
Риск "непонятных" ошибок	Минимальный	Чуть выше (iptables/firewall изменения в 22.04, ulimits, старые libs внутри контейнера)
Поддержка до	Апрель 2025 (стандарт)	Апрель 2027 (стандарт)
Рекомендация для legacy	Да, особенно для миграции без тестов	Только если сервер уже на 22.04 или нужна долгая поддержка

Почему 22.04 скорее всего сработает

Всё в Docker → хост-ОС влияет минимально (кроме ядра, сетевого стека и ulimits).
network_mode: host + bind-mount'ы → сеть и файлы работают одинаково.
Образы Kurento 6.16.0 и OpenVidu 2.19.0 основаны на старых Ubuntu внутри (16.04/18.04), но Docker их изолирует.
Сообщество запускало похожие стеки на 22.04 (есть примеры с KMS в Docker на 22.04, без фатальных проблем).
Официальные новые OpenVidu (с 2.20+) уже используют 22.04 в примерах/AMI.

Что может пойти не так на 22.04 (и как фиксить)

KMS крашит или "жрёт" UDP-порты → проверь логи kms, повысь ulimits в docker-compose (уже есть ulimits: core: -1), или добавь --ulimit nofile=65535:65535 при запуске.
Docker networking / iptables → после апгрейда до 22.04 иногда ломается доступ к контейнерам (редко). Фикс: sudo update-alternatives --set iptables /usr/sbin/iptables-legacy (или nftables → legacy).
Redis или coturn не стартуют → проверь логи, чаще всего из-за портов или REDIS_PASSWORD.
WebRTC ICE candidates странные → убедись в правильном DOMAIN_OR_PUBLIC_IP, иногда на новой ОС нужно явно указывать KMS_EXTERNAL_IPV4.

Итоговый совет

Если можешь выбрать ОС → ставь Ubuntu 20.04 LTS — это самый "безопасный" вариант для точного переноса без экспериментов. Твой стек 2021 года идеально на него ложится.
Если новый сервер уже на 22.04 (или хочется новее) → пробуй, шансы успеха 90–95%. Просто после docker compose up -d внимательно смотри логи первые 5–10 минут:
```
sudo docker compose logs -f kms openvidu-server
```
Если KMS healthy и openvidu-server отвечает на 4443 — всё ок.

В любом случае сначала перенеси образы через docker save/load (как я писал раньше) — это снимет зависимость от интернета и версий на Docker Hub.

Если решишь на 22.04 и будут логи с ошибками — кидай, помогу разобрать. Удачи!

Admin

А Debian 12?

Admin

Да, на Debian 12 (Bookworm) вполне можно запустить твой старый OpenVidu 2.19.0 с Kurento 6.16.0 в Docker — это реально и в большинстве случаев проходит успешно.
Debian 12 — это "современная" Linux-дистрибуция (как и Ubuntu 22.04), и официальная документация OpenVidu прямо говорит, что CE-версия работает на любом современном Linux, включая Debian, если Docker + Compose стоят правильно.

Почему совместимость хорошая

Всё в Docker → хост-ОС (Debian 12) влияет минимально: ядро Linux 6.1, glibc 2.36 — старые образы (Kurento на базе Ubuntu 18.04 внутри) запускаются без проблем.
network_mode: host в твоём docker-compose.yml — это самый "прямой" режим, меньше сюрпризов с сетью/портами по сравнению с bridge.
Нет известных фатальных багов именно для Kurento 6.16.0 + Docker на Debian 12 (из форумов, GitHub, Discourse OpenVidu — жалоб мало, и они обычно решаются ulimits/iptables).
Docker на Debian 12 ставится свежий (26–28.x), но старые образы 4–5-летней давности продолжают работать (linux/amd64).

Сравнение с Ubuntu 20.04 / 22.04

ОС	Рекомендация для твоего legacy-стека	Почему	Риск мелких проблем
Ubuntu 20.04	Самый надёжный (топ-1)	Ближе по времени к 2021 году (твоя версия), glibc 2.31, меньше изменений в ядре/iptables	Минимальный
Debian 12	Можно, хорошо (топ-2)	Стабильный, LTS до 2028, Docker отлично поддерживается, много людей используют для медиа-серверов	Низкий-средний
Ubuntu 22.04	Можно, но чуть рискованнее	glibc 2.35 + изменения в netfilter → иногда iptables-legacy нужно переключать	Средний

Debian 12 ≈ Ubuntu 22.04 по уровню "современности", но Debian часто стабильнее в enterprise-сценариях (меньше неожиданных обновлений).

Что нужно сделать на Debian 12

Установка Docker + Compose (официально, не из репозитория Debian — там старая версия):

sudo apt update
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

→ Теперь docker compose (v2) работает.

Перенос — точно так же, как раньше:
- Скопируй всю /opt/openvidu (с .env, compose.yml, certificates/, recordings/ и т.д.)
- docker save образов на старом → docker load на новом
- В .env проверь/поправь DOMAIN_OR_PUBLIC_IP (если IP/домен изменился)
- cd /opt/openvidu && sudo docker compose up -d
Возможные фиксы на Debian 12 (редко, но бывает):
- Нет интернета в контейнерах или странная сеть → sudo update-alternatives --set iptables /usr/sbin/iptables-legacy (или nftables → legacy)
- KMS не стартует / high CPU / краши → Добавь в kms-сервис в docker-compose:
```
ulimits:
  nofile:
    soft: 65535
    hard: 65535
```
  Перезапусти.
- Порты 3478/UDP, 40000-57000 — убедись, что firewall (ufw/iptables) пропускает их.
- Let's Encrypt — если сертификаты не валидируются → временно CERTIFICATE_TYPE=selfsigned для теста.

Итог

Debian 12 — хороший выбор, если сервер уже на нём или ты предпочитаешь Debian (стабильность, меньший размер обновлений). Шансы успеха ~90–95%, почти как на Ubuntu 20.04.
Если хочешь максимальную надёжность без тестов → всё же Ubuntu 20.04.
Если выберешь Debian 12 — после запуска сразу смотри sudo docker compose logs -f kms openvidu-server coturn и проверь https://твой-домен:4443 (должен быть status OK).

Если решишь пробовать и будут логи с ошибками — присылай, разберём по шагам. Удачи с миграцией!

Admin

На Debian 13?

Admin

Да, на Debian 13 (Trixie) можно запустить твой старый OpenVidu 2.19.0 с Kurento 6.16.0 в Docker — это вполне реально и должно работать стабильно.
Debian 13 вышел в августе 2025 года (13.0), а сейчас (март 2026) уже на версии 13.4 с кучей фиксов безопасности и багов. Это свежая стабильная ветка, поддержка до 2028 + LTS до 2030.

Почему совместимость должна быть хорошей (почти как на Debian 12)

Всё в Docker — хост-ОС влияет минимально: ядро Linux 6.1+ (в 13-й версии), glibc 2.36–2.38. Старые образы (Kurento/OpenVidu 2019–2021 годов, основаны на Ubuntu 18.04 внутри) продолжают запускаться без проблем в контейнерах.
Твой compose использует network_mode: host + bind-mount'ы → сеть, порты и файлы работают одинаково независимо от дистрибутива.
Docker на Debian 13 ставится самый свежий (версии 26–28.x+), но backward-совместимость с legacy-образами сохраняется (linux/amd64, без критических breaking changes для такого стека).
Нет известных фатальных проблем с Kurento 6.x в Docker именно на Debian 13 (сообщество использует похожие медиа-сервера на новых Debian без жалоб на этот стек).

Сравнение с предыдущими вариантами (Debian 12 / Ubuntu 20.04 / 22.04)

ОС	Рекомендация для твоего legacy OpenVidu 2.19	Почему	Риск мелких проблем
Ubuntu 20.04	Самый надёжный (топ-1)	Ближе по времени к твоей версии (2020), меньше изменений в ядре/сетевом стеке	Минимальный
Debian 12	Отличный (топ-2)	Стабильный, проверенный, LTS до 2028	Низкий
Debian 13	Можно, хорошо (топ-3)	Свежий stable, улучшения в безопасности/производительности, поддержка до 2030	Низкий-средний
Ubuntu 22.04	Можно, но чуть рискованнее	glibc 2.35 + netfilter изменения → иногда iptables-legacy нужен	Средний

Debian 13 ≈ Debian 12 по стабильности, но с более новым ядром, glibc и пакетами → чуть больше шансов на "мелкие сюрпризы" с очень старыми образами, но на практике их почти нет для Docker-based медиа-серверов.

Что нужно сделать на Debian 13 (почти идентично Debian 12)

Установка Docker + Compose (официальный способ, чтобы была свежая версия):

sudo apt update
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian bookworm stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
# ↑ для Debian 13 используй "trixie" вместо "bookworm", если репозиторий уже обновлён; проверь на https://docs.docker.com/engine/install/debian/
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Перенос — стандартно:
- Скопируй всю /opt/openvidu (.env, docker-compose.yml, certificates/, recordings/ и т.д.)
- docker save нужных образов на старом сервере → docker load на новом
- Поправь .env (DOMAIN_OR_PUBLIC_IP, если домен/IP изменился)
- cd /opt/openvidu && sudo docker compose up -d
Возможные фиксы (редко, но на новых Debian бывает чаще):
- iptables/nftables конфликт → sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
- KMS не стартует/high CPU → Добавь в kms-сервис:
```
ulimits:
  nofile: 65535:65535
  nproc: 65535:65535
```
- Порты заблокированы → sudo ufw allow 4443,3478/udp,80,443 + диапазон 40000-65535/udp если нужно.
- Let's Encrypt → если не валидируется, переключи временно на selfsigned.

Итог

Debian 13 — нормальный и даже хороший выбор в 2026 году: свежий, стабильный, с долгой поддержкой. Шансы успеха ~90–95% (почти как на Debian 12).
Если хочешь максимум предсказуемости без лишних тестов → Ubuntu 20.04 или Debian 12 всё ещё чуть безопаснее.
Но если сервер планируется на Debian 13 — пробуй смело, после запуска просто проверь логи kms/openvidu-server и доступ к :4443.

Если после миграции будут конкретные ошибки в логах — присылай, разберём. Удачи!

Admin

Это сервер, куда я хочу поставить старый OpenVidu. Пойдёт?
user@debian:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp0s31f6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 10:7b:44:4a:76:58 brd ff:ff:ff:ff:ff:ff
    altname enx107b444a7658
    inet 91.221.70.18/23 brd 91.221.71.255 scope global enp0s31f6
       valid_lft forever preferred_lft forever
3: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 10:66:6a:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
       valid_lft forever preferred_lft forever
5: incusbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 10:66:6a:24:4c:3a brd ff:ff:ff:ff:ff:ff
    inet 10.214.97.1/24 scope global incusbr0
       valid_lft forever preferred_lft forever
8: vethVUwRoA@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
    link/ether fe:b6:d0:22:f8:2c brd ff:ff:ff:ff:ff:ff link-netnsid 3
12: vethajhobZ@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
    link/ether fe:8c:99:e5:35:85 brd ff:ff:ff:ff:ff:ff link-netnsid 6
14: vethbVecex@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
    link/ether fe:13:fe:c9:6c:7a brd ff:ff:ff:ff:ff:ff link-netnsid 8
15: br-mailcow: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether ca:75:43:04:83:b5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/24 brd 10.0.0.255 scope global br-mailcow
       valid_lft forever preferred_lft forever
17: br-c633aa5852cd: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 8a:84:f5:87:50:52 brd ff:ff:ff:ff:ff:ff
    inet 172.22.0.1/16 brd 172.22.255.255 scope global br-c633aa5852cd
       valid_lft forever preferred_lft forever
18: br-e934d8635c04: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether ca:65:bd:6d:01:3c brd ff:ff:ff:ff:ff:ff
    inet 172.21.0.1/16 brd 172.21.255.255 scope global br-e934d8635c04
       valid_lft forever preferred_lft forever
19: br-ec99f735c413: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 46:24:f9:78:76:1e brd ff:ff:ff:ff:ff:ff
    inet 172.20.0.1/16 brd 172.20.255.255 scope global br-ec99f735c413
       valid_lft forever preferred_lft forever
20: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 16:b9:c3:4d:00:d2 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
21: br-4477e29f02b8: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 4a:d6:91:ed:e8:09 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.1/16 brd 172.19.255.255 scope global br-4477e29f02b8
       valid_lft forever preferred_lft forever
24: veth89ee70e@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 1a:40:2d:ae:b3:47 brd ff:ff:ff:ff:ff:ff link-netnsid 11
26: vethbd4be89@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 5e:0d:13:3d:9e:46 brd ff:ff:ff:ff:ff:ff link-netnsid 13
27: vethc7c5b8d@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether ca:16:96:59:83:07 brd ff:ff:ff:ff:ff:ff link-netnsid 14
28: vethebc996c@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 86:33:89:90:76:0a brd ff:ff:ff:ff:ff:ff link-netnsid 15
31: veth57217b8@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 76:33:ff:93:91:78 brd ff:ff:ff:ff:ff:ff link-netnsid 18
32: vethb99ec88@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 5a:83:b1:af:64:0c brd ff:ff:ff:ff:ff:ff link-netnsid 19
34: veth7aeb529@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 1e:b6:b1:de:c5:77 brd ff:ff:ff:ff:ff:ff link-netnsid 21
36: veth87b746c@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether a6:32:81:21:15:7e brd ff:ff:ff:ff:ff:ff link-netnsid 23
38: veth3b8a4aa@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether de:d8:83:4a:24:fa brd ff:ff:ff:ff:ff:ff link-netnsid 25
39: vethc29d31d@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 5a:e5:4b:aa:18:d3 brd ff:ff:ff:ff:ff:ff link-netnsid 26
41: veth1050fb7@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 26:e6:45:24:5b:0b brd ff:ff:ff:ff:ff:ff link-netnsid 28
42: vethc6b8f7a@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 46:cb:1e:f8:ff:ee brd ff:ff:ff:ff:ff:ff link-netnsid 29
44: veth00edd6d@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether f2:7e:4f:d7:ce:26 brd ff:ff:ff:ff:ff:ff link-netnsid 31
67: vethae06ec59@if66: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master incusbr0 state UP group default qlen 1000
    link/ether ee:4e:34:28:63:44 brd ff:ff:ff:ff:ff:ff link-netnsid 5
82: veth9da0b22@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether e2:95:29:eb:23:0a brd ff:ff:ff:ff:ff:ff link-netnsid 30
84: vethc41dbd7@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 6e:87:3e:51:59:f9 brd ff:ff:ff:ff:ff:ff link-netnsid 20
98: br-2634df5227f8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 7a:04:96:1b:61:7a brd ff:ff:ff:ff:ff:ff
    inet 172.18.0.1/16 brd 172.18.255.255 scope global br-2634df5227f8
       valid_lft forever preferred_lft forever
99: veth6108f2f@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether 96:3c:67:bb:7b:06 brd ff:ff:ff:ff:ff:ff link-netnsid 9
100: veth8f3bc1e@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether e6:80:fe:b2:39:a5 brd ff:ff:ff:ff:ff:ff link-netnsid 10
101: veth80455b9@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether 1e:f1:c6:81:b7:0c brd ff:ff:ff:ff:ff:ff link-netnsid 12
102: vethd282c13@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether 4a:33:75:86:75:fe brd ff:ff:ff:ff:ff:ff link-netnsid 16
103: veth2270c1b@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether 92:4f:1a:f4:7d:a7 brd ff:ff:ff:ff:ff:ff link-netnsid 17
104: vethe96ff62@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether 16:65:bd:0e:78:70 brd ff:ff:ff:ff:ff:ff link-netnsid 37
105: vethce3b02b@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether 5e:c5:c0:50:49:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 38
106: vethb77af69@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether d2:5f:a2:13:bf:a3 brd ff:ff:ff:ff:ff:ff link-netnsid 39
107: veth8aaa27b@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-2634df5227f8 state UP group default
    link/ether c6:f0:04:8b:a1:f1 brd ff:ff:ff:ff:ff:ff link-netnsid 40
136: veth6A2EnF@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
    link/ether fe:df:b2:cf:34:db brd ff:ff:ff:ff:ff:ff link-netnsid 2
158: vethf4a74cc2@if157: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master incusbr0 state UP group default qlen 1000
    link/ether 12:4c:02:5c:32:15 brd ff:ff:ff:ff:ff:ff link-netnsid 1
212: veth5809eb30@if211: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master incusbr0 state UP group default qlen 1000
    link/ether 42:7c:14:d4:52:f1 brd ff:ff:ff:ff:ff:ff link-netnsid 7
226: vethfb5f3af@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether 1e:f9:2c:5f:f4:a4 brd ff:ff:ff:ff:ff:ff link-netnsid 4
248: veth163c0711@if247: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master incusbr0 state UP group default qlen 1000
    link/ether 56:5f:e0:05:bb:7f brd ff:ff:ff:ff:ff:ff link-netnsid 24
250: vethc181a6d@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether aa:c3:8b:a7:24:ae brd ff:ff:ff:ff:ff:ff link-netnsid 22
252: veth83ded6c@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-mailcow state UP group default
    link/ether ce:a8:89:37:fc:74 brd ff:ff:ff:ff:ff:ff link-netnsid 0
user@debian:~$ sudo docker ps -a
[sudo] password for user:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ef8857d8750b jitsi/jibri:stable "/init" 4 weeks ago Up 4 weeks docker-jitsi-meet-stable-9955-jibri-4
00a505e73990 jitsi/jibri:stable "/init" 4 weeks ago Up 4 weeks docker-jitsi-meet-stable-9955-jibri-1
f73424f5ad75 jitsi/jibri:stable "/init" 4 weeks ago Up 4 weeks docker-jitsi-meet-stable-9955-jibri-5
7b1114228acd jitsi/jibri:stable "/init" 4 weeks ago Up 4 weeks docker-jitsi-meet-stable-9955-jibri-3
97d06a315584 jitsi/jibri:stable "/init" 4 weeks ago Up 4 weeks docker-jitsi-meet-stable-9955-jibri-2
9ec60c2714da jitsi/web:stable "/init" 4 weeks ago Up 4 weeks 0.0.0.0:8000->80/tcp, [::]:8000->80/tcp, 0.0.0.0:32769->443/tcp, [::]:32769->443/tcp docker-jitsi-meet-stable-9955-web-1
3b268c83eebb jitsi/jvb:stable "/init" 4 weeks ago Up 4 weeks 127.0.0.1:8080->8080/tcp, 0.0.0.0:10000->10000/udp, [::]:10000->10000/udp docker-jitsi-meet-stable-9955-jvb-1
0407789c9d2b jitsi/jicofo:stable "/init" 4 weeks ago Up 4 weeks 127.0.0.1:8888->8888/tcp docker-jitsi-meet-stable-9955-jicofo-1
8aafa6dd09a6 jitsi/prosody:stable "/init" 4 weeks ago Up 4 weeks 5222/tcp, 5269/tcp, 5280/tcp, 5347/tcp docker-jitsi-meet-stable-9955-prosody-1
b9958b9112f0 ghcr.io/mailcow/watchdog:2.09 "/watchdog.sh" 3 months ago Up 4 weeks mailcowdockerized-watchdog-mailcow-1
3c9e72180bac ghcr.io/mailcow/acme:1.94 "/sbin/tini -g -- /s…" 3 months ago Up 2 months mailcowdockerized-acme-mailcow-1
6ef4395a733c ghcr.io/mailcow/nginx:1.05 "/docker-entrypoint.…" 3 months ago Up 2 months 0.0.0.0:8087->8087/tcp, [::]:8087->8087/tcp, 80/tcp, 0.0.0.0:8443->8443/tcp, [::]:8443->8443/tcp mailcowdockerized-nginx-mailcow-1
cb21341aa47e ghcr.io/mailcow/rspamd:2.4 "/docker-entrypoint.…" 3 months ago Up 24 hours mailcowdockerized-rspamd-mailcow-1
252c44735dc2 mcuadros/ofelia:latest "/usr/bin/ofelia dae…" 3 months ago Up 2 months mailcowdockerized-ofelia-mailcow-1
9ee227f29cb7 ghcr.io/mailcow/phpfpm:1.94 "/docker-entrypoint.…" 3 months ago Up 2 months 9000/tcp mailcowdockerized-php-fpm-mailcow-1
c34bde9b2876 ghcr.io/mailcow/dovecot:2.35 "/docker-entrypoint.…" 3 months ago Up 2 months 0.0.0.0:110->110/tcp, [::]:110->110/tcp, 0.0.0.0:143->143/tcp, [::]:143->143/tcp, 0.0.0.0:993->993/tcp, [::]:993->993/tcp, 0.0.0.0:995->995/tcp, [::]:995->995/tcp, 0.0.0.0:4190->4190/tcp, [::]:4190->4190/tcp, 127.0.0.1:19991->12345/tcp mailcowdockerized-dovecot-mailcow-1
5e3f8af58ec6 ghcr.io/mailcow/postfix:1.81 "/docker-entrypoint.…" 3 months ago Up 4 weeks 0.0.0.0:25->25/tcp, [::]:25->25/tcp, 0.0.0.0:465->465/tcp, [::]:465->465/tcp, 0.0.0.0:587->587/tcp, [::]:587->587/tcp, 588/tcp mailcowdockerized-postfix-mailcow-1
82b545993e14 mariadb:10.11 "docker-entrypoint.s…" 3 months ago Up 2 months 127.0.0.1:13306->3306/tcp mailcowdockerized-mysql-mailcow-1
3658a74a3001 ghcr.io/mailcow/postfix-tlspol:1.0 "/docker-entrypoint.…" 3 months ago Up 2 months mailcowdockerized-postfix-tlspol-mailcow-1
f3d4b8974c23 ghcr.io/mailcow/clamd:1.71 "/sbin/tini -g -- /c…" 3 months ago Up 2 months (healthy) mailcowdockerized-clamd-mailcow-1
f34574101473 redis:7.4.6-alpine "/bin/sh /redis-conf…" 3 months ago Up 2 months 127.0.0.1:7654->6379/tcp mailcowdockerized-redis-mailcow-1
12beef85595a memcached:alpine "docker-entrypoint.s…" 3 months ago Up 2 months 11211/tcp mailcowdockerized-memcached-mailcow-1
1410268219ba ghcr.io/mailcow/dockerapi:2.11 "/bin/sh /app/docker…" 3 months ago Up 2 months mailcowdockerized-dockerapi-mailcow-1
a15b629f3645 ghcr.io/mailcow/olefy:1.15 "python3 -u /app/ole…" 3 months ago Up 2 months mailcowdockerized-olefy-mailcow-1
9725ac715566 ghcr.io/mailcow/sogo:1.136 "/docker-entrypoint.…" 3 months ago Up 3 days mailcowdockerized-sogo-mailcow-1
032128623ab7 ghcr.io/mailcow/netfilter:1.63 "/bin/sh -c /app/doc…" 3 months ago Up 2 months mailcowdockerized-netfilter-mailcow-1
ebbc3891e944 ghcr.io/mailcow/unbound:1.24 "/docker-entrypoint.…" 3 months ago Up 10 days (healthy) 53/tcp, 53/udp mailcowdockerized-unbound-mailcow-1
c59e388e9638 ghcr.io/requarks/wiki:2 "docker-entrypoint.s…" 4 months ago Exited (0) 2 months ago wikijs-wiki-1
6a298ad1597b postgres:17-alpine "docker-entrypoint.s…" 4 months ago Exited (0) 2 months ago wikijs-db-1
7fb4f9c3a817 portainer/portainer-ce "/portainer" 4 months ago Up 2 months 8000/tcp, 9443/tcp, 0.0.0.0:9000->9000/tcp, [::]:9000->9000/tcp portainer
ac975655c125 hello-world "/hello" 5 months ago Exited (0) 3 months ago jolly_thompson
user@debian:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.2
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
user@debian:~$ sudo docker -h
Flag shorthand -h has been deprecated, use --help
Usage: docker [OPTIONS] COMMAND
A self-sufficient runtime for containers
Common Commands:
  run Create and run a new container from an image
  exec Execute a command in a running container
  ps List containers
  build Build an image from a Dockerfile
  bake Build from a file
  pull Download an image from a registry
  push Upload an image to a registry
  images List images
  login Authenticate to a registry
  logout Log out from a registry
  search Search Docker Hub for images
  version Show the Docker version information
  info Display system-wide information
Management Commands:
  builder Manage builds
  buildx* Docker Buildx
  compose* Docker Compose
  container Manage containers
  context Manage contexts
  image Manage images
  manifest Manage Docker image manifests and manifest lists
  network Manage networks
  plugin Manage plugins
  system Manage Docker
  volume Manage volumes
Swarm Commands:
  swarm Manage Swarm
Commands:
  attach Attach local standard input, output, and error streams to a running container
  commit Create a new image from a container's changes
  cp Copy files/folders between a container and the local filesystem
  create Create a new container
  diff Inspect changes to files or directories on a container's filesystem
  events Get real time events from the server
  export Export a container's filesystem as a tar archive
  history Show the history of an image
  import Import the contents from a tarball to create a filesystem image
  inspect Return low-level information on Docker objects
  kill Kill one or more running containers
  load Load an image from a tar archive or STDIN
  logs Fetch the logs of a container
  pause Pause all processes within one or more containers
  port List port mappings or a specific mapping for the container
  rename Rename a container
  restart Restart one or more containers
  rm Remove one or more containers
  rmi Remove one or more images
  save Save one or more images to a tar archive (streamed to STDOUT by default)
  start Start one or more stopped containers
  stats Display a live stream of container(s) resource usage statistics
  stop Stop one or more running containers
  tag Create a tag TARGET_IMAGE that refers to SOURCE_IMAGE
  top Display the running processes of a container
  unpause Unpause all processes within one or more containers
  update Update configuration of one or more containers
  wait Block until one or more containers stop, then print their exit codes
Global Options:
      --config string Location of client config files (default "/root/.docker")
  -c, --context string Name of the context to use to connect to the daemon (overrides DOCKER_HOST env var and default context set with "docker context use")
  -D, --debug Enable debug mode
  -H, --host string Daemon socket to connect to
  -l, --log-level string Set the logging level ("debug", "info", "warn", "error", "fatal") (default "info")
      --tls Use TLS; implied by --tlsverify
      --tlscacert string Trust certs signed only by this CA (default "/root/.docker/ca.pem")
      --tlscert string Path to TLS certificate file (default "/root/.docker/cert.pem")
      --tlskey string Path to TLS key file (default "/root/.docker/key.pem")
      --tlsverify Use TLS and verify the remote
  -v, --version Print version information and quit
Run 'docker COMMAND --help' for more information on a command.
For more help on how to use Docker, head to https://docs.docker.com/go/guides/
user@debian:~$ sudo docker -v
Docker version 29.1.3, build f52814d
user@debian:~$

Admin

Да, твой сервер на Debian 13 (Trixie) вполне подойдёт для переноса и запуска старого OpenVidu 2.19.0 с Kurento 6.16.0 в Docker.
Это не идеальный вариант (как Ubuntu 20.04), но шансы на успех высокие — 90%+, особенно учитывая, что всё в контейнерах и использует network_mode: host.

Почему должно работать

Docker установлен свежий (29.1.3) — официально поддерживает Debian 13 (Trixie), репозиторий Docker его видит как stable.
Старые образы совместимы — Kurento 6.16.0 и OpenVidu 2.19.0 (2019–2021) основаны на старых Ubuntu внутри (16.04/18.04), glibc/kernel хоста (Debian 13: glibc 2.41+, kernel 6.12 LTS) не ломают их. Нет известных критических проблем с этим стеком на новых Debian (поиски по GitHub/issues/форумам за 2025–2026 не выявили фатальных багов для Kurento/OpenVidu на Trixie).
network_mode: host — твоя конфигурация обходит большинство сетевых сюрпризов Docker (iptables/nftables изменения в новых ядрах).
Публичный IP есть — 91.221.70.18 на enp0s31f6 — это хорошо для WebRTC/ICE/STUN/TURN (Kurento и coturn будут использовать его напрямую).

Что уже хорошо на сервере

Docker работает (ps -a показывает кучу контейнеров: Jitsi, Mailcow, Portainer и т.д.).
Порты частично заняты (Jitsi: 10000/udp, 8000/tcp → 32769/tcp; Mailcow: 25,465,587,993 и т.д.).
Много bridge-сетей (docker0, br-mailcow, br-2634df... и т.д.) — но поскольку OpenVidu использует host-сеть, конфликтов с ними не будет.

Потенциальные проблемы и как их обойти (на Debian 13 чаще, чем на 12)

iptables/nftables конфликт (новое ядро 6.12 использует nftables по умолчанию):
```
sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy
```
Перезагрузи Docker после: sudo systemctl restart docker
Ulimits для KMS (Kurento любит много файлов/процессов):
В docker-compose.yml в секции kms добавь/увеличь:
```
ulimits:
  nofile:
    soft: 65535
    hard: 65535
  nproc:
    soft: 65535
    hard: 65535
```
Затем docker compose up -d --force-recreate kms
Порты конфликтуют:
- OpenVidu: 4443 (сервер), 3478/udp (coturn), 80/443 (nginx-proxy), RTP-диапазон ~40000–57000/udp.
- Jitsi уже занимает 10000/udp и HTTPS на 32769.
- Mailcow — SMTP/IMAP/POP3/HTTPS.
  → Убедись, что 4443, 3478/udp, 80/443 свободны (netstat/ss -tuln | grep ':80|:443|:4443|:3478').
  Если заняты — останови конфликтующие сервисы временно или перенеси OpenVidu на другие порты (но это сломает клиентский код → лучше освободить).
Let's Encrypt сертификаты:
- Перенеси папку certificates/ → но если IP/домен изменился, certbot в nginx-контейнере может не обновить.
  → В .env временно поставь CERTIFICATE_TYPE=selfsigned для теста, потом верни letsencrypt и перезапусти.

Firewall (ufw или nftables):

sudo ufw allow 4443/tcp
sudo ufw allow 3478/udp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from any to any port 40000:57000 proto udp   # для RTP, если нужно

План действий (коротко)

Скопируй всю /opt/openvidu с старого сервера (rsync -a или tar).
Перенеси образы (docker save ... -o openvidu.tar → docker load -i openvidu.tar).
Поправь .env: DOMAIN_OR_PUBLIC_IP=91.221.70.18 (или media2.nbics.net, если DNS на него смотрит).
Выполни фиксы выше (iptables-legacy, ulimits).
cd /opt/openvidu && sudo docker compose up -d
Смотри логи: sudo docker compose logs -f kms openvidu-server coturn nginx
- KMS должен быть healthy.
- OpenVidu-server: "OpenVidu Server started" + listening on 5443 (внутри).
- Проверь: curl -k https://91.221.70.18:4443 (или твой домен) → должен ответить OK или status.

Если после запуска KMS крашит (high CPU, segfault) или WebRTC не работает — пришли логи kms/openvidu-server, разберём. Но в целом — сервер годный, просто новый дистрибутив требует чуть больше внимания к сетевым/лимитам вещам. Удачи!

Admin

А Debian 11?

Admin

Да, на Debian 11 (Bullseye) тоже можно запустить твой старый OpenVidu 2.19.0 с Kurento 6.16.0 в Docker — и это даже один из самых "безопасных" вариантов по совместимости среди всех, о которых мы говорили.

Debian 11 вышел в августе 2021 года (как раз примерно в то время, когда твоя версия OpenVidu 2.19.0 была актуальной), так что стек ближе по времени к оригинальной разработке. Многие люди успешно запускали похожие медиа-сервера на Bullseye без проблем.

Текущий статус Debian 11 (на март 2026)

Полная поддержка закончилась в августе 2024.
Сейчас идёт LTS (Long Term Support) от Debian LTS-команды — до 31 августа 2026 (ещё ~5 месяцев).
В LTS получают только критические security-фиксы и важные баги — обычные обновления пакетов не приходят.
Docker официально поддерживается на Debian 11 (oldoldstable) — свежие версии (до 29.x+) ставятся из репозитория Docker без проблем.

Сравнение с другими вариантами (для твоего legacy-стека)

ОС	Совместимость с OpenVidu 2.19 / Kurento 6.16	Актуальность поддержки (март 2026)	Риск проблем	Рекомендация
Debian 11 (Bullseye)	Отличная (самая близкая по времени)	LTS до августа 2026 (критические фиксы)	Минимальный	Топ-1 для точного переноса без сюрпризов
Ubuntu 20.04	Отличная	Полная поддержка до апреля 2025	Минимальный	Тоже топ-уровень
Debian 12 (Bookworm)	Хорошая	Полная до июня 2026 + LTS до 2028	Низкий	Хороший баланс
Debian 13 (Trixie)	Хорошая, но чуть больше шансов на мелкие баги	Полная до 2028 + LTS до 2030	Низкий-средний	Нормально, но новее
Ubuntu 22.04	Хорошая	Полная до апреля 2027	Средний	Можно, но не идеал

Debian 11 — один из лучших выборов именно для твоего случая, потому что:

glibc/kernel ближе к тому, что было при разработке Kurento 6.16.0 (меньше шансов на несовместимость libs внутри контейнера).
Docker ставится свежий (29.x), но образы 2.19.0 работают стабильно.
network_mode: host обходит большинство изменений в новых ядрах (nftables и т.д.).

Что нужно на Debian 11

Установка Docker (если ещё не стоит) — официальный способ:

sudo apt update
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian bullseye stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io docker-compose-plugin

Перенос — стандартный:
- Скопируй /opt/openvidu целиком.
- docker save → docker load образов.
- В .env: DOMAIN_OR_PUBLIC_IP=91.221.70.18 (или домен).
- docker compose up -d
Фиксы (могут не понадобиться, но проверь):
- iptables-legacy (если сеть глючит): sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
- ulimits для kms (добавь в docker-compose.yml, как раньше).
- Порты: проверь ss -tuln | grep '80\|443\|4443\|3478' — освободи, если заняты Jitsi/Mailcow.
- Firewall: ufw allow нужные порты + RTP-диапазон.

Итог

Debian 11 — пойдёт отлично, и это один из самых предсказуемых вариантов для твоего старого OpenVidu (лучше, чем 13-й в плане "без сюрпризов").
Минус только в том, что через 5 месяцев (август 2026) LTS закончится → потом только коммерческий ELTS (платный) или апгрейд до 12/13.
Если сервер уже на 11-й — используй её смело. После запуска просто проверь логи kms и openvidu-server + доступ к :4443.

Если решишь ставить и будут логи/ошибки — кидай, помогу. Удачи с миграцией!

Admin

Для Ubuntu 20.04 такая инструкция пойдёт?
# Обновите список пакетов и установите необходимые зависимости:
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

Admin

Нет, твоя инструкция не подойдёт напрямую для Ubuntu 20.04, потому что она скопирована/адаптирована под Debian (там https://download.docker.com/linux/debian и ключ сохраняется как .asc без dearmor).

Для Ubuntu (включая 20.04 Focal) официальная инструкция Docker отличается:

Репозиторий: https://download.docker.com/linux/ubuntu
Ключ обычно сохраняют в dearmored-формате (.gpg), а не .asc.
Формат sources.list теперь часто использует новый .sources файл (deb822-style), но на 20.04 старый /etc/apt/sources.list.d/docker.list тоже работает.
Ubuntu 20.04 всё ещё поддерживается Docker Engine (хоть и не в списке "новейших" LTS в 2026 году — Docker продолжает предоставлять пакеты для focal через репозиторий).

Правильная инструкция для Ubuntu 20.04 (2025–2026 годы, по актуальным официальным докам Docker)

# 1. Удалить старые/конфликтующие пакеты (если были)
sudo apt-get remove docker docker-engine docker.io containerd runc podman-docker docker-compose docker-doc docker-compose-v2

# 2. Обновить и установить зависимости
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 3. Создать директорию для ключей
sudo install -m 0755 -d /etc/apt/keyrings

# 4. Добавить официальный GPG-ключ Docker (dearmor → .gpg)
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 5. Добавить репозиторий Docker (старый стиль list-файла — надёжнее на 20.04)
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Альтернатива: новый deb822-формат (если хочешь как в свежих доках)
# sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
# Types: deb
# URIs: https://download.docker.com/linux/ubuntu
# Suites: $(lsb_release -cs)
# Components: stable
# Signed-By: /etc/apt/keyrings/docker.gpg
# EOF

# 6. Обновить индекс пакетов и установить Docker
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 7. Добавить текущего пользователя в группу docker (чтобы без sudo)
sudo usermod -aG docker $USER
newgrp docker   # или перелогинься

# 8. Проверить
sudo docker run hello-world
docker --version
docker compose version   # должен показать v2.x

Почему твоя инструкция не сработает

linux/debian вместо linux/ubuntu → пакеты не найдутся или будут несовместимы.
Ключ как .asc без --dearmor → в Ubuntu предпочитают бинарный .gpg (dearmored).
VERSION_CODENAME из /etc/os-release — ок, но лучше lsb_release -cs для надёжности на старых Ubuntu.

Дополнительные советы для твоего случая (OpenVidu 2.19 на Ubuntu 20.04)

После установки Docker — просто копируй папку /opt/openvidu, загружай образы (docker load), поправляй .env и docker compose up -d.
Если возникнут ошибки с GPG или репозиторием — проверь, что lsb_release -cs возвращает focal.
Ubuntu 20.04 уже в конце поддержки (апрель 2025), но Docker пакеты для неё продолжают выходить (проверено по репозиторию на 2026 год).

Если выполнишь эти шаги и будут ошибки — пришли вывод apt update или логов установки, помогу поправить. Удачи!

База знаний (цифровой суверенитет)

Навигация

Учётная запись

Навигация

Учётная запись

Перенос старого OpenVidu на новый сервер

Что именно нужно перенести (самый надёжный вариант)

Альтернативные варианты (если не хочется тащить образы)

Резюме — что лучше всего сделать прямо сейчас

Почему перенос работает почти всегда идеально

Краткий план «самый надёжный и быстрый» (ещё раз)

Самые важные вещи, которые ещё стоит посмотреть / предоставить

Краткий вердикт на текущий момент

Почему совместимость хорошая

Что нужно сделать на новом сервере (Ubuntu 20.04)

Возможные мелкие проблемы и как фиксить

Сравнение 20.04 vs 22.04 для твоего случая

Почему 22.04 скорее всего сработает

Что может пойти не так на 22.04 (и как фиксить)

Итоговый совет

Почему совместимость хорошая

Сравнение с Ubuntu 20.04 / 22.04

Что нужно сделать на Debian 12

Итог

Почему совместимость должна быть хорошей (почти как на Debian 12)

Сравнение с предыдущими вариантами (Debian 12 / Ubuntu 20.04 / 22.04)

Что нужно сделать на Debian 13 (почти идентично Debian 12)

Итог

Почему должно работать

Что уже хорошо на сервере

Потенциальные проблемы и как их обойти (на Debian 13 чаще, чем на 12)

План действий (коротко)

Текущий статус Debian 11 (на март 2026)

Сравнение с другими вариантами (для твоего legacy-стека)

Что нужно на Debian 11

Итог

Правильная инструкция для Ubuntu 20.04 (2025–2026 годы, по актуальным официальным докам Docker)

Почему твоя инструкция не сработает

Дополнительные советы для твоего случая (OpenVidu 2.19 на Ubuntu 20.04)