Skip to main content
O self-hosting é uma implantação Enterprise. Entre em contato com o Failproof AI para obter uma licença empresarial.

​
Pré-requisitos

  • Kubernetes 1.27 ou mais recente com acesso cluster-admin
  • kubectl com suporte a Kustomize
  • Helm 3
  • Acesso às imagens privadas ghcr.io/agenteye-enterprise
  • Dois nomes DNS: um para o dashboard e outro para ingest
  • Armazenamento persistente para PostgreSQL e ClickHouse
  • cert-manager e Traefik, ou infraestrutura equivalente de ingress e certificados adaptada ao seu overlay
  • SMTP para login OTP em produção e notificações
A árvore de fontes fornece um overlay orientado para AWS/EKS e um overlay separado para GCP/GKE. Não combine as instruções de certificado, balanceador de carga ou backup entre eles: o GKE utiliza sua própria configuração de DNS-01, GCS e autoescalonamento.

​
Sequência de implantação

1

Preparar o cluster

Instale o cert-manager e os controladores de ingress público/dashboard, verifique seus balanceadores de carga e, em seguida, crie o namespace, as credenciais de pull de imagem, as credenciais do banco de dados, a chave de bootstrap do administrador e os secrets de autenticação/SMTP.
2

Configurar domínios públicos

Defina INGEST_DOMAIN e DASHBOARD_DOMAIN no arquivo de ambiente de domínio gerado pelo overlay e crie registros DNS apontando para os balanceadores de carga correspondentes.
3

Aplicar e verificar um overlay de plataforma

Use o overlay customer/EKS ou GCP. Inspecione a saída renderizada do Kustomize, aplique-a e confirme que todas as cargas de trabalho e certificados atingiram o estado desejado antes de registrar máquinas.
4

Inicializar o acesso e a ingestão

Faça login como administrador protegido, crie uma chave de máquina com escopo de organização e envie uma pequena sessão de teste pelo endpoint de ingest público.

​
Serviços obrigatórios e opcionais

​
Capacidade de auditoria e entrega em caso de falha

Execute auditorias no deployment dedicado de audit-agent quando disponível. Cada pod de audit-agent aceita uma investigação por padrão; escalone o throughput com réplicas em vez de aumentar a concorrência por pod sem também aumentar a memória. O servidor pode despachar réplicas do servidor × AUDIT_WORKERS auditorias concorrentemente, portanto, a capacidade do dispatcher deve ser grande o suficiente para preencher a frota de audit-agents. Quando todos os slots do audit-agent estão ocupados, uma auditoria aguarda e tenta novamente por até um quarto de sua cadência, limitado a seis horas. Se nenhum slot ficar disponível, a execução é concluída sem resultados e envia um e-mail de falha. Falhas recorrentes do tipo “ocupado” indicam a necessidade de mais réplicas de audit-agent ou âncoras de agendamento mais espaçadas. Falhas recorrentes do tipo “encerrando” indicam pods instáveis ou um rollout em loop, e não capacidade insuficiente. As notificações de falha exigem um canal de e-mail habilitado e SMTP. Elas usam os destinatários da auditoria e, na ausência de um canal de e-mail configurado na auditoria, recorrem a alerts.email_default_recipients.

​
Verificar a implantação

  1. Abra o domínio do dashboard configurado, conclua o fluxo OTP do administrador e confirme o nome e o slug da organização.
  2. Acesse Administração → Chaves e crie uma chave de máquina com escopo restrito.
  3. Envie uma sessão de teste e confirme-a em Observar → Eventos e Observar → Sessões.
  4. Teste um canal de alerta e, quando configurado, uma avaliação manual e uma auditoria.

​
Autenticação e e-mail

O dashboard utiliza e-mail e códigos de uso único. Sem SMTP, implantações de desenvolvimento registram os códigos OTP na saída do servidor. Quando SMTP_HOST está definido, nome de usuário, senha e remetente são obrigatórios em conjunto; caso contrário, o servidor recusa a inicialização. SMTP_TLS é um booleano. O transporte criptografado suportado é STARTTLS, normalmente na porta 587; SMTPS implícito na porta 465 não é suportado pelo transporte atual do servidor. Configure corretamente a URL pública do dashboard, pois os e-mails de OTP, alerta, incidente e auditoria utilizam-na para deep links. A associação à organização controla quem pode solicitar um código; cada organização pode restringir ainda mais os logins de seus próprios membros em Administração → Configurações.

​
Requisitos para multi-tenant

Antes de criar uma segunda organização, configure um secret de derivação ClickHouse forte e estável para a organização e mantenha-o idêntico em todas as réplicas do servidor. Rotacioná-lo sem uma migração coordenada pode tornar os usuários ClickHouse específicos da organização inacessíveis. Mantenha o listener do administrador de instância interno. O console do operador fornecido é opcional e foi projetado para kubectl port-forward, não para ingress público. Habilitá-lo requer sua própria chave de API forte, uma caixa de correio de super-admin e entrega funcional do segundo fator via SMTP.

​
CLI de organização para acesso de emergência

agenteye-orgctl é incluído na imagem do servidor e se comunica diretamente com o PostgreSQL e o ClickHouse. Permanece disponível quando o servidor público ou o console do operador está indisponível.
As operações de organização suportadas incluem: criar, listar, renomear, exclusão lógica, restaurar, reprovisionamento de usuário ClickHouse, gerenciamento de data de faturamento, feature flags e exclusão irreversível. As operações de membros incluem: adicionar, listar, atualizar, remover, substituições de permissão e estado de administrador protegido. Use a exclusão lógica antes da exclusão definitiva. org purge é irreversível e exige que a organização seja excluída primeiro. Membros protegidos não podem ser removidos ou rebaixados pela página comum de Usuários da organização até que um operador os desproteja explicitamente.

​
Checklist de prontidão para produção

  • DNS de ingest e dashboard resolve para os caminhos de ingress pretendidos diferentes.
  • O TLS é válido; use TLS mútuo no ingest onde sua implantação exigir.
  • Os volumes do PostgreSQL e ClickHouse possuem alertas de capacidade.
  • Os backups incluem ambos os datastores e possuem um procedimento de restauração testado.
  • Os health checks alertam sobre silêncio no ingest, cargas de trabalho com falha, expiração de certificados, pressão de armazenamento e backups desatualizados.
  • Os logs estruturados são coletados sem duplicar um pipeline de logs existente no cluster.
  • A concorrência do Evaluator, auditoria e workers de alerta não foi alterada sem evidências mensuradas de fila.
  • Uma release de aplicação fixada e um procedimento de rollback estão registrados antes das atualizações.
Os manifestos de implantação contêm suposições de segurança e disponibilidade específicas da plataforma. Revise os recursos renderizados, as políticas de rede, a exposição do ingress, as referências a secrets, as classes de armazenamento, os orçamentos de interrupção e os destinos de backup com sua equipe de plataforma antes de aplicá-los.