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.
129 lines
2.9 KiB
Markdown
129 lines
2.9 KiB
Markdown
# 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
|