Развёртывание и контуры

Агент, собранный в конструкторе, разворачивается в изолированный контур: сеть, кластер, база данных, секреты, политики безопасности и аудит. Этот раздел описывает, что именно получает клиент, какие контуры бывают и где заканчивается автоматизация.

1. Три типа контуров

Контур	Изоляция	Кому подходит	Срок
Общий контур MindRoot.ru	Namespace в общем кластере, свои ключи шифрования, NetworkPolicy на клиента	Пилоты, средний бизнес без требований к выделенному железу	1 день
Выделенный контур (VPC на клиента)	Отдельные VPC, кластер Kubernetes, managed PostgreSQL и бакет	Компании с ПДн клиентов, требованиями ИБ и аудита	3 дня
Контур заказчика (on-premise)	Полная изоляция сети, локальный инференс, данные не покидают периметр	Банки, медицина, госсектор, промышленность	10 дней

Облако выбирается из Yandex Cloud, VK Cloud и Selectel — все с размещением данных в РФ. Для on-premise генерируется пакет без Kubernetes: docker-compose, runbook монтажа и чеклист согласований с ИБ заказчика.

2. Как считаются ресурсы

Расчёт идёт от нагрузки: количества задач агента в месяц. Система берёт средний RPS, добавляет шестикратный запас на пики и определяет:

Реплики ядра — из пиковой нагрузки (≈1,5 RPS на реплику), минимум две при включённой отказоустойчивости;
Узлы приложений — из числа реплик, с выбором конфигурации 4 vCPU / 8 ГБ или 8 vCPU / 16 ГБ;
PostgreSQL — 2, 4 или 8 vCPU, HA-кластер при отказоустойчивости, диск — с учётом срока хранения логов;
Объектное хранилище — под файлы, вложения и резервные копии;
GPU-узел — если выбрана локальная модель (T4 при небольшой нагрузке, A100 при большой).

Смета раскладывается по статьям, отдельно показываются разовые затраты (для on-premise — серверы, СХД, работы по внедрению).

3. Состав пакета развёртывания

Группа	Файлы	Назначение
План	`README.md`, `deploy-plan.json`	Ресурсы, смета, порядок работ, предупреждения плана
Kubernetes	`k8s/00…90`	Namespace с метками соответствия, шаблон секретов, configmap с политиками (маскирование ПДн, аудит, лимиты, срок хранения), deployment с `runAsNonRoot` и `readOnlyRootFilesystem`, ingress, HPA, NetworkPolicy с запретом по умолчанию, PVC, CronJob бэкапа
Terraform	`terraform/<провайдер>/`	Сеть, кластер, группа узлов, managed PostgreSQL, бакет; пример `terraform.tfvars`
On-premise	`compose/`, `runbooks/`	Запуск без кластера, пошаговая инструкция монтажа, требования к площадке
Соответствие	`152fz-checklist.md`, `checks/verify-contour.sh`	Чеклист для приёмки и скрипт проверки контура после развёртывания
Агент	`agent.json`, `.env.example`	Собранный агент и переменные окружения с подсказками по каждому плагину

4. Шаги развёртывания

Облачный прогон состоит из 13 шагов, локальный — из 7 (проверка конфигурации, плагины, секреты, агент, ядро, дымовой тест, ручные действия), у каждого шага есть журнал и время выполнения: проверка конфигурации → проект, сервисный аккаунт и квоты → сеть (VPC, подсети, группы безопасности, NAT) → хранилище секретов и ключи шифрования → кластер → узлы → PostgreSQL и S3 → ядро MindRoot (Helm) → установка плагинов агента → импорт агента и включение команд → политики безопасности и аудит → дымовой тест → домен, сертификат и передача доступов.

Шаги, которые невозможно выполнить без человека, помечаются явно: заполнение токенов интеграций, выдача минимальных прав сервисным пользователям в 1С/CRM, настройка выгрузки журнала аудита в SIEM, DNS-запись, сертификат, передача доступов ответственным сотрудникам заказчика.

5. Контур в действии

Кнопка «Запустить контур» не просто собирает файлы: контур поднимается на этом же хосте, и его панель доступна по адресу /c/<id>/. Внутри панели — чат с агентом, очередь подтверждений, политики, показатели и журнал аудита.

Что происходит	Как это выглядит
Плагины исполняются	Вызывается настоящий код команд: тот же `mod.py`, что установлен из маркетплейса. Задача «покажи сделки за неделю» идёт в коннектор Битрикс24.
Внешние API — демонстрационные	Ответы 10 вендоров детерминированы, в ответе команды стоит источник `demo`. Боевой вызов включается сам, когда в настройках появляется реальный токен: хост уходит в сеть, код не меняется.
Политики работают	Изменяющая команда ставится в очередь подтверждений; работа вне разрешённых часов, превышение лимита записей и внешние вызовы при on-premise отклоняются с записью в аудит.
Аудит и отчёт	`state/audit.jsonl`: задачи, команды, аргументы, подтверждения, отказы, обновление секретов. Отчёт — счётчики, ошибки, разбивка по плагинам.
Живучесть	После перезапуска сервера контур восстанавливается из `deployments/<id>/`; удаление контура снимает рантайм и состояние.

API контура: POST /c/{id}/api/task — задача, POST /c/{id}/api/command — прямой вызов команды, POST /c/{id}/api/approve|reject — решение человека, GET /c/{id}/api/report|audit|commands|secrets — показатели, журнал, команды и состав настроек, POST /c/{id}/api/smoke|stop — дымовой тест и остановка. Список работающих контуров — GET /api/contours.

6. Что важно знать про режимы работы

Облачный прогон — dry-run. Пакет для облака создаётся полностью и показывает план применения, но не вызывает API облачного провайдера: для этого нужны доступы заказчика. Боевое развёртывание — это terraform init && terraform apply и kubectl apply -f k8s/ в аккаунте клиента, либо работы нашей команды внедрения. Смета — оценка по тарифам: перед договором цены подтверждаются у провайдера.

Локальный прогон — рабочий контур. Плагины исполняются, политики и аудит действуют, панель доступна сразу. Внешние API отвечает демонстрационный транспорт: боевые данные подключит заказчик своими токенами (вкладка «Секреты» в панели контура).

Terraform-файлы — рабочая стартовая точка. API облаков меняются: перед apply сверьте имена и аргументы ресурсов с документацией провайдера и прогоните terraform validate.
Секреты в пакете — только шаблон. В продакшене они создаются из Vault или KMS заказчика; реальные значения в git не попадают.
Сценарий с ошибками политики (неизвестные команды, запись без подтверждения, отключённое маскирование ПДн) не разворачивается: API возвращает HTTP 422 с текстом ошибки.