Runners do CircleCI: autoscaling de máquinas não substitui o desenho da fila

O CircleCI lançou em disponibilidade geral o Machine Runner Orchestrator 1.0.0, que cria e remove máquinas virtuais conforme a demanda de jobs.[15] A ferramenta amplia a prévia chamada Runner Provisioner e gerencia cargas CPU, GPU e ARM a partir de uma implantação.[15] O ganho potencial está em adaptar a capacidade à fila, não em tornar todo build automaticamente mais rápido.

O que muda para quem desenvolve

A camada de controle roda em Kubernetes, com suporte a GKE, AKS, EKS e KubeVirt, enquanto os runners continuam sendo máquinas.[15] O produto está incluído nos planos que oferecem runners auto-hospedados, sem cobrança adicional pela funcionalidade, segundo o CircleCI.[15] Essa condição não elimina o custo das máquinas e dos serviços usados para operá-las.

O anúncio diferencia o orquestrador dos autoscalers de nós: Karpenter e Cluster Autoscaler ajustam capacidade para workloads Kubernetes; a ferramenta CircleCI responde à fila de jobs e às máquinas registradas como runners.[15] Minha leitura: são decisões em camadas diferentes e devem ter métricas próprias.

Para a equipe de desenvolvimento, recomendo separar tempo esperando capacidade, tempo preparando a máquina e tempo executando o build. Sem essa divisão, é fácil investir em mais runners quando a maior parcela do atraso está dentro da tarefa.

A abordagem enfatiza VMs, enquanto o GitHub Actions Runner Controller normalmente cria ambientes efêmeros como workloads gerenciados pelo Kubernetes.[15] Escolha o modelo pelos requisitos de execução e isolamento, não por uma comparação superficial entre nomes de ferramentas.

Como aplicar

Selecione uma classe de jobs e registre uma linha de base: espera na fila, preparação do ambiente, duração, taxa de falha e tempo de máquina ociosa. Inclua uma carga representativa, não apenas o build mais curto.

Proponha um teste de subida de demanda seguido de queda. Verifique se novas máquinas ficam prontas em tempo útil e se a capacidade deixa de gerar custo quando já não é necessária. Registre também o comportamento quando uma máquina falha durante preparação ou execução.

Defina limites de capacidade e de custo antes do ensaio. Para GPU e ARM, confira se imagem, dependências e testes atendem a cada classe; um único controlador não deve ser interpretado como ambiente de build universal.

Se houver a prévia instalada, planeje uma janela específica. A atualização exige remover a instalação antiga e substituí-la pela 1.0.0, com runners das classes configuradas offline durante o intervalo.[15] Não trate a troca como atualização transparente.

Cuidados e limites

A migração altera nome, chart Helm, repositório de imagem e repositório Packagecloud.[15] Registre as novas referências e valide a retomada da fila antes de encerrar a janela.

A versão corrige duas falhas graves em gRPC Go, CVE-2026-84304 e CVE-2026-84445.[15] Esse é um motivo adicional para revisar instalações anteriores, mas não substitui o planejamento de disponibilidade.

O trade-off é trocar capacidade permanentemente ligada por uma operação de provisionamento mais dinâmica. Minha recomendação é avaliar o resultado em espera, confiabilidade e custo total. Autoscaling resolve uma parte do problema quando os builds conseguem aproveitar a capacidade que aparece.

Fonte

[15] Fonte: InfoQ