vitor
/
orquestrador
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
feat/self-evolving-tools-foundation
main
chore/observability-latency-markers
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'feat/self-evolving-tools-foundation'
${ noResults }
orquestrador/docs/architecture/independent-deploy-strategy.md

2.9 KiB
Raw Permalink Blame History

Estrategia De Deploy Independente Para Product E Admin

Este documento define a estrategia de deploy para manter orquestrador-product e orquestrador-admin como servicos distintos, porem ligados.

Objetivo

Permitir que:

  • o atendimento continue estavel mesmo se o admin estiver fora do ar
  • o admin evolua com login, painel, relatorios e geracao de tools sem impactar o hot path
  • os dois servicos possam ser versionados e publicados com cadencias diferentes

Servico de produto

Nome operacional sugerido:

  • orquestrador-product

Responsabilidades:

  • Telegram
  • orquestracao
  • execucao de tools publicadas
  • regras operacionais do atendimento

Unit systemd sugerida:

  • deploy/systemd/orquestrador-product.service.example

Servico administrativo

Nome operacional sugerido:

  • orquestrador-admin

Responsabilidades:

  • autenticacao interna
  • painel administrativo
  • relatorios
  • configuracao do sistema
  • geracao, validacao, aprovacao e publicacao de tools

Unit systemd sugerida:

  • deploy/systemd/orquestrador-admin.service.example

Principios

  1. Deploy do admin nao deve exigir restart do product.
  2. Deploy do product nao deve depender do admin estar online.
  3. Mudancas em shared/contracts devem ser compativeis para frente e para tras durante a janela de rollout.
  4. O product consome somente estado publicado e aprovado.
  5. O admin nao entra no hot path do atendimento.

Configuracao de ambiente

Sugestao de arquivos distintos:

  • .env.product
  • .env.admin

product

Mantem:

  • Vertex do atendimento
  • Redis do estado conversacional
  • Telegram
  • bancos do runtime operacional

admin

Mantem:

  • credenciais do painel interno
  • banco administrativo
  • modelo de geracao de codigo
  • configuracoes de relatorios e publicacao

Estrategia de rollout

Mudancas so no admin

  1. publicar codigo do admin
  2. atualizar dependencias do admin
  3. reiniciar apenas orquestrador-admin

Mudancas so no product

  1. publicar codigo do product
  2. atualizar dependencias do product
  3. reiniciar apenas orquestrador-product

Mudancas em contratos compartilhados

  1. publicar contrato novo de forma aditiva
  2. subir primeiro o servico consumidor mais tolerante
  3. subir o outro servico depois
  4. so remover campos antigos numa fase posterior

Banco e publicacao de estado

Nesta fase, a estrategia recomendada e:

  • admin grava seus proprios metadados e artefatos
  • product consome somente dados publicados e estaveis
  • nenhuma dependencia sincrona do product para consultar admin em tempo de atendimento

Observabilidade

Cada servico deve ter:

  • logs proprios
  • unit systemd propria
  • variaveis de ambiente proprias
  • healthcheck proprio

Situacao atual

Hoje o runtime real em producao ainda e o de product.

Esta estrategia ja prepara o caminho para:

  • manter o deploy atual do produto
  • introduzir o admin como segundo servico
  • fazer a transicao sem mover app/ agora