Kestra (http://kestra.io)

O Kestra é utilizado para realizar a ingestão das bases de conhecimento dos componentes. Existem quatro fluxos para tratar essa ingestão: Ingestao, IngestaoComponentes, IngestaoBasesConhecimento e IngestaoFontesDados. O fluxo Ingestao é acionado através de um Trigger do Kafka, que chama o fluxo IngestaoComponente para cada componente que possui Bases de Conhecimento.

Ao criar uma nova instância do Kestra em um ambiente, ficar atento a:

• Criar um tópico no Kafka específico desse ambiente e configurar esse tópico no Kestra:

  - id: kafka_deploy_topic_trigger 
    type: br.gov.serpro.plugins.serprobots.kafka.ChatbotDeployTrigger
    bootstrapServersEnvKey: "SERPROBOTS_KAKFA_SERVERS"
    groupEnvKey: "SERPROBOTS_KAFKA_GROUP"
    certPahEnvKey: "SERPROBOTS_KAFKA_CERT_PATH"
    clientIdEnvKey: "SERPROBOTS_KAFKA_CLIENT_ID"
    usernameEnvKey: "SERPROBOTS_KAFKA_USER"
    passwordEnvKey: "SERPROBOTS_KAFKA_PASSWORD"
    topics: ["11537.chatbots.deploys"] 

• Definir os valores das variáveis associadas ao módulo dentro do ambiente (principalmente a KESTRA_PLUGINS_PATH)
• Criar o storage que deve conter o arquivo config.yml (do tipo Anexo), que contém as configurações do Kestra (banco de dados e S3)
• Criar um PostgreSQL na versão 15 para o Kestra para usar no ambiente P
  • O ambiente P precisa de seu próprio banco de dados. Entretanto, talvez possamos manter um único Kestra pra D e H
  • Para ter um único Kestra pra D e H, entretanto, precisamos mudar o Kestra para não obter as envvars usando System.getenv(), pois aí ele vai obter as vars somente daquele ambiente em que ele está publicado
• Criar o storage de objetos que deve ser usado pelo Kestra (lembrar de configurar no config.yml). Estamos usando o padrão kestra-desenv, kestra-prod e etc
  • Cada ambiente precisa ter seu próprio storage
• Usar a mesma instância do PostgreSQL para os databases kestra_d e kesta_h (kestra_h precisa ser criado). O Kestra já faz o migration e cria a estrutura do database na inicialização
• Precisa criar o gitlab-ci para integrar os plugins com a publicação do Kestra no Estaleiro

Endereços

O Kestra fornece uma interface gráfica para acompanhar a execução dos fluxos:

• Ambiente D: https://kestra-d-serprobots.estaleiro.serpro.gov.br/

Storage S3

O Kestra utiliza o Storage de objetos do Estaleiro para guardar o estado da execução dos fluxos. NÃO COMPARTILHE os storages entre os ambientes. Cada instância do Kestra precisa ter o seu próprio storage. No caso de compartilhamento, ocorrerão problemas na execução dos fluxos.

Deploy

O Kestra está hospedado no repositório https://gitcorporativo.serpro/serprobots-11537/serprobots.kestra/kestra. Ainda não temos um .gitlab-ci para ele, entretanto, é simples. Basta publicar o módulo com o conteúdo da pasta. A pasta plugins contém todos os plugins que necessitamos. Sempre que um plugin for alterado ou um novo usado, é necessário copiá-lo para essa pasta e depois republicar o módulo no ambiente desejado.

Foi criado um script deploy.ps1 que realiza a publicação no Estaleiro e um script run.ps1 para executar o Kestra localmente.

Testar subir os parâmetros de memória heap do Java no Procfile. Está usando 1gb mas o flavor no Estaleiro é de 4gb.

Plugins

Foram criados plugins específicos para o Serprobots. Esses plugins auxiliam a ingestão das bases de conhecimento, conectando-se ao Elastic, Kafka, ReRanker, LLM e etc. Esses plugins estão em https://gitcorporativo.serpro/serprobots-11537/serprobots.kestra. Ao modificar um plugin, é necessário rodar a task shadowJar no Gradle. Será gerado um JAR contendo todas as dependências. É necessário copiar esse JAR para a pasta plugins do Kestra e republicar o módulo do Kestra.

Execução local

O Kestra pode ser rodado localmente através do script run.ps1 (é necessário adaptá-lo para o Linux). No ambiente local, é necessário também criar um banco de dados específico para o Kestra. Não utilize o banco de dados de D, H ou P. Evite sujar o banco de dados desses ambientes com testes locais. Foi criado um storage de objetos chamado kestra-localhost para estes testes na máquina do desenvolvedor. Não use os storages dos ambientes D, H e P para testes locais.

Para os testes locais, o ideal é usar o Trigger do Webhook que está definido no fluxo Ingestao. Dessa forma, fica mais fácil. Para testar, obtenha um ID de um Deploy e execute o HTTPie a seguir (precisamos da versão cURL também aqui):

http POST http://localhost:8080/api/v1/executions/webhook/br.gov.serpro.serprobots/Ingestao/4wjtkzwVGBM9yKnjm3yv8r deploy=26d13d0a-2a42-4082-aec8-9f787e06d704

Obter os IDs dos deploys de um chatbot pela URL: https://d-serprobots.estaleiro.serpro.gov.br/manager/api/v2/chatbots/d1e0b52a-a053-405a-acbc-fce6f96fb4f1/publish/history?sort=desc(date)&page=1&size=5

Atenção!

Ao desenvolver uma task para o Kestra, evite criar outputs grandes. Isso vai estourar a memória do ExecutionContext do Kestra e causar problemas na execução das tarefas. Sempre guarde esses dados no Internal Storage do Kestra e repasse a URI do Storage para as demais tarefas. O Plugin do Serprobots foi desenvolvido desta forma.

Novas Versões do Kestra

Quando forem lançadas novas versões do Kestra, é só obter o .jar do standalone, copiar na pasta do Kestra e republicar no Estaleiro.