Состав платформы

Раздел «Установка и администрирование» написан для службы ИТ, которая ставит и обслуживает DeepDive в своём контуре — on-premise или в частном облаке (см. «Варианты развёртывания»). Работа пользователей и администраторов организаций описана в разделах «Руководство пользователя» и «Руководство администратора».

Сервисы платформы

Платформа — шесть сервисов. Пять серверных собраны в один образ и различаются точкой входа, поэтому всегда обновляются одной версией; шестой — веб-интерфейс.

Сервис	Назначение	Порт
config	Централизованная конфигурация: раздаёт остальным сервисам их настройки	3001
service-discovery	Реестр сервисов и их адресов	3002
identity	Кто вошёл и что ему можно: пользователи, организации, роли, интеграция с Keycloak	3005
instance	Установка и её организации: идентификатор, оформление	3007
api	Основной сервис: GraphQL-API, ассистент, диалоги, база знаний, подключения к источникам данных	3000
ui	Веб-интерфейс, общается с api только по GraphQL	—

Перед платформой стоит oauth2-proxy — единственная точка входа снаружи. Он завершает TLS, проверяет сессию в Keycloak и передаёт платформе, кто пришёл. Интерфейс и API живут на одном домене за ним.

Порядок запуска

Сервисы стартуют по цепочке, и каждый ждёт готовности предыдущего по его /healthz:

config (3001)                  стартует первым, зависимостей нет
  └─ service-discovery (3002)
       ├─ identity (3005)
       └─ instance (3007)
            └─ api (3000)
                 └─ ui

Практическое следствие: если config не поднялся, не поднимется ни один сервис, — разбор всегда начинается с него.

У api, кроме /healthz, есть /livez: он выполняет SELECT 1 через собственный пул соединений и отвечает 503, если база не возвращает ответ. По нему Kubernetes перезапускает под, который потерял соединения с PostgreSQL (например, после пересоздания пода базы), — /healthz базу не проверяет.

Зависимости

Система	Для чего	Обязательна	Откуда берётся
PostgreSQL 16 с расширением vector (pgvector)	База платформы: настройки, организации, диалоги, состояние ассистента, база знаний; база сервиса identity; база Keycloak, если он из комплекта	Да	Из комплекта, на отдельной машине или ваш
Redis	Кэш платформы и сессии входа	Да	Из комплекта, на отдельной машине или ваш
NATS JetStream	Шина событий, поток ответа ассистента в интерфейс	Да	Из комплекта или ваш
S3-совместимое хранилище	Вложения диалогов и выгрузки	Да	Из комплекта, на отдельной машине или ваше
Keycloak	Вход в платформу (OIDC)	Да	Из комплекта или ваш
Языковая модель	Ответы ассистента; нужен вызов инструментов (tool calling) и потоковый ответ	Да	Ваш endpoint в контуре или внешний провайдер по API
Модель векторизации (embeddings)	Поиск по базе знаний	Да	Ваш endpoint в контуре или внешний провайдер по API
ClickHouse	Витрина бизнес-данных, таблицы из загруженных файлов	Нет	Из комплекта или ваш
Oracle, PostgreSQL	Источники бизнес-данных, если ассистент читает их напрямую	Нет	Ваши
Langfuse	Трассировка работы ассистента	Нет	Только ваш: из комплекта не ставится

Что из этого поднимает комплект, а что подключается ваше, решается при установке, — см. «Выбор компонентов».

База знаний живёт в базе платформы. Отдельного сервера под неё нет: таблицу и индексы платформа заводит сама при старте, в той же PostgreSQL. Поэтому к серверу PostgreSQL одно требование сверху — расширение vector. Граф знаний на Neo4j, который был в платформе до версии 1.0, удалён: ни сервера, ни тома, ни пароля под него больше не нужно.

Источники бизнес-данных

Ассистент отвечает по данным, к которым платформа подключена как к источникам: ClickHouse, Oracle и PostgreSQL. Подключение — запись в базе платформы; витрину ClickHouse, названную при установке, заводит источником сама установка, остальные подключаются в интерфейсе. Платформа данные в источник не загружает и не пишет — наполнение витрины остаётся за вашей службой эксплуатации. Подробнее — в «Руководстве администратора».