Установка на своих серверах

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

Чем это отличается от облака

	Облако	На своих серверах
Где лежат данные	инфраструктура ActionPulse	ваши тома, ваш диск, ваша сеть
Права на возможности	тариф и подписка	подписанная лицензия
Оплата в продукте	оформляется в кабинете	биллинг не монтируется вовсе
Срок хранения событий	от 6 месяцев до 25 месяцев в зависимости от тарифа	25 месяцев, потолок TTL в ClickHouse
Обновление	делает ActionPulse	делаете вы, поэтапно и с проверкой
Обращения наружу	не применимо	выключены; телеметрия — только по явному согласию

Первый владелец организации в on-prem создаётся не регистрацией, а парой переменных BOOTSTRAP_EMAIL/BOOTSTRAP_PASSWORD при первом старте HTTP-сервиса. После того как владелец появился, обе переменные нужно очистить.

Из каких сервисов состоит установка

Установка — не один контейнер, а набор сервисов с разными правами доступа к данным. Разделение намеренное: например, ключи от миграций получает только одноразовый контейнер миграций, а обслуживающий API их не видит.

Край и приложение

Сервис	Зачем нужен
caddy	единственная точка входа: 80/443, автоматический TLS, редактирование логов от credential’ов, заголовки безопасности
ingest-api	приём событий по /v1/* и раздача версионных ассетов трекера
query-api	/api/v1: кабинет, отчёты, ключи проектов, приватность, лицензия
ch-writer	переносит события из JetStream в ClickHouse
worker	фоновые задачи: удаление данных субъекта, очистка по сроку хранения, письма, алерты, импорты

Одноразовые задачи, без которых не стартует остальное

Сервис	Зачем нужен
query-api-migrate	применяет миграции PostgreSQL и ClickHouse; query-api ждёт его успешного завершения
query-api-nats-bootstrap	создаёт потоки JetStream EVENTS, REPLAY, IMPORT_FENCES; ingest-api без них не запускается

Оба контейнера идемпотентны и защищены advisory-локами, поэтому повторный запуск безопасен. В on-prem ingest-api намеренно не создаёт потоки сам: при старте он только читает их описание и падает, если инициализация не выполнялась.

Хранилища

Сервис	Что хранит
postgres	пользователи, организации и проекты, отчёты, метаданные лицензии, импорты, задания приватности и журнал аудита
clickhouse	события и аналитические таблицы
redis	квоты, дедупликация, кэш ответов
nats (JetStream)	транспорт событий между приёмом и записью, хранение до 48 часов

Наблюдаемость

Стек метрик, логов и трейсов стартует вместе с приложением, без отдельного профиля: prometheus, alertmanager, grafana, node-exporter и экспортёры PostgreSQL, Redis и NATS, elasticsearch с kibana и filebeat для логов, jaeger для трейсов. Ни один из этих сервисов не публикует порт на хост — доступ только через контролируемый port-forward или VPN. Что с этим делать дальше — в Мониторинге.

Резервные копии

Раннер бэкапов включается отдельным профилем backup и требует хранилища, совместимого с S3. Снимок — это дамп PostgreSQL, полный бэкап ClickHouse и подписанный манифест, который публикуется последним; пригодным считается только снимок с манифестом в состоянии complete. Транспортный поток JetStream в снимок не входит.

Два способа развёртывания

Docker Compose — один хост

Основной путь. Комплект содержит один файл compose, который поднимает всё перечисленное выше, включая базы данных и наблюдаемость. Подходит, когда установка живёт на выделенной машине и вы хотите получить работающий контур с минимумом внешних зависимостей.

Helm — Kubernetes

Чарт разворачивает только сервисы приложения. Это осознанное решение, и оно меняет объём вашей работы:

• PostgreSQL, ClickHouse, Redis и NATS вы приносите свои — как внешние сервисы или как subchart’ы;
• чарт не создаёт ни одного пароля: все значения приходят из вашего Secret’а, а роли с наименьшими правами в PostgreSQL и ClickHouse нужно создать до запуска Helm;
• Service, Ingress/Gateway и терминацию TLS для query-api и ingest-api чарт не создаёт — их пишете вы, и вы же указываете чарту CIDR’ы своего ingress-контроллера, иначе заголовки с адресом клиента будут игнорироваться;
• миграции выполняются pre-install/pre-upgrade хуком, поэтому запуск с --no-hooks и схема «helm template плюс kubectl apply» поддерживаемым путём не являются: они не гарантируют, что миграции пройдут до обновления сервисов.

Выбирайте Kubernetes, если у вас уже есть управляемые базы, GitOps и практика эксплуатации кластера. В остальных случаях Compose даёт предсказуемый результат быстрее.

Что получает оператор в комплекте

Комплект приходит одним архивом actionpulse-onprem-<версия>.tgz из аутентифицированного канала поставки, вместе с контрольной суммой и подписанным release-манифестом. И то и другое нужно проверить до распаковки.

Внутри, в корне архива:

• docker-compose.onprem.yml — единственный compose, запускается из корня;
• .env.example — шаблон конфигурации; версии образов уже зафиксированы как tag@sha256;
• preflight.sh — проверка .env и файлов секретов до первого запуска;
• Caddyfile — конфигурация обратного прокси;
• OPERATIONS.md — руководство по эксплуатации;
• redis-users.acl.example, nats-server.conf.example — шаблоны ACL Redis и конфигурации NATS, заведомо нерабочие: все пароли в них заменены заглушками;
• clickhouse/ — конфигурация сервера и пользователей, а также файлы для шардированной топологии;
• postgres/roles.sql — роли PostgreSQL для каждого сервиса;
• backup/ — named collection для ClickHouse, шаблон окружения и описание раннера;
• observability/ и monitoring/prometheus/ — живые конфигурации Prometheus, Alertmanager, Grafana, Filebeat и файл правил алертов;
• jaeger/ — конфигурация трейсинга;
• helm/actionpulse/ — чарт для Kubernetes;
• docs/ — контракты приёма событий, документ по безопасности и приватности, спецификация OpenAPI;
• release/ — перечень образов с точными digest’ами, SBOM, provenance, отчёты сканера и ассеты браузерного SDK;
• VERSION — манифест версии и коммита, из которого собран комплект.

Отчёты сканера в release/trivy/ — это набор кандидатов, а не список подтверждённых уязвимостей: каждая запись требует отдельной оценки достижимости в вашей конфигурации.

Комплект намеренно не содержит того, что оператор запустить не может: скриптов раннера бэкапов (они внутри образа, зафиксированного по digest), Dockerfile’ов, тестовых и smoke-харнессов, генераторов конфигураций и валидатора правил Prometheus. Все команды вида make …, а также сборщик самого комплекта, работают только из клона репозитория продукта и в поставку не входят — ни одна инструкция для оператора на них не опирается.

Порядок работ: от нуля до принятого события

1. Сверьте окружение с требованиями и подготовьте домен, сертификаты для Elasticsearch и Kibana, файл лицензии — Требования.
2. Проверьте контрольную сумму и подписанный release-манифест архива, затем распакуйте комплект.
3. Скопируйте .env.example в .env с правами 0600, сгенерируйте каждый секрет отдельным значением, заполните домен и публичные адреса — Развёртывание в Docker Compose.
4. Подготовьте файлы вне .env: ACL Redis, конфигурацию NATS, сертификаты и ключи Elasticsearch и Kibana. Приватные ключи — режим 0600.
5. Запустите ./preflight.sh .env из корня комплекта и добейтесь успешного вывода. Проверка закрытая: пока она падает, запускать compose бессмысленно.
6. Поднимите хранилища, дождитесь завершения инициализации JetStream и миграций, затем поднимите остальное — Развёртывание в Docker Compose.
7. Войдите как владелец из BOOTSTRAP_*, установите лицензию и убедитесь, что статус возвращает valid — Лицензия. Затем очистите BOOTSTRAP_EMAIL и BOOTSTRAP_PASSWORD и перезапустите query-api.
8. Создайте проект и ключ для отправки событий — Создание проекта и Ключи и токены.
9. Отправьте первое событие — Первое событие для браузера или Отправка событий с бэкенда для серверного ключа.
10. Убедитесь, что событие дошло до отчётов — Проверка приёма.
11. Настройте наблюдаемость и резервное копирование, проведите первое восстановление в изолированную цель — Мониторинг.

Шаги 8–10 доступны и через HTTP API, и через интерфейс кабинета; см. оговорку о статике кабинета ниже.

Чего в on-prem нет по устройству

Это не пробелы в настройке — этих маршрутов и механизмов в режиме on-prem физически нет.

• Биллинга. Обработчики /api/v1/billing/… не монтируются: любой запрос к ним вернёт 404. Подписок, счетов, чеков и квоты по подписке в on-prem не существует.
• Пробных периодов. Нет ни триала, ни перехода кабинета в режим «только чтение» после его окончания. Отказы приходят по пути лицензии, а не по пути подписки.
• Административных маршрутов поставщика. Служебная часть, через которую в облаке выпускаются лицензии, в on-prem не монтируется. Лицензию выпускает поставщик и передаёт вам готовый ключ.
• Ограничения приёма по числу событий. Поле с месячным объёмом в лицензии — это метаданные договора: во время работы оно ничего не блокирует. Не планируйте на него техническую защиту от перерасхода; следите за объёмом по метрикам.
• Отдельных маршрутов готовности. Есть только /healthz — на query-api он проверяет доступность PostgreSQL, на ingest-api — соединение с NATS. Маршрутов /readyz и /livez не существует, и в Helm-чарте задана только проба готовности.
• Раздачи статики кабинета из комплекта. В поставляемом compose нет сервиса, который отдаёт файлы веб-интерфейса, а перехватывающее правило в Caddyfile помечено в самом файле как заглушка на query-api. Как получить и смонтировать статику кабинета для вашей версии — уточните у поставщика; вся проверка установки, включая шаги 8–10 выше, выполнима через HTTP API.
• SQL-консоли без отдельного подключения. Её маршруты монтируются только когда задано read-only подключение к ClickHouse под ролью console_ro. Если его нет, консоль просто отсутствует, а в журнале старта остаётся предупреждение.

Обратное тоже верно: маршруты управления лицензией /api/v1/license существуют только в on-prem, а в облаке возвращают 404.

Что проверить, прежде чем считать установку рабочей

• ./preflight.sh .env завершается успехом, а docker compose … config --quiet не печатает ничего.
• Все контейнеры в состоянии running или, для одноразовых задач, exited (0).
• /healthz отвечает 200 через ваш домен, а не только изнутри сети.
• На хосте опубликованы только 80 и 443.
• Статус лицензии — valid, и запись в API не отклоняется.
• Тестовое событие прошло путь приём → JetStream → ClickHouse и видно в отчёте.
• Свежий бэкап создан и восстановлен в изолированную цель с совпадением контрольных сумм. Резервная копия, которую ни разу не восстанавливали, ещё не является резервной копией.