Provisionamento

O que a engine instala no passo Infraestrutura.

O passo Infraestrutura é onde tudo é montado no host. A engine instala, em sequência, com progresso transmitido ao vivo:

• k3s — Kubernetes leve e production-grade (escala para multi-node depois).
• Ingress (Traefik) + cert-manager — roteamento e TLS automático via Let's Encrypt.
• PostgreSQL e Redis in-cluster — o banco definitivo e a fila/pub-sub de logs.
• Registry de artefatos e os Runners de CI.
• Runtime serverless do Deploy.
• As imagens definitivas de api e web (deploy + migrações + seed do super admin como Jobs in-cluster).

Runners de CI#

Os jobs de pipeline rodam como pods isolados no cluster — um pod por job, com limites próprios de CPU/memória, de modo que um job pesado nunca derruba a plataforma nem os vizinhos. A capacidade é derivada do próprio cluster (sempre reservando folga para o control plane): jobs além do teto esperam na fila, e adicionar um nó à fleet aumenta a capacidade de CI automaticamente.

Todo container do pod de um job é limitado — o próprio job, os sidecars de services: e o daemon Docker por job carregam tetos explícitos, e cada volume temporário tem um limite de tamanho, de modo que um job desgovernado despeja a si mesmo em vez de pressionar o nó. O timeout-minutes do job também fica carimbado no pod: mesmo que o processo da plataforma morra no meio do job, o cluster aposenta o pod por conta própria.

Ajustando a capacidade#

O cálculo é um bom padrão, não uma sentença: em Configurações → Plataforma → Capacidade do CI você decide quanto da máquina o runner pode tomar, e cada alteração já mostra o que ela renderia neste cluster antes de você salvar.

Dois botões importam mais. A reserva da plataforma é a fatia de cada nó que o CI nunca toca — baixá-la dá mais ao CI no total, mas aí cabem mais vagas dividindo a memória, e cada job pode acabar menor. E o "não iniciar abaixo de" é um piso de admissão: o teto de um job é congelado quando o pod nasce, então um vale passageiro de memória livre pode entregar a um build de duas horas um limite sob o qual ele não termina. Abaixo do piso o nó não oferece vaga e o job espera na fila — tarde é melhor que aleijado.

A reserva também tem um piso absoluto — pelo menos 2 cores e 3 GiB ficam com o control plane, diga o que disser o percentual (em hosts minúsculos, ele encolhe sozinho). Um nó dedicado só a runners, sem nada da plataforma rodando nele, pode zerar o piso via EQS_RUNNER_MIN_PLATFORM_RESERVE_CPU / EQS_RUNNER_MIN_PLATFORM_RESERVE_MEMORY_GI.

Logs e retenção#

Um único step pode armazenar até 50.000 linhas de log (EQS_RUNNER_MAX_LOG_LINES_PER_STEP; 0 remove o teto). Passado o teto, o step continua rodando até sua conclusão real — um marcador de truncamento bem visível é gravado e o restante da saída é descartado, o que protege o banco e o stream ao vivo de um set -x desgovernado.

Logs de step expiram após 90 dias (EQS_CI_LOG_RETENTION_DAYS; 0 os guarda para sempre). Execuções, jobs, conclusões e anotações ficam — o histórico continua navegável, só a transcrição bruta expira. O garbage collector de blobs e a rotina de retenção do registry também vêm ligados por padrão (cada EQS_REGISTRY_*_ENABLED=false desliga o seu): blobs sem referência são recolhidos sozinhos, e uma política de retenção salva na tela de Artefatos simplesmente roda.

A fatia da própria plataforma#

A plataforma dimensiona os próprios pods a partir do host — banco, api e web declaram requests de recursos derivados na instalação (e preenchidos retroativamente pelas atualizações), de modo que, sob carga, o kernel arbitra a favor da plataforma em vez de tratar um job de CI e o banco como iguais. Dá para sobrescrever por componente com variáveis no estilo EQS_PG_CPU_REQUEST, quando você conhece a sua máquina melhor do que a fórmula.