Skip to main content
El autoalojamiento es un despliegue Enterprise. Contacta con Failproof AI para obtener una licencia enterprise.

​
Requisitos previos

  • Kubernetes 1.27 o superior con acceso cluster-admin
  • kubectl con soporte para Kustomize
  • Helm 3
  • Acceso a las imágenes privadas de ghcr.io/agenteye-enterprise
  • Dos nombres DNS: uno para el panel de control y otro para la ingesta
  • Almacenamiento persistente para PostgreSQL y ClickHouse
  • cert-manager y Traefik, o una infraestructura equivalente de ingress y certificados adaptada a tu overlay
  • SMTP para login OTP en producción y notificaciones
El árbol de fuentes incluye un overlay orientado a AWS/EKS y otro separado para GCP/GKE. No combines sus instrucciones de certificados, balanceadores de carga o copias de seguridad: GKE usa su propia configuración de DNS-01, GCS y autoescalado.

​
Secuencia de despliegue

1

Preparar el clúster

Instala cert-manager y los controladores de ingress público/panel de control, verifica sus balanceadores de carga y, a continuación, crea el namespace, las credenciales de extracción de imágenes, las credenciales de base de datos, la clave de administrador de arranque y los secretos de autenticación/SMTP.
2

Configurar los dominios públicos

Establece INGEST_DOMAIN y DASHBOARD_DOMAIN en el archivo de entorno de dominio generado por el overlay y crea los registros DNS apuntando a los balanceadores de carga correspondientes.
3

Aplicar y verificar un overlay de plataforma

Usa el overlay de customer/EKS o GCP. Inspecciona la salida renderizada de Kustomize, aplícala y confirma que todas las cargas de trabajo y certificados alcanzan el estado deseado antes de incorporar máquinas.
4

Inicializar el acceso y la ingesta

Inicia sesión como administrador protegido, crea una clave de máquina con ámbito organizacional y envía una pequeña sesión de prueba a través del endpoint público de ingesta.

​
Servicios requeridos y opcionales

​
Capacidad de auditoría y entrega de fallos

Ejecuta las auditorías en el despliegue dedicado de audit-agent cuando esté disponible. Cada pod de audit-agent acepta una investigación por defecto; escala el rendimiento con réplicas en lugar de aumentar la concurrencia por pod sin incrementar también la memoria. El servidor puede despachar réplicas del servidor × AUDIT_WORKERS auditorías de forma concurrente, por lo que la capacidad del despachador debe ser suficientemente grande para abastecer a toda la flota de audit-agent. Cuando todas las ranuras del audit-agent están ocupadas, una auditoría espera y reintenta durante hasta un cuarto de su cadencia, con un máximo de seis horas. Si no queda ninguna ranura disponible, la ejecución finaliza sin hallazgos y envía un email de fallo. Los fallos repetidos por “busy” requieren más réplicas de audit-agent o anclas de programación más separadas. Los fallos repetidos por “shutting down” indican pods inestables o un rollout en bucle, no capacidad insuficiente. Las notificaciones de fallos requieren un canal de email habilitado y SMTP. Usan los destinatarios de la auditoría y, si la auditoría no tiene canal de email, recurren a alerts.email_default_recipients.

​
Verificar el despliegue

  1. Abre el dominio del panel de control configurado, completa el flujo OTP de administrador y confirma el nombre y slug de la organización.
  2. Ve a Administración → Claves y crea una clave de máquina con ámbito restringido.
  3. Envía una sesión de prueba y confírmala en Observe → Events y Observe → Sessions.
  4. Prueba un canal de alertas y, si está configurado, una evaluación manual y una auditoría.

​
Autenticación y email

El panel de control usa email y códigos de un solo uso. Si no hay SMTP configurado, los despliegues de desarrollo registran los códigos OTP en la salida del servidor. Cuando se establece SMTP_HOST, el nombre de usuario, la contraseña y el remitente son requeridos como grupo o el servidor se niega a iniciar. SMTP_TLS es un booleano. El transporte cifrado soportado es STARTTLS, normalmente en el puerto 587; el transporte SMTPS implícito en el puerto 465 no está soportado por el transporte del servidor actual. Configura correctamente la URL pública del panel de control, ya que los emails de OTP, alertas, incidentes y auditorías la utilizan para los enlaces profundos. La membresía en la organización controla quién puede solicitar un código; cada organización puede restringir adicionalmente los inicios de sesión de sus propios miembros en Administración → Configuración.

​
Requisitos multi-tenant

Antes de crear una segunda organización, configura un secreto de derivación de ClickHouse fuerte y estable para la organización, y mantenlo idéntico en todas las réplicas del servidor. Rotarlo sin una migración coordinada puede dejar huérfanos a los usuarios de ClickHouse específicos de cada organización. Mantén el listener del administrador de instancia de forma interna. La consola de operador proporcionada es opcional y está diseñada para kubectl port-forward, no para ingress público. Habilitarla requiere su propia clave API fuerte, un buzón de super-administrador y una entrega funcional del segundo factor por SMTP.

​
CLI de organización de emergencia

agenteye-orgctl se incluye dentro de la imagen del servidor y se comunica directamente con PostgreSQL y ClickHouse. Permanece disponible cuando el servidor público o la consola de operador no están disponibles.
Las operaciones de organización soportadas incluyen: crear, listar, renombrar, eliminación suave, restaurar, reaprovisionamiento de usuario de ClickHouse, gestión de fecha de facturación, indicadores de funcionalidades y purga irreversible. Las operaciones de miembros incluyen: añadir, listar, actualizar, eliminar, anulaciones de permisos y estado de administrador protegido. Usa la eliminación suave antes de la purga. org purge es irreversible y requiere que la organización esté eliminada primero. Los miembros protegidos no pueden ser eliminados ni degradados a través de la página de Usuarios ordinaria de la organización hasta que un operador los desproteja explícitamente.

​
Lista de verificación de preparación para producción

  • El DNS de ingesta y del panel de control resuelve a las rutas de ingress previstas, que son diferentes entre sí.
  • TLS es válido; usa TLS mutuo en la ingesta si tu despliegue lo requiere.
  • Los volúmenes de PostgreSQL y ClickHouse tienen alertas de capacidad.
  • Las copias de seguridad incluyen ambos almacenes de datos y cuentan con un procedimiento de restauración probado.
  • Las comprobaciones de salud alertan sobre silencio en la ingesta, cargas de trabajo fallidas, expiración de certificados, presión en el almacenamiento y copias de seguridad desactualizadas.
  • Los logs estructurados se recopilan sin duplicar un pipeline de logs del clúster existente.
  • La concurrencia de workers de Evaluator, auditoría y alertas no se ha modificado sin evidencia medida de la cola.
  • Se registra una versión de aplicación fijada y un procedimiento de rollback antes de las actualizaciones.
Los manifiestos de despliegue contienen suposiciones de seguridad y disponibilidad específicas de la plataforma. Revisa los recursos renderizados, las políticas de red, la exposición del ingress, las referencias a secretos, las clases de almacenamiento, los presupuestos de interrupción y los destinos de copia de seguridad con tu equipo de plataforma antes de aplicarlos.