Por que migrar para Runners Efêmeros no Azure Container Apps?
TL;DR: Este artigo detalha a implementação de self-hosted runners do GitHub Actions sobre Azure Container Apps, utilizando KEDA para escalonamento automático de zero a n. A solução elimina a necessidade de gerenciar VMs de longa duração, permitindo que a infraestrutura escale conforme a demanda real dos pipelines. A conclusão é que essa abordagem serverless é ideal para empresas que buscam reduzir custos operacionais, otimizar a segurança via Managed Identity e garantir agilidade na execução de tarefas paralelarizadas.
O uso de runners hospedados no GitHub atende a muitas demandas, mas conforme o volume de CI/CD cresce, equipes técnicas enfrentam limitações de custo, falta de controle sobre os ambientes de execução e latência no acesso a recursos privados (databases ou APIs internas). Enquanto a alternativa tradicional via self-hosted runners em Virtual Machines resolve o acesso, ela introduz um débito técnico severo: overhead de patching, custo de disponibilidade 24/7 e complexidade manual no scaling. A utilização de Azure Container Apps (ACA) com escalonamento por KEDA transforma esse modelo em algo puramente event-driven.
O que essa arquitetura entrega na prática?
A implementação proposta eleva a eficiência operacional do time de DevOps através de:
- Estratégia Pay-per-job: A infraestrutura escala para zero automaticamente quando não há jobs ativos, zerando o custo de ociosidade.
- Efemeridade: Cada job roda em seu próprio container isolado, garantindo um ambiente limpo e reduzindo conflitos entre diferentes execuções.
- Segurança Nativa: Integração total com o Azure Key Vault para armazenar segredos e uso de Managed Identity para autenticação, eliminando o gerenciamento de credenciais expostas no código.
Como funciona o fluxo de execução (Runtime Flow)
O sistema atua como um observador inteligente. Quando um desenvolvedor dispara um workflow, o KEDA monitora via API do GitHub a necessidade de novos runners. Se um job estiver no estado "Queued", o KEDA orquestra a criação do container no ACA. Após o término, o container é destruído. Essa automação minimiza a necessidade de intervenção do time de SRE em manutenções rotineiras de patching.
Pontos de Atenção Estratégicos
Ao adotar este modelo em escala, considere:
- Limites da GitHub API: A escolha entre Fine-grained PAT versus Classic PAT não é apenas estética. O uso de tokens com escopo amplo em toda a organização para polling do KEDA esgotará rapidamente os seus limites (5.000 requisições/hora). Opte sempre pelo, least-privilege.
- Networking: Em ambientes corporativos, a exposição pública de recursos é um risco. Certifique-se de configurar Private Endpoints em seu ACR e Key Vault se estiverem dentro de uma VNet privada.
- Segurança no Runner Group: Bloquear repositórios públicos em ambientes de alto risco é essencial, mas não esqueça de habilitar explicitamente a checkbox "Allow public repositories" caso sua organização exija suporte a projetos open-source ou públicos.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
