Skip to main content
Самостоятельный хостинг — это развертывание Enterprise. Свяжитесь с Failproof AI, чтобы получить лицензию enterprise.

​
Предварительные требования

  • Kubernetes 1.27 или новее с доступом cluster-admin
  • kubectl с поддержкой Kustomize
  • Helm 3
  • Доступ к приватным образам ghcr.io/agenteye-enterprise
  • Два DNS-имени: одно для панели управления и одно для приема данных
  • Постоянное хранилище для PostgreSQL и ClickHouse
  • cert-manager и Traefik, или эквивалентная инфраструктура ingress и сертификатов, адаптированная в ваш overlay
  • SMTP для production OTP входа и уведомлений
Исходное дерево предоставляет overlay ориентированный на AWS/EKS и отдельный overlay для GCP/GKE. Не комбинируйте их инструкции для сертификатов, балансировщиков нагрузки или резервных копий: GKE использует собственную конфигурацию DNS-01, GCS и автомасштабирования.

​
Последовательность развертывания

1

Подготовьте кластер

Установите cert-manager и контроллеры ingress для публичного доступа/панели управления, проверьте их балансировщики нагрузки, затем создайте namespace, учетные данные для pull образов, учетные данные базы данных, ключ начальной загрузки администратора и секреты аутентификации/SMTP.
2

Настройте публичные домены

Установите INGEST_DOMAIN и DASHBOARD_DOMAIN в сгенерированном файле переменных окружения домена overlay и создайте DNS-записи, указывающие на соответствующие балансировщики нагрузки.
3

Примените и проверьте один platform overlay

Используйте customer/EKS или GCP overlay. Проверьте отрендеренный вывод Kustomize, примените его и подтвердите, что все рабочие нагрузки и сертификаты достигли требуемого состояния перед регистрацией машин.
4

Начальная загрузка доступа и приема данных

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

​
Обязательные и необязательные сервисы

​
Емкость аудита и доставка при сбое

Выполняйте аудиты в выделенном развертывании audit-agent при наличии. Каждый pod audit-agent по умолчанию принимает одно расследование; масштабируйте пропускную способность с помощью реплик, а не увеличивайте одновременность на одном pod без увеличения памяти. Сервер может одновременно отправлять server replicas × AUDIT_WORKERS аудитов, поэтому емкость диспетчера должна быть достаточной для заполнения парка audit-agent. Когда каждый слот audit-agent занят, аудит ждет и повторяет попытки до одной четверти его интервала, максимум шесть часов. Если слот не становится доступным, запуск завершается без результатов и отправляет письмо об ошибке. Повторяющиеся сбои “busy” требуют большего количества реплик audit-agent или более широко разделенных якорей расписания. Повторяющиеся сбои “shutting down” указывают на нестабильные pods или циклический rollout, а не на недостаточную емкость. Уведомления об ошибках требуют включенного канала email и SMTP. Они используют получателей аудита, затем переходят на alerts.email_default_recipients, если у аудита нет канала email.

​
Проверьте развертывание

  1. Откройте настроенный домен панели управления, пройдите поток admin OTP и подтвердите название и slug организации.
  2. Перейдите в Administration → Keys и создайте ключ машины с ограниченной областью действия.
  3. Отправьте тестовую сессию, затем подтвердите ее в Observe → Events и Observe → Sessions.
  4. Протестируйте канал уведомлений и, если настроено, ручную оценку и аудит.

​
Аутентификация и email

Панель управления использует email и одноразовые коды. При отсутствии SMTP развертывания разработки логируют OTP-коды в вывод сервера. Когда установлен SMTP_HOST, имя пользователя, пароль и отправитель требуются как группа, или сервер отказывается запускаться. SMTP_TLS — логическое значение. Поддерживаемый зашифрованный транспорт — STARTTLS, обычно на порту 587; неявный SMTPS на порту 465 не поддерживается текущим транспортом сервера. Установите URL панели управления правильно, так как OTP, уведомления об алертах, инциденты и письма аудита используют его для глубоких ссылок. Членство в организации контролирует, кто может запросить код; каждая организация может дополнительно ограничить вход своих членов в Administration → Settings.

​
Требования для мультитенантности

Перед созданием второй организации настройте надежный стабильный секрет производной ClickHouse организации и сохраняйте его идентичным на всех репликах сервера. Его ротация без скоординированной миграции может привести к потере пользователей ClickHouse для конкретной организации. Держите listener администратора экземпляра внутренним. Предоставленная консоль оператора — это opt-in и предназначена для kubectl port-forward, а не для публичного ingress. Её включение требует собственного надежного API ключа, super-admin почтового ящика и работающей доставки второго фактора SMTP.

​
Break-glass организации CLI

agenteye-orgctl входит в состав образа сервера и обращается непосредственно к PostgreSQL и ClickHouse. Остается доступным, когда публичный сервер или консоль оператора неисправны.
Поддерживаемые операции организации включают create, list, rename, soft-delete, restore, переподготовку пользователей ClickHouse, управление датой выставления счетов, флаги функций и необратимую очистку. Операции членов включают add, list, update, remove, переопределения разрешений и состояние protected-admin. Используйте soft-delete перед purge. org purge необратим и требует предварительного удаления организации. Защищенные члены не могут быть удалены или понижены через обычную страницу Users организации, пока оператор явно не снимет защиту с них.

​
Контрольный список готовности к production

  • Приём и DNS панели управления разрешаются в различные предполагаемые пути ingress.
  • TLS действителен; используйте взаимный TLS на приёме, где этого требует ваше развертывание.
  • Тома PostgreSQL и ClickHouse имеют алерты о емкости.
  • Резервные копии включают оба хранилища данных и имеют проверенную процедуру восстановления.
  • Проверки здоровья предупреждают о молчании приема, неудачных рабочих нагрузках, истечении сертификатов, нехватке памяти и устаревших резервных копиях.
  • Структурированные логи собираются без дублирования существующего конвейера логов кластера.
  • Одновременность Evaluator, audit и alert worker не была изменена без измеренных доказательств очереди.
  • Закрепленный релиз приложения и процедура отката записаны перед обновлениями.
Манифесты развертывания содержат специфичные для платформы предположения о безопасности и доступности. Проверьте отрендеренные ресурсы, сетевые политики, экспозицию ingress, ссылки на секреты, классы хранилища, бюджеты нарушений и назначения резервных копий с вашей командой платформы перед применением.