> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Самостоятельный хостинг Failproof AI Cloud

> Разверните плоскость управления Failproof AI в кластере Kubernetes, управляемом клиентом.

<Note>
  Самостоятельный хостинг — это развертывание Enterprise. [Свяжитесь с Failproof AI](mailto:support@befailproof.ai), чтобы получить лицензию enterprise.
</Note>

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

* 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 и автомасштабирования.

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

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

  <Step title="Настройте публичные домены">
    Установите `INGEST_DOMAIN` и `DASHBOARD_DOMAIN` в сгенерированном файле переменных окружения домена overlay и создайте DNS-записи, указывающие на соответствующие балансировщики нагрузки.
  </Step>

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

  <Step title="Начальная загрузка доступа и приема данных">
    Войдите как защищенный администратор, создайте ключ машины с областью действия организации и отправьте небольшую тестовую сессию через публичную конечную точку приема.
  </Step>
</Steps>

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

| Компонент             | Требование                                                                                                                    |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| ClickHouse            | Обязателен. Сервер отказывается запускаться без его канонического хранилища событий.                                          |
| PostgreSQL            | Обязателен для пользователей, организаций, сохраненных объектов и состояния плоскости управления.                             |
| Redis                 | Необязателен. Сервер и панель управления деградируют до поведения, поддерживаемого базой данных, при недоступности.           |
| SMTP                  | Необязателен для разработки, обязателен для production email OTP и доставки уведомлений.                                      |
| Evaluator             | Необязателен. Автоматическая оценка остается отключенной без `EVALUATOR_ENDPOINT`.                                            |
| Assistant/audit LLM   | Необязателен. Функции Assistant и поддерживаемого LLM аудита остаются неактивными, пока не будет настроено подключение к LLM. |
| Object storage backup | Настоятельно рекомендуется для архивов резервных копий PostgreSQL и ClickHouse.                                               |

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

Выполняйте аудиты в выделенном развертывании 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.

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

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

  <Tab title="CLI">
    ```bash theme={null}
    kubectl get pods -n agenteye
    kubectl get certificates -n agenteye
    kubectl logs -n agenteye deploy/server --tail=100

    fp --base-url https://failproof.example.com login
    fp --base-url https://failproof.example.com whoami
    fp --base-url https://failproof.example.com usage
    ```

    Проверьте публичную конечную точку health и один аутентифицированный запрос `/v1` перед регистрацией production машин.
  </Tab>
</Tabs>

## Аутентификация и 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. Остается доступным, когда публичный сервер или консоль оператора неисправны.

```bash theme={null}
kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org create --slug acme --name "Acme Corp"
kubectl -n agenteye exec deploy/server -- agenteye-orgctl org list
kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email ops@acme.com --set admin --protected
```

Поддерживаемые операции организации включают 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 не была изменена без измеренных доказательств очереди.
* Закрепленный релиз приложения и процедура отката записаны перед обновлениями.

<Warning>
  Манифесты развертывания содержат специфичные для платформы предположения о безопасности и доступности. Проверьте отрендеренные ресурсы, сетевые политики, экспозицию ingress, ссылки на секреты, классы хранилища, бюджеты нарушений и назначения резервных копий с вашей командой платформы перед применением.
</Warning>