Skip to content

Развертывание и инфраструктура

Принятое решение

Базовая production-модель VideoGrace - Terraform + Ansible + systemd, а не Kubernetes. Это сознательный выбор для текущего media core: он дает предсказуемую сеть, простой lifecycle долгих конференций и понятную эксплуатацию stateful-узлов.

Kubernetes не запрещен. Он остается подходящим вариантом для отдельных stateless-сервисов, но не является целевой платформой для VideoGraceServer и RTP/WebRTC media plane в текущей архитектуре.

flowchart TB
    TF[Terraform]
    Cloud[Облачная инфраструктура\nVM, сеть, диски, IP, DNS]
    Ansible[Ansible]
    Host[Узел VideoGrace]
    Systemd[systemd]
    Server[VideoGraceServer\ncontrol + WebRTC + Translator]
    Workers[CAN workers\nRecorder / Transcriber]
    Data[(Локальные SQLite DB\nи storage)]
    Nginx[Nginx / TLS / web-client]

    TF --> Cloud
    Cloud --> Ansible
    Ansible --> Host
    Host --> Systemd
    Systemd --> Server
    Systemd --> Workers
    Server --> Data
    Server --> Nginx

Границы ответственности

Инструмент Ответственность
Terraform Создает и изменяет облачную инфраструктуру: VM, сети, security groups, постоянные диски, публичные IP, DNS и связанные облачные ресурсы.
Ansible Приводит хост к нужному состоянию: системные зависимости, бинарные файлы, конфигурация, Nginx, TLS, firewall, systemd units, обновления и health-check.
systemd Запускает и перезапускает VideoGraceServer и worker-процессы, хранит их логи в journald и задает lifecycle после reboot.
VideoGraceServer Владеет control plane, конференциями, WebRTC gateway, Translator и server-side SQLite базами.

Секреты не попадают в Git, Terraform state или логи. Ansible получает их из защищенного CI/CD secret store либо Ansible Vault и передает только в runtime-конфигурацию с ограниченными правами на файл.

Почему media core не запускается в Kubernetes

Для текущего VideoGraceServer Kubernetes создает больше обязательной инфраструктуры, чем решает задач:

  • Media plane требует стабильного публичного IP, UDP port range и прозрачного прохождения ICE/DTLS/SRTP.
  • Конференции и media sessions долгоживущие; перезапуск или reschedule pod'а означает разрыв активных звонков.
  • Узел использует локальные SQLite базы (main.db, history.db, security.db, storage.db, records.db, api.db, integration.db) и локальный storage lifecycle.
  • Корректная Kubernetes-схема потребовала бы host networking или сложной UDP публикации, закрепления workload за node, persistent volumes, controlled draining и отдельного дизайна HA/backup/restore.
  • При текущем числе серверов Terraform + Ansible дают тот же уровень воспроизводимости с меньшим числом движущихся частей и более простой диагностикой media-проблем.

Это не означает, что Kubernetes технически несовместим с VideoGrace. Его следует рассматривать только вместе с изменением архитектуры stateful-слоя и отдельным планом HA, а не как замену процесса деплоя.

Топология production-узла

Один media-узел содержит следующие роли:

Роль Содержание
Edge Nginx завершает TLS, отдает web-client и проксирует HTTP/WebSocket к серверу.
Core VideoGraceServer обслуживает control API, комнаты, устройства, WebRTC gateway и Translator.
Data SQLite базы и blob storage лежат на persistent disk узла и резервируются отдельно от бинарных файлов.
Workers Recorder, Transcriber и другие CAN workers могут работать на отдельном VM или рядом с core, но жизненный цикл каждого процесса независим.

Для нескольких узлов масштабирование начинается с явного разделения ролей и доменов, а не с автоматического размещения pod'ов. Media-узел должен иметь фиксированные сетевые параметры, мониторинг ресурсов и проверенный путь восстановления из backup.

Обновление

Стандартный управляемый релиз выглядит так:

  1. terraform plan и terraform apply изменяют только инфраструктуру, когда это требуется.
  2. Ansible раскладывает релиз, зависимости и конфигурацию, не перезаписывая данные и secrets.
  3. Выполняются health-check: HTTP server_info, WebSocket/HTTPS доступность, при необходимости регистрация CAN worker.
  4. Затем systemd перезапускает затронутые сервисы контролируемо; для media core это означает плановое завершение активных конференций на конкретном узле.
  5. После релиза проверяются журнал сервиса, место на диске, доступность базы и backup policy.

Нельзя подменять контролируемый релиз простым копированием бинарника в работающий процесс. Бинарник, конфигурация, systemd unit и версия базы должны обновляться наблюдаемым сценарием с возможностью отката.

Где Kubernetes уместен

Kubernetes допустим и потенциально полезен для компонентов, не владеющих активными медиа-сессиями и локальным состоянием:

  • статический сайт документации и web UI;
  • QA Hub и аналогичные внутренние HTTP-сервисы;
  • stateless integration/webhook workers;
  • фоновые задачи, которые переживают повторное выполнение и используют внешнее persistent storage.

Перед переносом любого компонента в Kubernetes нужно явно описать его состояние, сетевые требования, restart semantics, health/readiness probes, storage и стратегию rollback. Media core переносится только отдельным архитектурным проектом, после отказа от локальной stateful-модели или ее полноценного внешнего HA-контура.