Skip to main content
Self-Hosting ist eine Enterprise-Bereitstellung. Kontaktieren Sie Failproof AI, um eine Enterprise-Lizenz zu erhalten.

​
Voraussetzungen

  • Kubernetes 1.27 oder neuer mit Cluster-Admin-Zugriff
  • kubectl mit Kustomize-Unterstützung
  • Helm 3
  • Zugriff auf die privaten ghcr.io/agenteye-enterprise-Images
  • Zwei DNS-Namen: einer für das Dashboard und einer für die Ingestion
  • Persistenter Speicher für PostgreSQL und ClickHouse
  • cert-manager und Traefik oder eine gleichwertige Ingress- und Zertifikatsinfrastruktur, die in Ihren Overlay eingebunden wird
  • SMTP für produktives OTP-Login und Benachrichtigungen
Der Quellbaum enthält einen AWS/EKS-orientierten Overlay sowie einen separaten GCP/GKE-Overlay. Vermischen Sie deren Anweisungen für Zertifikate, Load Balancer oder Backups nicht: GKE verwendet eine eigene DNS-01-, GCS- und Autoscaling-Konfiguration.

​
Bereitstellungsreihenfolge

1

Cluster vorbereiten

Installieren Sie cert-manager und die öffentlichen/Dashboard-Ingress-Controller, überprüfen Sie deren Load Balancer und erstellen Sie anschließend den Namespace, Image-Pull-Credentials, Datenbank-Credentials, den Bootstrap-Admin-Key sowie Authentifizierungs- und SMTP-Secrets.
2

Öffentliche Domains konfigurieren

Setzen Sie INGEST_DOMAIN und DASHBOARD_DOMAIN in der generierten Domain-Umgebungsdatei des Overlays und erstellen Sie DNS-Einträge, die auf die zugehörigen Load Balancer zeigen.
3

Einen Plattform-Overlay anwenden und verifizieren

Verwenden Sie den Customer/EKS- oder GCP-Overlay. Prüfen Sie die gerenderte Kustomize-Ausgabe, wenden Sie sie an und bestätigen Sie, dass alle Workloads und Zertifikate ihren gewünschten Zustand erreicht haben, bevor Sie Maschinen registrieren.
4

Zugriff und Ingestion initialisieren

Melden Sie sich als geschützter Admin an, erstellen Sie einen organisationsbezogenen Machine Key und senden Sie eine kleine Test-Session durch den öffentlichen Ingest-Endpunkt.

​
Erforderliche und optionale Dienste

​
Audit-Kapazität und Fehlerbenachrichtigung

Führen Sie Audits auf der dedizierten Audit-Agent-Bereitstellung aus, wenn verfügbar. Jeder Audit-Agent-Pod akzeptiert standardmäßig eine Untersuchung; skalieren Sie den Durchsatz über Replicas, anstatt die Parallelität pro Pod zu erhöhen, ohne gleichzeitig den Speicher zu vergrößern. Der Server kann Server-Replicas × AUDIT_WORKERS Audits gleichzeitig verarbeiten, daher sollte die Dispatcher-Kapazität groß genug sein, um die gesamte Audit-Agent-Flotte auszulasten. Wenn alle Audit-Agent-Slots belegt sind, wartet ein Audit und wiederholt den Versuch für bis zu einem Viertel seines Intervalls, maximal jedoch sechs Stunden. Wenn kein Slot frei wird, wird der Lauf ohne Befunde abgeschlossen und eine Fehler-E-Mail gesendet. Wiederholte „Belegt”-Fehler erfordern mehr Audit-Agent-Replicas oder weiter gestreute Zeitplan-Ankerpunkte. Wiederholte „Herunterfahren”-Fehler weisen auf instabile Pods oder ein sich wiederholendes Rollout hin, nicht auf unzureichende Kapazität. Fehlerbenachrichtigungen erfordern einen aktivierten E-Mail-Kanal und SMTP. Sie verwenden die Empfänger des Audits und fallen auf alerts.email_default_recipients zurück, wenn der Audit keinen E-Mail-Kanal hat.

​
Bereitstellung verifizieren

  1. Öffnen Sie die konfigurierte Dashboard-Domain, schließen Sie den Admin-OTP-Ablauf ab und bestätigen Sie den Organisationsnamen und den Slug.
  2. Gehen Sie zu Administration → Keys und erstellen Sie einen eng begrenzten Machine Key.
  3. Senden Sie eine Test-Session und bestätigen Sie diese unter Observe → Events und Observe → Sessions.
  4. Testen Sie einen Alert-Kanal sowie, wenn konfiguriert, eine manuelle Auswertung und einen Audit.

​
Authentifizierung und E-Mail

Das Dashboard verwendet E-Mail und Einmalcodes. Ohne SMTP protokollieren Entwicklungsbereitstellungen OTP-Codes in der Serverausgabe. Wenn SMTP_HOST gesetzt ist, sind Benutzername, Passwort und Absender als Gruppe erforderlich, andernfalls verweigert der Server den Start. SMTP_TLS ist ein boolescher Wert. Der unterstützte verschlüsselte Transport ist STARTTLS, normalerweise auf Port 587; implizites SMTPS auf Port 465 wird vom aktuellen Server-Transport nicht unterstützt. Setzen Sie die öffentliche Dashboard-URL korrekt, da OTP-, Alert-, Incident- und Audit-E-Mails sie für Deep Links verwenden. Die Organisationsmitgliedschaft steuert, wer einen Code anfordern darf; jede Organisation kann ihre eigenen Mitglieder-Anmeldungen zusätzlich unter Administration → Settings einschränken.

​
Anforderungen für Mehrmandantenfähigkeit

Bevor Sie eine zweite Organisation erstellen, konfigurieren Sie ein starkes, stabiles ClickHouse-Ableitungsgeheimnis für Organisationen und halten Sie es auf allen Server-Replicas identisch. Eine Rotation ohne koordinierte Migration kann organisationsspezifische ClickHouse-Benutzer verwaisen lassen. Halten Sie den Instance-Admin-Listener intern. Die mitgelieferte Operator-Konsole ist optional und für kubectl port-forward konzipiert, nicht für öffentlichen Ingress. Ihre Aktivierung erfordert einen eigenen starken API-Key, ein Super-Admin-Postfach und eine funktionierende SMTP-Zweifaktor-Zustellung.

​
Break-Glass-Organisations-CLI

agenteye-orgctl wird im Server-Image mitgeliefert und kommuniziert direkt mit PostgreSQL und ClickHouse. Es ist verfügbar, wenn der öffentliche Server oder die Operator-Konsole nicht funktionieren.
Unterstützte Organisationsoperationen umfassen: Erstellen, Auflisten, Umbenennen, Soft-Delete, Wiederherstellen, ClickHouse-Benutzer-Reprovisioning, Abrechnungsdatumsverwaltung, Feature-Flags und unwiderrufliches Löschen. Mitgliederoperationen umfassen: Hinzufügen, Auflisten, Aktualisieren, Entfernen, Berechtigungsüberschreibungen und geschützten Admin-Status. Verwenden Sie Soft-Delete vor dem endgültigen Löschen. org purge ist unwiderruflich und erfordert, dass die Organisation zuerst gelöscht wurde. Geschützte Mitglieder können nicht über die normale Benutzerseite der Organisation entfernt oder zurückgestuft werden, bis ein Operator sie explizit aufhebt.

​
Checkliste für die Produktionsbereitschaft

  • Ingest- und Dashboard-DNS werden zu den vorgesehenen, unterschiedlichen Ingress-Pfaden aufgelöst.
  • TLS ist gültig; verwenden Sie gegenseitiges TLS beim Ingest, wo Ihre Bereitstellung es erfordert.
  • PostgreSQL- und ClickHouse-Volumes haben Kapazitätswarnungen.
  • Backups umfassen beide Datenspeicher und verfügen über ein getestetes Wiederherstellungsverfahren.
  • Health-Checks warnen bei Ingest-Stille, fehlgeschlagenen Workloads, abgelaufenen Zertifikaten, Speicherdruck und veralteten Backups.
  • Strukturierte Logs werden gesammelt, ohne eine vorhandene Cluster-Log-Pipeline zu duplizieren.
  • Die Parallelität von Evaluator, Audit und Alert-Worker wurde nicht ohne gemessene Queue-Evidenz geändert.
  • Ein festgelegter Anwendungs-Release und ein Rollback-Verfahren sind vor Upgrades dokumentiert.
Die Bereitstellungsmanifeste enthalten plattformspezifische Sicherheits- und Verfügbarkeitsannahmen. Überprüfen Sie gerenderte Ressourcen, Netzwerkrichtlinien, Ingress-Exposition, Secret-Referenzen, Storage-Klassen, Disruption-Budgets und Backup-Ziele mit Ihrem Plattformteam, bevor Sie sie anwenden.