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 mais tarde).
• Ingress (Traefik) + cert-manager — encaminhamento e TLS automático via Let's Encrypt.
• PostgreSQL e Redis in-cluster — a base de dados definitiva e a fila/pub-sub de registos.
• Registry de artefactos 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 correm como pods isolados no cluster — um pod por job, com limites próprios de CPU/memória, pelo que um job pesado nunca esgota a plataforma nem os vizinhos. A capacidade é derivada do próprio cluster (reservando sempre folga para o control plane): os jobs além do limite aguardam na fila, e adicionar um nó à fleet aumenta automaticamente a capacidade de CI.

Todos os containers do pod de um job têm limites — o próprio job, os sidecars de services: e o daemon Docker de cada job carregam tetos explícitos, e cada volume temporário tem um limite de tamanho, pelo que um job desgovernado se despeja a si próprio em vez de pressionar o nó. O timeout-minutes do job também fica carimbado no pod: mesmo que o processo da plataforma morra a meio do job, o próprio cluster encerra o pod.

Afinar a capacidade#

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

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 cabem mais vagas a dividir 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 fica fixo quando o pod nasce, pelo que uma descida passageira da memória livre pode dar a um build de duas horas um limite sob o qual não termina. Abaixo do piso o nó não oferece vaga e o job espera na fila — tarde é melhor do que aleijado.

A reserva tem ainda um piso absoluto — pelo menos 2 cores e 3 GiB ficam com o control plane, diga o que disser a percentagem (em hosts minúsculos, encolhe sozinho). Um nó dedicado aos runners, sem plataforma nenhuma a correr nele, pode pôr o piso a zero via EQS_RUNNER_MIN_PLATFORM_RESERVE_CPU / EQS_RUNNER_MIN_PLATFORM_RESERVE_MEMORY_GI.

Registos e retenção#

Um único step pode armazenar até 50.000 linhas de registo (EQS_RUNNER_MAX_LOG_LINES_PER_STEP; 0 remove o teto). Ultrapassado o teto, o step continua a correr até à sua conclusão real — fica gravado um marcador de truncagem bem visível e o resto da saída é descartado, o que protege a base de dados e o stream ao vivo de um set -x desgovernado.

Os registos de step expiram ao fim de 90 dias (EQS_CI_LOG_RETENTION_DAYS; 0 guarda-os para sempre). As execuções, os jobs, as conclusões e as anotações ficam — o histórico continua navegável, só a transcrição em bruto expira. O garbage collector de blobs e a rotina de retenção do registry também vêm ligados por predefinição (cada EQS_REGISTRY_*_ENABLED=false desativa o seu): os blobs sem referência são recolhidos sozinhos, e uma política de retenção gravada no ecrã de Artefactos passa simplesmente a correr.

A fatia da própria plataforma#

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