Содержание

Офлайн режим установки

Требования для офлайн-режима

Доставка образов только через SSH/22

Локальные уменьшенные репозитории на виртуальных машинах

Диагностика

Процесс установки

Компоненты инфраструктуры

Технические требования

Виртуальные машины

Требования к вычислительным ресурсам для пилотной инсталляции

Дисковое пространство

Поддерживаемые версии окружения

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

Получите комплект поставки

Настройте целевые серверы

Настройте сервер установки

Настройте серверы для дополнительных конвертеров

Настройте серверы для SIP-коннектора

Если используется офлайн-режим установки

Создайте SSH-пользователя

Настройте сетевое взаимодействие

Межпродуктовое взаимодействие в стандартной-поставке

Пользовательские входящие порты 

Порты для работы SIP-коннектора 

Дополнительные интеграционные порты

Настройте DNS-зону 

Правила формирования доменов

Типовой резолв для поставки «Встречи + Чаты + Платформа» 

Выполните проверку DNS 

Если корпоративный DNS будет настроен после установки

Выпустите TLS-сертификаты

Офлайн режим установки

Выберите режим установки МТС Линк — онлайн или офлайн.

При онлайн-режиме для установки используется корпоративный репозиторий МТС Линк, содержащий роли Ansible, Docker-контейнеры и локальный регистри.

Офлайн-режим используется, если

• этого требуют политики информационной безопасности
• используется собственный регистри
• ограничен доступ в интернет или интернет-соединение неустойчиво.

В таком случае представители МТС Линк передают вам файл custom-registry.img . Это ext4 image с локальной поставкой Ansible-ролей и Docker Registry v2 storage.

Требования для офлайн-режима

• на сервере установки доступны утилиты mount, docke и curl
• установщик запущен с правами, достаточными для mount loop image и управления Docker
• целевые виртуальные машины доступны по SSH
• в прямом режиме целевые виртуальные машины видят сервер установки по адресу <registry-url> и порту 5000
• в прямом режиме Docker на целевых виртуальных машинах допускает HTTP registry через insecure-registries.

Доставка образов только через SSH/22

Если между сервером установки и целевыми виртуальными машинами нельзя открыть порт TCP/5000, включите в разделе Офлайн веб-установщика опцию Доставлять образы на удаленные ВМ через SSH (порт 22). Установщик в этом режиме:

• публикует registry на сервере установки только на 127.0.0.1:5000
• для каждой удаленной виртуальной машины открывает reverse SSH-туннель до её 127.0.0.1:5000
• передаёт Ansible адрес registry 127.0.0.1:5000.

Трафик образов идёт внутри уже настроенного SSH-подключения. На каждой целевой виртуальной машины должен быть свободен порт 5000, а в sshd_config требуется AllowTcpForwarding yes. Туннели существуют только во время запуска продукта и закрываются при завершении или ошибке.

Локальные уменьшенные репозитории на виртуальных машинах

Если у машин нет обратного SSH-доступа и не нужен даже временный туннель, используйте параметр:

local_registry_copy_to_hosts (в CLI: offline.registry_copy_to_hosts = true ; в session JSON:

offline_registry_copy_to_hosts: true ). Этот режим несовместим с local_registry_via_ssh .

Установщик берёт сформированный план установки, сопоставляет стадии с путями ролей в архивах и собирает для каждой машины один самостоятельный Registry v2 storage только из образов назначенных ей ролей. 

Общие образы роли сохраняются на всех нужных машинах. Если структуру нового архива невозможно сопоставить со стадией, используется безопасная консервативная выборка всего продукта. Поставка передаётся исходящим SSH-подключением с сервера установки. Для каждого выбранного образа передаются его manifest, config и нужные layer blobs, остальные образы из custom-registry.img не копируются.

По умолчанию данные находятся в /opt/mts-local-registry/data/registry-data , а контейнер local-registry  слушает только 127.0.0.1:5000. Поле Каталог на целевых ВМ позволяет выбрать другой абсолютный путь, например /data/mts-local-registry:  туда же временно загружаются архивы в подкаталог .incoming  , поэтому свободное место в /tmp не требуется. 

Ansible продолжает запускаться с сервера установки, но Docker каждой машины получает образы из собственного 127.0.0.1:5000. Поэтому машинам не требуется доступ ни к серверу установки по TCP/5000, ни к другим машинам по SSH.

Требования: с сервера установки должен открываться SSH/22 к каждой целевой виртуальной машины, на машинах должен быть работающий Docker и права sudo у SSH-пользователя. Копия registry остается на виртуальных машинах после установки для повторного запуска и диагностики, удалить её можно командой sudo rm -rf <выбранный-каталог> после того как она больше нужна.

Диагностика

Проверьте mount:

findmnt /mnt/custom-registry

ls -la /mnt/custom-registry

Проверьте локальный регистри:

docker ps --filter name=local-registry

curl -fsS http://127.0.0.1:5000/v2/

Проверьте доступность регистри с целевой виртуальной машины:

ssh <user>@<vm-ip> 'curl -fsS http://<registry-url>/v2/'

Если Docker на целевой виртуальной машин не тянет образы из HTTP registry, проверьте /etc/docker/daemon.json:

{ 
"insecure-registries": ["<registry-url>"] 
}

Процесс установки

Установка МТС Линк состоит из следующих этапов:

1. Установите основные модули МТС Линк — Встречи, Чаты, Доски и Платформу
2. При необходимости установите дополнительные модули — ИИ-коннектор (саммаризация /транскрибация), дополнительные конвертеры записей, SIP-коннектор (понадобится дополнительная лицензия на Vinteo).

В общем виде процесс установки сводится к следующим шагам:

1. Подготовьте корпоративную инфраструктуру
2. Получите от представителей МТС Линк всё необходимое для установки
3. Установите основные и дополнительные модули
4. Выполните обязательные проверки после установки.

Установка проводится в согласованное окно работ и отсутствие параллельных изменений на виртуальных машинах.

Компоненты инфраструктуры

NTP-сервер — используется для синхронизации времени.

SMTP-сервер — авторизация пользователей в МТС Линк выполняется с помощью одноразовых кодов (OTP via email). Для доставки писем с одноразовыми кодами необходим SMTP-сервер, на котором разрешена отправка почтовых сообщений для данной виртуальной машины — без авторизации и блокировки антиспам-системой.

DNS-сервер— используется для преобразования имен в IP-адреса и обратно.

Push-сервисы — внешние сервисы Apple и Google для отправки push-сообщений на мобильные платформы.

Технические требования

Виртуальные машины

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

Доски не устанавливаются как самостоятельный продукт. Для сценария с Досками в составе поставки также должны быть Встречи и Платформа . Чаты могут входить или не входить в состав лицензии.

Примечание: вы также можете создать отдельную виртуальную машину под сервер установки, который используется для распаковки дистрибутива и запуска установщика. Либо вы можете разместить сервер установки на одной из целевых виртуальных машин.

Требования к вычислительным ресурсам для пилотной инсталляции

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

Практические требования:

• используйте SSD накопители
• закладывайте не менее 500 ГБ под продуктовые виртуальные машины
• контролируйте свободное место в каталоге /opt 
• не размещайте Docker data root на маленьком системном разделе
• синхронизируйте время через NTP
• убедитесь, что CPU поддерживает AVX или AVX2
• убедитесь, что Docker-подсети не пересекаются с корпоративными сетями.

Дисковое пространство

Создайте на диске новый раздел и смонтируйте его в директорию /opt . Скопируйте в него данные Docker data root.

Поддерживаемые версии окружения

Совместимость точной версии продукта и операционной системы необходимо подтвердить в проектной документации перед началом установки.

Важно: не обновляйте операционную систему, Ansible, Python или Docker непосредственно перед установкой без согласования. Изменение версий зависимостей может изменить результат предварительных проверок.

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

Получите комплект поставки

Перед установкой получите у представителей МТС Линк:

1. Дистрибутив установщика
2. Файл с лицензионным ключом. Не формируйте и не изменяйте лицензионный файл самостоятельно: установщик ожидает официальный файл поставки с корректной подписью, составом продуктов и данными регистри
3. При офлайн-режиме инсталляции — ссылку на custom-registry.img с локальной поставкой Ansible-ролей и Docker Registry v2 storage. 

Настройте целевые серверы

Целевые серверы — виртуальные машины, на которых размещаются модули МТС Линк.

1. Создайте виртуальные машины
2. Установите на них операционные системы
3. Назначьте каждой виртуальной машине внутренний IP-адрес. При наличии NAT — внешний
4. Проведите базовую диагностику каждой машины.

lscpu
free -h 
df -h 
lsblk 
cat /etc/os-release 
uname -m 
timedatectl
hostname -f 
ip addr

Дополнительные проверки:

grep -m1 '^flags' /proc/cpuinfo | grep -Eo 'avx2?|sse4_2'

df -h /opt 

ip route  

• время должно быть синхронизировано через NTP-сервер
• разделы под /opt и Docker data root должны иметь достаточный запас
• Docker-подсеть не должна пересекаться с LAN, VPN, Kubernetes и другими Docker-сетями
• имена сервисов должны одинаково резолвиться на сервере установки и целевых виртуальных машинах.

Настройте сервер установки

Сервер установки — виртуальная машина для распаковки дистрибутива и запуска установщика. Вы можете развернуть его на одной из целевых виртуальных машин, либо создать под него отдельную виртуальную машину.

Для сервера установки:

1. Настройте доступы:

• в сеть до rep-box.webinar.ru 
• в сеть до серверов лицензирования
• доступ по SSH до всех виртуальных машин под модули МТС Линк
• доступ на запись в рабочие каталоги установщика.

2. Выдайте права на запуск установщик от root или через sudo

3. Настройте свободный порт веб-установщика, например 9443

4. Назначьте виртуальной машине внутренний IP-адрес. При наличии NAT — внешний

5. Проведите базовую диагностику машины.

lscpu
free -h 
df -h 
lsblk 
cat /etc/os-release 
uname -m 
timedatectl
hostname -f 
ip addr

Дополнительные проверки

grep -m1 '^flags' /proc/cpuinfo | grep -Eo 'avx2?|sse4_2'

df -h /opt 

ip route  

• время должно быть синхронизировано через NTP-сервер
• разделы под /opt и Docker data root должны иметь достаточный запас
• Docker-подсеть не должна пересекаться с LAN, VPN, Kubernetes и другими Docker-сетями
• имена сервисов должны одинаково резолвиться на сервере установки и целевых виртуальных машинах.

Настройте серверы для дополнительных конвертеров

Пропустите этот шаг, если не планируете подключать дополнительные конвертеры записи звонков.

1. Создайте виртуальные машины
2. Установите на них операционные системы. Операционные системы машин, предназначенных для установки дополнительных конвертеров, могут отличаться от операционных систем Встреч
3. Назначьте каждой виртуальной машине внутренний IP-адрес. При наличии NAT — внешний
4. Проведите базовую диагностику каждой машины

lscpu
free -h 
df -h 
lsblk 
cat /etc/os-release 
uname -m 
timedatectl
hostname -f 
ip addr

Дополнительные проверки

grep -m1 '^flags' /proc/cpuinfo | grep -Eo 'avx2?|sse4_2'

df -h /opt 

ip route  

5. Настройте двустороннюю сетевую доступность (связь) с сервером Встреч. Виртуальные машины конвертеров рекомендуется размещать в одном сегменте сети с сервером Встреч.

Настройте серверы для SIP-коннектора

Пропустите этот шаг, если не планируете подключать SIP-коннектор.

Для работы SIP-коннектора необходимо использовать две виртуальные машины с различными компонентами и характеристиками:

1. Компонент WRC
2. Компонент MCU Vinteo.

Настройте серверы

1. Создайте виртуальные машины
2. Установите на них операционные системы. Операционные системы машин, предназначенных для установки дополнительных конвертеров, могут отличаться от операционных систем Встреч
3. Назначьте каждой виртуальной машине внутренний IP-адрес. При наличии NAT — внешний
4. Проведите базовую диагностику каждой машины

lscpu
free -h 
df -h 
lsblk 
cat /etc/os-release 
uname -m 
timedatectl
hostname -f 
ip addr

Дополнительные проверки

grep -m1 '^flags' /proc/cpuinfo | grep -Eo 'avx2?|sse4_2'

df -h /opt 

ip route  

5. Предоставьте доступ до:

• rep-box.webinar.ru
• on-premise-reg.webinar.ru

репозиториям операционной системы (Debian, РЕД ОС или Astra), в которой разворачивается ПО, и/или их зеркалам

6. На машине под MCU Vinteo установите MCU Vinteo.

Если используется офлайн-режим установки

Пропустите этот раздел, если вы используете онлайн-режим установки. Если вы используете офлайн-режим:

1. Получите у представителей МТС Линк ссылку для скачивания custom-registry.img с ролями Ansible, Docker-контейнерами и локальным регистри
2. Распакуйте архив на любой виртуальной машине в любую директорию. Вы можете использовать одну из целевых виртуальных машин либо локальный регистри.

Примечание: если архив не будет распакован до запуска установки, установщик сделает это самостоятельно в процессе установки.

docker-compose.yml
docker-image.registry2.tar
registry-data/
platform.tar.gz
chats.tar.gz
webinar.tar.gz
doski.tar.gz 

Продуктовые архивы ролей остаются внутренней частью image. Для Досок используется файл doski.tar.gz .

Важно

img  должен быть доступен на машине, где запускается установщик. Роли берутся из tar.gz внутри image, Docker-образы — из локального регистри storage внутри custom-registry.img .

Создайте SSH-пользователя

Сервер установки должен подключаться по SSH ко всем целевым виртуальным машинам. Web UI поддерживает аутентификацию по ключу или паролю и отдельно принимает пароль sudo.

Рекомендуется создать отдельного пользователя, например, installer на всех целевых серверах. Требования к пользователю:

• одинаковый пользователь на всех целевых серверах
• авторизация по приватному ключу или паролю
• доступ к /bin/bash 
• права суперпользователя без интерактивного запроса пароля
• проверенный доступ с сервера установки до каждого IP. 

Проверка с сервера установки

Пример для Debian / Astra Linux:

useradd -m -s /bin/bash installer  
usermod -aG sudo installer  
echo "installer ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/installer  
chmod 440 /etc/sudoers.d/installer

Пример для RedOS:

useradd -m -s /bin/bash installer
usermod -aG wheel installer
echo "installer ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/installer
chmod 440 /etc/sudoers.d/installer

Если используется SSH-ключ:

mkdir -p /home/installer/.ssh
chmod 700 /home/installer/.ssh
echo "<содержимое публичного ключа>" >> /home/installer/.ssh/authorized_keys 
chmod 600 /home/installer/.ssh/authorized_keys
chown -R installer:installer /home/installer/.ssh 

Если SSH-подключение осуществляется по паролю, на сервере Встреч выполните команду:

vim /etc/sudoers.d/admin

admin ALL=(root) NOPASSWD: /usr/bin/rsync *

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

Чтобы проверить подключение, выполните на сервере установки:

ssh installer@<IP-адрес целевого сервера>

ssh installer@<IP-адрес целевого сервера> "sudo -n whoami"

Ожидаемый результат второй команды:

root

Важно: не передавайте приватный SSH-ключ, пароль sudo и архив конфигурации вместе с обычным диагностическим письмом. Используйте утвержденный защищённый канал.

Настройте сетевое взаимодействие

Обязательные исходящие доступы

При работе через SSH-туннель порт 9443 не требуется открывать на межсетевом экране между рабочей станцией и сервером установки.

При использовании proxy обеспечьте доступ к proxy-серверу, настройте доверие к корпоративному УЦ при TLS inspection и укажите параметры proxy в разделе Опции. Для первичного скачивания бинарного файла proxy может потребоваться ещё до запуска Web UI.

Проверьте соединения

curl -I https://rep-box.webinar.ru 
curl -I https://on-premise-reg.webinar.ru   
curl -I https://license-chat.mts-link.ru 
curl -I https://premise-registry.mts-link.net 

Межпродуктовое взаимодействие в стандартной-поставке

Если продукты находятся на разных серверах и между серверными сегментами действует firewall, разрешите HTTPS-соединения между продуктовыми серверами по сервисным FQDN.

Пользовательские входящие порты

Полный набор межпродуктовых и интеграционных правил зависит от архитектуры. Для распределенной установки и ограниченного east-west трафика оформляется отдельная матрица доступа.

Порты для работы SIP-коннектора

Для работы SIP-коннектора (WRC) необходимо обеспечить связь между серверами. Для этого нужно открыть порты, указанные ниже:

Остальные порты нужно закрыть.

Дополнительные интеграционные порты

Открываются только при использовании соответствующей интеграции. Точные адреса источников и назначений согласуются в проектной матрице сетевого взаимодействия.

Настройте DNS-зону

Перед установкой должны быть определены все FQDN. Они должны соответствовать сертификатам и сетевой схеме публикации.

Правила формирования доменов

Колонка «Типовая виртуальная машина» приведена для стандартной поставки «Встречи + Чаты + Платформа». При NAT, внешнем балансировщике, внешнем S3 или иной архитектуре используйте согласованную проектную схему.

* если вы используете внешнее хранилище, можно не создавать доменное имя <boards>-s3.<zone>

Примеры доменов Встреч

Пример домена Платформы

Ключевое правило домена Платформы — домен Платформы формируется от префикса основного домена Встреч. Например, если основной домен Встреч — meetings.example.com, то домен Платформы должен быть meetings-mgw.example.com

Примеры доменов Чатов

Примеры доменов Доски

В Web UI вводятся основные домены продуктов. Производные имена должны быть заранее согласованы и присутствовать в DNS и сертификате. Они должны разрешаться в адреса, соответствующие выбранной схеме публикации и значениям IP в Web UI.

Проверьте доступность доменов:

dig +short meetings.example.com
dig +short meetings-wowza.example.com
dig +short meetings-webrtc.example.com
dig +short meetings-message.example.com
dig +short chats.example.com
dig +short chats-gateway.example.com
dig +short chats-storage.example.com
dig +short platform-gw.example.co 

Типовой резолв для поставки «Встречи + Чаты + Платформа»

В стандартной двухсерверной схеме медиа-домены Встреч направляются на виртуальные машины Встреч, а основной домен Встреч и остальные сервисные домены на машины Чатов + Платформы. Это ожидаемая схема размещения, а не ошибка DNS.

Пример для виртуальных машин Встреч 10.60.50.64 и виртуальной машины Чатов + Платформы 10.60.50.66

Пример записей DNS или временного /etc/hosts:

10.60.50.64 meet-wowza.example.com
10.60.50.64 meet-webrtc.example.com
10.60.50.66 meet.example.com
10.60.50.66 meet-message.example.com
10.60.50.66 meet-mgw.example.com
10.60.50.66 chats.example.com
10.60.50.66 chats-gateway.example.com
10.60.50.66 chats-storage.example.com

Важно: поле IP Встреч в Web UI содержит внутренний IP-адрес виртуальной машины Встреч, но основной домен Встреч в типовой двухсерверной схеме направляется на виртуальную машину Чатов + Платформы. На машины Встреч направляются только meet-wowza и meet-webrtc.

При публикации через NAT или балансировщик внешний DNS может указывать на опубликованный адрес. Внутренний резолв, используемый сервером установки и целевыми виртуальными машинами, должен соответствовать согласованной split-DNS-схеме и результатам проверки Web UI.

Выполните проверку DNS

Проверка с учетом DNS и /etc/hosts:

getent hosts meet.example.com
 getent hosts meet-mgw.example.com
 getent hosts meet-wowza.example.com
 getent hosts meet-webrtc.example.com
 getent hosts meet-message.example.com
 getent hosts chats.example.com
 getent hosts chats-gateway.example.com
 getent hosts chats-storage.example.com

Проверка непосредственно через DNS:

dig +noedns +short meet.example.com
dig +noedns +short meet-mgw.example.com 

Успешный резолв не гарантирует правильный маршрут. Сравните ожидаемый IP-адрес с фактически разрешенным адресом для каждой записи.

Если корпоративные DNS-записи еще не готовы, допускается временно использовать /etc/hosts на сервере установки и на каждой целевой виртуальной машине. Временные строки должны быть одинаковыми и не конфликтовать с постоянным DNS.

Если корпоративный DNS будет настроен после установки

Если корпоративный DNS будет настроен позже, на время установки имена должны корректно определяться с сервера установки и с целевых серверов. Если DNS-записи еще не заведены, добавьте временные записи в /etc/hosts .

Записи нужны:

• на сервере установки
• на каждом целевом сервере
• для всех FQDN, которые вводятся в веб-установщике
• для производных доменов Встреч, Чатов, Платформы, Досок.

Пример для поставки Встречи + Чаты + Платформа, где сервер Встреч имеет IP 10.60.50.64, а сервер Чаты + Платформа имеет IP 10.60.50.66:

10.60.50.64 meetings.example.com
10.60.50.64 meetings-wowza.example.com
10.60.50.64 meetings-webrtc.example.com
10.60.50.64 meetings-message.example.com

10.60.50.66 chats.example.com
10.60.50.66 chats-gateway.example.com
10.60.50.66 chats-storage.example.com
10.60.50.66 platform-gw.example.com

Проверьте IP-адреса.

getent hosts meetings.example.com
getent hosts meetings-webrtc.example.com
getent hosts chats.example.com
getent hosts platform-gw.example.com 

Важно

Записи в /etc/hosts не заменяют полноценный DNS для продуктивной эксплуатации.

Временные записи должны совпадать с теми IP-адресами, которые указаны в веб-установщике.

Если Встречи опубликованы за NAT, отдельно согласуйте внутренний IP-адрес для SSH и внешний IP-адрес для пользовательского доступа.

Веб-установщик показывает, если имя найдено через /etc/hosts , но сам факт наличия записи не означает, что она указывает на правильный IP-адрес.

Выпустите TLS-сертификаты

Подготовьте сертификат и приватный ключ до установки. Поддерживаются сертификаты .crt, .pem, .cer и ключи .key, .pem.

Можно использовать один wildcard-сертификат на все продукты или отдельные сертификаты для каждого продукта. Также можно использовать сертификат собственного УЦ или самоподписанный сертификат.

Требования:

• сертификат и приватный ключ являются парой
• срок действия сертификата не истёк
• до окончания срока действия осталось больше 14 дней
• SAN должен содержать все используемые FQDN либо сертификат должен быть wildcard нужного уровня
• Wildcard *.example.com покрывает ://example.com и ://example.com и другие одноуровневые имена, но не покрывает вложенные имена ://example.com 
• при необходимости должна использоваться полная цепочка сертификатов
• файлы должны быть доступны на сервере установки по абсолютному пути или доступны для загрузки через веб-интерфейс установщика
• при использовании корпоративного УЦ доверенная цепочка должна быть установлена на серверы и клиентские устройства.

Проверьте сертификаты и ключи.

openssl x509 -in /path/to/cert.pem -noout -subject -issuer -dates -ext subjectAltName openssl pkey -in /path/to/key.pem -check 

Проверка пары — хэши должны совпасть.

openssl x509 -noout -modulus -in /path/to/cert.pem | openssl sha256
openssl pkey -noout -modulus -in /path/to/key.pem | openssl sha2