Skip to main content
セルフホストはエンタープライズ向けデプロイメントです。エンタープライズライセンスを取得するには Failproof AI までお問い合わせください。

​
前提条件

  • 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、およびオートスケーリング設定を使用します。

​
デプロイメントの手順

1

クラスターの準備

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

パブリックドメインの設定

オーバーレイで生成されるドメイン環境ファイルに INGEST_DOMAIN と DASHBOARD_DOMAIN を設定し、対応するロードバランサーを指す DNS レコードを作成します。
3

プラットフォームオーバーレイの適用と確認

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

アクセスとインジェストのブートストラップ

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

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

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

利用可能な場合は専用の audit-agent デプロイメントで監査を実行してください。各 audit-agent ポッドはデフォルトで 1 件の調査を受け付けます。スループットを上げる場合は、メモリを同時に増やさずにポッドあたりの並列数を引き上げるのではなく、レプリカ数でスケールしてください。サーバーは サーバーレプリカ数 × AUDIT_WORKERS 件の監査を並行してディスパッチできるため、ディスパッチャーの容量は audit-agent フリートを十分に埋められる大きさにする必要があります。 すべての audit-agent スロットがビジー状態の場合、監査はカデンスの 4 分の 1（最大 6 時間）まで待機してリトライします。スロットが空かない場合、実行は結果なしで完了し、失敗メールが送信されます。「busy」の失敗が繰り返される場合は audit-agent レプリカを増やすか、スケジュールのアンカー間隔を広げてください。「shutting down」の失敗が繰り返される場合は、容量不足ではなく不安定なポッドやループするロールアウトが原因です。 失敗通知には有効なメールチャネルと SMTP が必要です。監査の受信者リストを使用し、監査にメールチャネルがない場合は alerts.email_default_recipients にフォールバックします。

​
デプロイメントの検証

  1. 設定したダッシュボードドメインを開き、管理者の OTP フローを完了して、組織名とスラッグを確認します。
  2. Administration → Keys に移動して、スコープを絞ったマシンキーを作成します。
  3. テストセッションを送信し、Observe → Events および Observe → Sessions で確認します。
  4. アラートチャネルをテストし、設定済みの場合は手動評価と監査もテストします。

​
認証とメール

ダッシュボードはメールとワンタイムコードを使用します。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 に直接接続します。パブリックサーバーまたはオペレーターコンソールが正常でない場合でも使用できます。
組織操作として、作成・一覧表示・名前変更・ソフト削除・復元・ClickHouse ユーザーの再プロビジョニング・請求日管理・機能フラグ・不可逆なパージがサポートされています。メンバー操作として、追加・一覧表示・更新・削除・権限オーバーライド・保護管理者状態の管理がサポートされています。 パージの前にソフト削除を使用してください。org purge は不可逆であり、組織を先に削除済みにする必要があります。保護されたメンバーは、オペレーターが明示的に保護を解除するまで、組織の通常のユーザーページから削除または降格することができません。

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

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