> ## 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 のセルフホスト

> 顧客管理の Kubernetes クラスターに Failproof AI コントロールプレーンをデプロイします。

<Note>
  セルフホストはエンタープライズ向けデプロイメントです。エンタープライズライセンスを取得するには [Failproof AI までお問い合わせください](mailto:support@befailproof.ai)。
</Note>

## 前提条件

* cluster-admin アクセス権を持つ Kubernetes 1.27 以降
* Kustomize サポート付きの `kubectl`
* Helm 3
* プライベートイメージ `ghcr.io/agenteye-enterprise` へのアクセス権
* 2 つの DNS 名：ダッシュボード用とインジェスト用それぞれ 1 つ
* PostgreSQL および ClickHouse 用の永続ストレージ
* cert-manager と Traefik、またはオーバーレイに適合させた同等のイングレスおよび証明書インフラ
* 本番環境の OTP ログインおよび通知用の SMTP

ソースツリーには AWS/EKS 向けオーバーレイと GCP/GKE 向けの独立したオーバーレイが含まれています。証明書、ロードバランサー、バックアップの手順をこれら 2 つで混在させないでください。GKE は独自の DNS-01、GCS、およびオートスケーリング設定を使用します。

## デプロイメントの手順

<Steps>
  <Step title="クラスターの準備">
    cert-manager とパブリック/ダッシュボードのイングレスコントローラーをインストールし、それらのロードバランサーを確認した上で、名前空間、イメージプル認証情報、データベース認証情報、ブートストラップ管理者キー、および認証/SMTP シークレットを作成します。
  </Step>

  <Step title="パブリックドメインの設定">
    オーバーレイで生成されるドメイン環境ファイルに `INGEST_DOMAIN` と `DASHBOARD_DOMAIN` を設定し、対応するロードバランサーを指す DNS レコードを作成します。
  </Step>

  <Step title="プラットフォームオーバーレイの適用と確認">
    customer/EKS または GCP オーバーレイを使用します。レンダリングされた Kustomize の出力を確認してから適用し、マシンを登録する前にすべてのワークロードと証明書が意図した状態に達していることを確認します。
  </Step>

  <Step title="アクセスとインジェストのブートストラップ">
    保護された管理者としてサインインし、組織スコープのマシンキーを作成して、パブリックのインジェストエンドポイントに小さなテストセッションを送信します。
  </Step>
</Steps>

## 必須サービスとオプションサービス

| コンポーネント             | 要件                                                 |
| ------------------- | -------------------------------------------------- |
| ClickHouse          | 必須。標準のイベントストアがなければサーバーは起動しません。                     |
| PostgreSQL          | ユーザー、組織、保存オブジェクト、およびコントロールプレーンの状態管理に必須。            |
| Redis               | オプション。利用不可の場合、サーバーとダッシュボードはデータベースベースの動作に低下します。     |
| SMTP                | 開発環境ではオプション、本番環境のメール OTP および通知配信には必須。              |
| Evaluator           | オプション。`EVALUATOR_ENDPOINT` がなければ自動評価は無効のままです。      |
| Assistant/audit LLM | オプション。LLM 接続が設定されるまで、アシスタントおよび LLM 連携の監査機能は動作しません。 |
| オブジェクトストレージバックアップ   | PostgreSQL および ClickHouse のバックアップアーカイブに強く推奨。       |

### 監査容量と障害時の配信

利用可能な場合は専用の audit-agent デプロイメントで監査を実行してください。各 audit-agent ポッドはデフォルトで 1 件の調査を受け付けます。スループットを上げる場合は、メモリを同時に増やさずにポッドあたりの並列数を引き上げるのではなく、レプリカ数でスケールしてください。サーバーは `サーバーレプリカ数 × AUDIT_WORKERS` 件の監査を並行してディスパッチできるため、ディスパッチャーの容量は audit-agent フリートを十分に埋められる大きさにする必要があります。

すべての audit-agent スロットがビジー状態の場合、監査はカデンスの 4 分の 1（最大 6 時間）まで待機してリトライします。スロットが空かない場合、実行は結果なしで完了し、失敗メールが送信されます。「busy」の失敗が繰り返される場合は audit-agent レプリカを増やすか、スケジュールのアンカー間隔を広げてください。「shutting down」の失敗が繰り返される場合は、容量不足ではなく不安定なポッドやループするロールアウトが原因です。

失敗通知には有効なメールチャネルと SMTP が必要です。監査の受信者リストを使用し、監査にメールチャネルがない場合は `alerts.email_default_recipients` にフォールバックします。

## デプロイメントの検証

<Tabs>
  <Tab title="ダッシュボード">
    1. 設定したダッシュボードドメインを開き、管理者の OTP フローを完了して、組織名とスラッグを確認します。
    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
    ```

    本番マシンを登録する前に、パブリックのヘルスエンドポイントと認証済みの `/v1` リクエストが 1 つ成功することを確認してください。
  </Tab>
</Tabs>

## 認証とメール

ダッシュボードはメールとワンタイムコードを使用します。SMTP がない場合、開発環境のデプロイメントでは OTP コードがサーバーの出力にログ出力されます。`SMTP_HOST` が設定されている場合、ユーザー名、パスワード、および送信者はセットで必須となり、いずれかが欠けるとサーバーは起動を拒否します。

`SMTP_TLS` はブール値です。サポートされている暗号化トランスポートは STARTTLS（通常はポート 587）です。ポート 465 の暗号化 SMTPS は現在のサーバートランスポートではサポートされていません。

OTP、アラート、インシデント、および監査のメールにはディープリンクが含まれるため、パブリックのダッシュボード URL を正確に設定してください。コードのリクエストは組織メンバーシップによって制御され、各組織は **Administration → Settings** で独自のメンバーのサインインをさらに制限できます。

## マルチテナントの要件

2 つ目の組織を作成する前に、強固で安定した組織の ClickHouse 導出シークレットを設定し、すべてのサーバーレプリカで同一に保ってください。協調的なマイグレーションなしにローテーションすると、組織固有の ClickHouse ユーザーが孤立する可能性があります。

インスタンス管理者リスナーは内部に留めてください。提供されているオペレーターコンソールはオプトインであり、`kubectl port-forward` 用に設計されており、パブリックイングレスには対応していません。有効化するには独自の強力な API キー、スーパー管理者メールボックス、および動作する SMTP 二段階認証が必要です。

### ブレークグラス組織 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
```

組織操作として、作成・一覧表示・名前変更・ソフト削除・復元・ClickHouse ユーザーの再プロビジョニング・請求日管理・機能フラグ・不可逆なパージがサポートされています。メンバー操作として、追加・一覧表示・更新・削除・権限オーバーライド・保護管理者状態の管理がサポートされています。

パージの前にソフト削除を使用してください。`org purge` は不可逆であり、組織を先に削除済みにする必要があります。保護されたメンバーは、オペレーターが明示的に保護を解除するまで、組織の通常のユーザーページから削除または降格することができません。

## 本番環境への対応チェックリスト

* インジェストおよびダッシュボードの DNS が、それぞれ意図したイングレスパスに解決されること。
* TLS が有効であること。デプロイメントの要件に応じてインジェストで相互 TLS を使用すること。
* PostgreSQL および ClickHouse のボリュームに容量アラートが設定されていること。
* バックアップが両方のデータストアを対象とし、リストア手順がテスト済みであること。
* インジェストの無応答、ワークロード障害、証明書の期限切れ、ストレージ逼迫、および古いバックアップに対してヘルスチェックのアラートが設定されていること。
* 既存のクラスターログパイプラインと重複せずに構造化ログが収集されていること。
* キューの実測データなしに Evaluator、監査、アラートワーカーの並列数を変更していないこと。
* アップグレード前に、固定されたアプリケーションリリースとロールバック手順が記録されていること。

<Warning>
  デプロイメントマニフェストにはプラットフォーム固有のセキュリティおよび可用性の前提が含まれています。適用する前に、レンダリングされたリソース、ネットワークポリシー、イングレスの公開範囲、シークレット参照、ストレージクラス、Disruption Budget、およびバックアップ先をプラットフォームチームとともに確認してください。
</Warning>
