pulse

/projects/ulbra-infra

← Todos os projetos

Ulbra Infra

De uma pessoa no servidor a um repositório e um pipeline.

Head de Tecnologia — design & implementação · Abr 2026 – Atual

Docker SwarmTraefikGitHub ActionsOpenTelemetrySigNozPrometheusGrafanaMetabase
Privado

Visão geral

A plataforma sob todos os outros sistemas deste grupo. Começou como servidores on-premise sem nenhuma automação — publicar significava uma pessoa na máquina, instalando um runtime e subindo a aplicação na mão. Hoje é um script de provisionamento, um orquestrador de contêineres, um proxy reverso, duas ferramentas de observabilidade com uma divisão declarada e um ciclo de entrega em que um alerta pode investigar a si mesmo e abrir um pull request.

O que eu fiz

Desenhei e construí a plataforma e o modelo de entrega que roda sobre ela.

  • O script de provisionamento em uma execução e o cluster que ele produz.
  • O proxy reverso e a convenção de roteamento que toda aplicação segue.
  • A divisão entre observabilidade de aplicação e de host.
  • O pipeline de CI e o ciclo alerta-para-pull-request construído sobre ele.
  • O painel de entrega que lê o próprio rastreador de tarefas do time.

O problema

Tudo rodava on-premise sem nenhuma automação em volta. Colocar uma aplicação em produção significava conectar num servidor, instalar um runtime e subir o processo na mão — o que torna todo deploy um exercício de memória, todo servidor sutilmente diferente do anterior e toda queda um problema de arqueologia. Nada era medido, então nada podia ser melhorado de propósito.

Provisiona uma vez, depois por aplicação

O servidor é configurado numa execução; depois disso, publicar uma aplicação é um repositório e um pipeline.

  1. ProvisionUm script: runtime, firewall, cluster, redes overlay.
  2. PlatformO proxy reverso e as stacks de observabilidade sobem junto.
  3. PushA CI constrói a imagem e envia para o registry.
  4. DeployO pipeline publica a stack; o proxy pega a rota pelos labels.
  5. ObserveTraces, logs e métricas chegam só pelas variáveis de ambiente.

De um alerta a uma correção mesclada

O que o time automatizou é a investigação, não o julgamento.

  1. AlertA telemetria da aplicação cruza um limiar.
  2. InvestigateUm agente de código lê o trace e o código em volta.
  3. Pull requestUma correção proposta chega como uma mudança normal para revisar.
  4. ReviewUm engenheiro aceita, ajusta ou rejeita.
  5. MergeO mesmo pipeline por onde passa qualquer outra mudança.

O que uma aplicação declara

services:
  my-app:
    image: registry.example.internal/my-app:latest
    networks: [proxy, monitoring]
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
      - OTEL_SERVICE_NAME=my-app
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.routers.myapp.rule=Host(`my-app.example.internal`)"
Os hostnames são fictícios. Roteamento, certificados e telemetria saem todos deste bloco — não há um segundo lugar onde registrar uma aplicação.

O que faz

  • Um script leva um servidor cru até pronto: runtime de contêiner, firewall, cluster, redes overlay, proxy e monitoramento.
  • Uma aplicação nova precisa de um compose e um workflow — o roteamento e o certificado saem dos labels.
  • A telemetria é opcional por variáveis de ambiente; nada mais precisa ser ligado.
  • Um alerta pode ser investigado automaticamente e chegar como um pull request para um humano julgar.

Decisões de engenharia

  • Duas ferramentas de observabilidade, numa fronteira declarada

    A telemetria de aplicação — logs, traces, métricas — vai para uma ferramenta via OpenTelemetry; métricas de host como CPU, memória e disco ficam em outra. Manter as duas parece deriva até se ler a regra escrita na configuração: aplicações não reportam para a stack de host. Cada ferramenta é boa em um dos dois trabalhos, e a alternativa considerada e descartada era uma só fazendo os dois mal.

  • Alertas se investigam; humanos ainda mesclam

    Quando a telemetria de aplicação dispara um alerta, um agente de código lê o trace e o código em volta e abre um pull request com uma correção proposta. O que foi automatizado é a investigação — a parte mecânica e lenta às três da manhã. O merge não é automatizado, e de propósito: uma mudança que ninguém aprovou chegando em produção é uma falha pior do que uma correção lenta.

  • Um orquestrador do tamanho do time

    Kubernetes era a resposta padrão e não foi adotado. O cluster é pequeno, on-premise, e operado por três engenheiros que também escrevem seis aplicações. O Swarm dá agendamento multi-nó, rolling update e rede overlay com uma fração da superfície operacional — e o custo do teto que ele impõe é muito menor que o de um control plane que ninguém tem tempo de operar.

  • O time se mede com o próprio pipeline

    Um painel lê o rastreador de tarefas do time por um sidecar de ETL, então a entrega fica visível no mesmo lugar em que estão os números dos sistemas. É um encanamento pequeno carregando uma afirmação grande: um modelo de trabalho que é medido pode ser discutido com evidência, e um que é apenas afirmado, não.