SRE · INTEGRAÇÕES · PRODUÇÃO
Rentech Operations Ecosystem
Ecossistema leve para operar, integrar e observar cinco aplicações independentes em uma única VM, com contratos de saúde, catálogo privado e histórico de incidentes.
01 — CONTEXTO
Problema
Aplicações independentes podem funcionar isoladamente e ainda assim formar uma operação frágil: portas divergentes, healthchecks incompatíveis, logs sem limite e integrações acopladas ao banco tornam incidentes difíceis de enxergar e mudanças arriscadas de repetir.
02 — SOLUÇÃO
O que construí
Padronizei contratos mínimos de saúde e identidade, mantive cada sistema dono dos próprios dados e criei duas camadas pequenas: um Hub privado para descoberta allowlisted de APIs e um Monitor para telemetria, histórico e incidentes. Caddy permanece como único ingresso web, enquanto bancos e serviços internos ficam em redes privadas.
03 — FLUXO
Arquitetura
- 01Internet e Caddy
- 02Aplicações independentes
- 03Contratos /api/v1
- 04Rentech Hub privado
- 05Rentech Monitor
- 06Prometheus e PostgreSQL
04 — ENGENHARIA
Decisões de construção
- Separar integração e observabilidade: o Hub descobre contratos autorizados; o Monitor armazena sinais e incidentes.
- Manter apenas o proxy reverso exposto e conectar aplicações, bancos e telemetria por redes Docker privadas.
- Usar contratos pequenos e versionados em vez de permitir acesso cruzado aos bancos ou criar um proxy genérico.
- Aplicar mudanças de produção por serviço, sempre com backup verificável e healthcheck pós-deploy.
05 — REALIDADE
Desafios
- Reconciliar código implantado e histórico Git sem substituir funcionalidades válidas nem dados reais.
- Observar containers e host com baixo consumo de recursos e retenção compatível com uma VM pequena.
- Padronizar aplicações de stacks diferentes sem apagar a identidade ou impor complexidade desnecessária.
06 — RESPONSABILIDADE
Segurança e limites
- Somente SSH, HTTP e HTTPS permanecem públicos; aplicações e bancos usam loopback ou redes internas.
- O Hub aceita apenas destinos imutáveis e conhecidos, limita resposta, rejeita redirects e usa token exclusivo entre serviços.
- Containers críticos usam usuário não-root, filesystem somente leitura, capabilities removidas e logs rotacionados quando compatível.
- Backups de banco têm checksum e validação de estrutura antes de migrations aditivas e reversíveis.
07 — ESTADO REAL
Resultado atual
Cinco serviços de produção agora publicam contratos compatíveis e aparecem em um catálogo operacional com versão, latência e disponibilidade. Checks são retidos por 30 dias, indisponibilidades geram incidentes deduplicados e deploys seguem backup, migration, healthcheck e validação real de domínio.
08 — EVOLUÇÃO
O que aprendi
- Observabilidade útil começa por contratos previsíveis e validação de produção, não pela quantidade de dashboards.
- Uma camada de integração fica mais segura quando conhece poucos destinos e poucas operações explicitamente permitidas.
- O melhor deploy para uma VM compartilhada é pequeno, reversível e capaz de provar que o fluxo real continua funcionando.
09 — CONTINUIDADE
Próximos passos
- Exibir tendências de latência e incidentes a partir do histórico já coletado.
- Adicionar service accounts com scopes específicos apenas quando surgirem integrações de negócio.
- Integrar alertas externos por canal configurável sem colocar credenciais no navegador ou no repositório.