Skip to main content
L’auto-hébergement est un déploiement Enterprise. Contactez Failproof AI pour obtenir une licence enterprise.

​
Prérequis

  • Kubernetes 1.27 ou supérieur avec accès cluster-admin
  • kubectl avec support Kustomize
  • Helm 3
  • Accès aux images privées ghcr.io/agenteye-enterprise
  • Deux noms DNS : un pour le tableau de bord et un pour l’ingestion
  • Stockage persistant pour PostgreSQL et ClickHouse
  • cert-manager et Traefik, ou une infrastructure d’entrée et de certificats équivalente adaptée à votre overlay
  • SMTP pour la connexion OTP en production et les notifications
L’arborescence source fournit un overlay orienté AWS/EKS et un overlay séparé GCP/GKE. Ne combinez pas leurs instructions de certificat, d’équilibreur de charge ou de sauvegarde : GKE utilise sa propre configuration DNS-01, GCS et d’autoscaling.

​
Séquence de déploiement

1

Préparer le cluster

Installez cert-manager et les contrôleurs d’entrée public/tableau de bord, vérifiez leurs équilibreurs de charge, puis créez l’espace de noms, les identifiants de tirage d’images, les identifiants de base de données, la clé d’administration de démarrage, et les secrets d’authentification/SMTP.
2

Configurer les domaines publics

Définissez INGEST_DOMAIN et DASHBOARD_DOMAIN dans le fichier d’environnement de domaine généré par l’overlay et créez des enregistrements DNS pointant vers les équilibreurs de charge correspondants.
3

Appliquer et vérifier un overlay de plateforme

Utilisez l’overlay customer/EKS ou GCP. Inspectez la sortie Kustomize rendue, appliquez-la et confirmez que toutes les charges de travail et tous les certificats atteignent l’état souhaité avant d’enrôler des machines.
4

Initialiser l'accès et l'ingestion

Connectez-vous en tant qu’administrateur protégé, créez une clé de machine limitée à l’organisation, puis envoyez une petite session de test via le point de terminaison d’ingestion public.

​
Services requis et optionnels

​
Capacité d’audit et remise en cas d’échec

Exécutez les audits sur le déploiement audit-agent dédié lorsqu’il est disponible. Chaque pod audit-agent accepte une investigation par défaut ; augmentez le débit en ajoutant des réplicas plutôt qu’en augmentant la simultanéité par pod sans augmenter également la mémoire. Le serveur peut distribuer server replicas × AUDIT_WORKERS audits simultanément, donc la capacité du répartiteur doit être suffisamment grande pour alimenter l’ensemble des agents d’audit. Lorsque tous les emplacements audit-agent sont occupés, un audit attend et réessaie pendant au plus un quart de sa cadence, plafonné à six heures. Si aucun emplacement ne devient disponible, l’exécution se termine sans résultats et envoie un email d’échec. Des échecs répétés de type « occupé » nécessitent davantage de réplicas audit-agent ou des ancres de planification plus espacées. Des échecs répétés de type « en cours d’arrêt » indiquent des pods instables ou un déploiement en boucle plutôt qu’une capacité insuffisante. Les notifications d’échec nécessitent un canal email activé et SMTP. Elles utilisent les destinataires de l’audit, puis se rabattent sur alerts.email_default_recipients lorsque l’audit ne possède pas de canal email.

​
Vérifier le déploiement

  1. Ouvrez le domaine du tableau de bord configuré, effectuez le flux OTP d’administration, et confirmez le nom et le slug de l’organisation.
  2. Accédez à Administration → Clés et créez une clé de machine à portée restreinte.
  3. Envoyez une session de test, puis confirmez-la dans Observer → Événements et Observer → Sessions.
  4. Testez un canal d’alerte et, lorsqu’il est configuré, une évaluation manuelle et un audit.

​
Authentification et email

Le tableau de bord utilise les emails et les codes à usage unique. En l’absence de SMTP, les déploiements de développement consignent les codes OTP dans la sortie du serveur. Lorsque SMTP_HOST est défini, le nom d’utilisateur, le mot de passe et l’expéditeur sont requis en tant que groupe, sinon le serveur refuse de démarrer. SMTP_TLS est un booléen. Le transport chiffré pris en charge est STARTTLS, normalement sur le port 587 ; le SMTPS implicite sur le port 465 n’est pas pris en charge par le transport serveur actuel. Définissez correctement l’URL publique du tableau de bord, car les emails d’OTP, d’alerte, d’incident et d’audit l’utilisent pour les liens profonds. L’appartenance à l’organisation contrôle qui peut demander un code ; chaque organisation peut également restreindre les connexions de ses propres membres dans Administration → Paramètres.

​
Exigences multi-tenant

Avant de créer une deuxième organisation, configurez un secret de dérivation ClickHouse d’organisation robuste et stable, et gardez-le identique sur tous les réplicas du serveur. Le faire pivoter sans une migration coordonnée peut rendre orphelins les utilisateurs ClickHouse spécifiques à l’organisation. Maintenez l’écouteur instance-admin en interne. La console opérateur fournie est optionnelle et est conçue pour kubectl port-forward, non pour une entrée publique. Son activation nécessite sa propre clé API robuste, une boîte aux lettres super-admin et une livraison SMTP fonctionnelle pour le second facteur.

​
CLI d’organisation en mode break-glass

agenteye-orgctl est intégré dans l’image du serveur et communique directement avec PostgreSQL et ClickHouse. Il reste disponible lorsque le serveur public ou la console opérateur est indisponible.
Les opérations d’organisation prises en charge incluent : créer, lister, renommer, suppression logique, restaurer, reprovisionnement des utilisateurs ClickHouse, gestion des dates de facturation, indicateurs de fonctionnalités et purge irréversible. Les opérations sur les membres incluent : ajouter, lister, mettre à jour, supprimer, remplacements de permissions et état d’administrateur protégé. Utilisez la suppression logique avant la purge. org purge est irréversible et nécessite que l’organisation soit d’abord supprimée. Les membres protégés ne peuvent pas être supprimés ou rétrogradés via la page Utilisateurs ordinaire de l’organisation, tant qu’un opérateur ne les déprotège pas explicitement.

​
Liste de contrôle pour la préparation à la production

  • Les DNS d’ingestion et de tableau de bord se résolvent vers les chemins d’entrée prévus distincts.
  • Le TLS est valide ; utilisez le TLS mutuel sur l’ingestion lorsque votre déploiement l’exige.
  • Les volumes PostgreSQL et ClickHouse disposent d’alertes de capacité.
  • Les sauvegardes incluent les deux magasins de données et disposent d’une procédure de restauration testée.
  • Les vérifications de santé alertent sur le silence d’ingestion, les charges de travail en échec, l’expiration des certificats, la pression de stockage et les sauvegardes obsolètes.
  • Les journaux structurés sont collectés sans dupliquer un pipeline de journaux de cluster existant.
  • La simultanéité des workers d’évaluation, d’audit et d’alerte n’a pas été modifiée sans preuves mesurées de file d’attente.
  • Une version d’application épinglée et une procédure de rollback sont enregistrées avant les mises à niveau.
Les manifestes de déploiement contiennent des hypothèses de sécurité et de disponibilité spécifiques à la plateforme. Examinez les ressources rendues, les politiques réseau, l’exposition des entrées, les références aux secrets, les classes de stockage, les budgets de perturbation et les destinations de sauvegarde avec votre équipe de plateforme avant de les appliquer.