Introdução à Infraestrutura de Agente de Auto-Scaling
No mundo da integração contínua e entrega contínua (CI/CD), agentes de build (ou trabalhadores, runners, executores) são os pilares que compilam código, executam testes e implantam aplicações. À medida que as equipes de desenvolvimento crescem e a complexidade dos projetos aumenta, a demanda por esses agentes pode flutuar dramaticamente. Provisionar e desprovisionar agentes manualmente não só consome tempo, mas também leva a ineficiências: ou os agentes ficam ociosos, custando dinheiro, ou os builds se acumulam, desacelerando o desenvolvimento. É aqui que a infraestrutura de agente de auto-scaling se torna indispensável.
O auto-scaling permite que sua frota de agentes ajuste dinamicamente sua capacidade com base na demanda. Quando há um aumento nos pedidos de build, novos agentes são automaticamente criados. Quando a demanda diminui, agentes ociosos são encerrados, otimizando a utilização de recursos e custos. Este artigo fornece um início rápido prático para implementar auto-scaling em sua infraestrutura de agentes CI/CD, focando em padrões comuns e fornecendo exemplos que podem ser aplicados.
Por Que Auto-Scaling? Os Principais Benefícios
- Otimização de Custos: Pague apenas pelos recursos que você utiliza. Agentes ociosos na nuvem são um dreno direto no seu orçamento.
- Aumento do Throughput: Elimine filas de builds. Mais agentes significam mais builds simultâneos, levando a ciclos de feedback mais rápidos para os desenvolvedores.
- Aumento da Confiabilidade: Distribua cargas de trabalho entre múltiplos agentes, reduzindo o risco de um único ponto de falha.
- Redução de Sobrecargas Operacionais: Automatize o processo de escalonamento, liberando sua equipe de tarefas manuais de provisionamento.
- Elasticidade: lide suavemente com picos e vales imprevisíveis na demanda sem intervenção manual.
Arquiteturas Comuns de Auto-Scaling
Embora os detalhes variem de acordo com o sistema CI/CD e o provedor de nuvem, a maioria das infraestruturas de agentes de auto-scaling segue alguns padrões principais:
-
Grupos de Auto-Scaling de Provedor de Nuvem (ASG)
muitos sistemas CI/CD se integram diretamente com grupos de auto-scaling específicos de provedores de nuvem (por exemplo, AWS Auto Scaling Groups, Azure Virtual Machine Scale Sets, Google Cloud Managed Instance Groups). Você define uma imagem base (AMI, VHD, imagem de VM) para seu agente, especifica políticas de escalonamento (com base na utilização da CPU, comprimento da fila, métricas personalizadas), e o provedor de nuvem cuida da gestão do ciclo de vida.
Prós:
- Altamente integrado com a infraestrutura de nuvem.
- usa serviços de nuvem sólidos e testados em combate.
- Frequentemente o mais simples de configurar para escalonamento básico.
Contras:
- Pode ser menos granular no controle de tipos ou condições específicas de agentes.
- Atrelado a um único provedor de nuvem.
-
Integrações Específicas de Sistema CI/CD
Muitas plataformas modernas de CI/CD (por exemplo, Jenkins, GitLab CI, Buildkite, CircleCI, GitHub Actions) oferecem seus próprios mecanismos de auto-scaling ou integrações diretas com vários provedores de nuvem/orquestradores de contêineres. Esses normalmente envolvem um “controlador” ou “plugin” que monitora a fila de builds e solicita novos agentes conforme necessário.
Prós:
- Otimizado para as necessidades específicas da plataforma CI/CD.
- Frequentemente fornece lógica mais sofisticada para o provisionamento de agentes (por exemplo, rótulos específicos, requisitos de recursos).
- Pode suportar tipos heterogêneos de agentes.
Contras:
- Pode exigir mais configuração dentro do próprio sistema CI/CD.
- Às vezes pode ser menos performático do que o escalonamento nativo em nuvem para mudanças muito rápidas.
-
Orquestração de Contêineres (Kubernetes)
Usar Kubernetes como a infraestrutura subjacente para seus agentes está se tornando cada vez mais popular. Os agentes são executados como pods efêmeros, e o Cluster Autoscaler do Kubernetes (ou ferramentas semelhantes) pode escalar o pool de nós subjacente com base em solicitações pendentes de pods. Isso oferece imensa flexibilidade e eficiência de recursos.
Prós:
- Alta densidade e utilização de recursos (múltiplos agentes por nó).
- Portabilidade entre diferentes provedores de nuvem ou em local.
- Excelente para cargas de trabalho efêmeras baseadas em tarefas.
Contras:
- Maior complexidade de configuração inicial para o próprio Kubernetes.
- Exige contêinerizar seu ambiente de build.
Início Rápido: Exemplos Práticos
Vamos explorar exemplos práticos para configurar auto-scaling com duas ferramentas populares de CI/CD e uma abordagem centrada no Kubernetes.
Exemplo 1: Jenkins com Instâncias Spot EC2 da AWS
Jenkins, um servidor de automação de código aberto amplamente utilizado, tem excelente suporte para auto-scaling baseado em nuvem, particularmente com AWS EC2. usar Instâncias Spot pode reduzir significativamente os custos.
Pré-Requisitos:
- Uma instância Jenkins em funcionamento (preferencialmente em EC2 ou uma VM dedicada).
- Conta AWS com permissões IAM apropriadas (EC2, VPC, S3 se utilizando S3 para artefatos).
- Plugin EC2 do Jenkins instalado.
Etapas:
-
Prepare uma AMI EC2 para seu Agente Jenkins:
Lance uma instância EC2 (por exemplo,
t3.medium, Ubuntu LTS). Instale o Java Development Kit (JDK), quaisquer ferramentas de build necessárias (Maven, Gradle, npm, Docker CLI) e configure o agente Jenkins. Certifique-se de que o agente se conecta com sucesso ao seu controlador Jenkins manualmente primeiro. Uma vez configurado, crie uma AMI dessa instância. Esta AMI será o modelo para seus agentes de auto-scaling.# Exemplo de configuração no Ubuntu para um agente Java básico sudo apt update sudo apt install -y openjdk-11-jdk maven docker.io sudo usermod -aG docker jenkins # Supondo usuário jenkins para o agente sudo systemctl enable docker sudo systemctl start docker # Configuração manual do agente Jenkins (para testar AMI) # Baixe agent.jar do seu controlador Jenkins # java -jar agent.jar -jnlpUrl <your-jenkins-url>/computer/<agent-name>/slave-agent.jnlp -secret <secret> -workDir <path> # Após verificação, crie a AMI a partir desta instância EC2. -
Configure o Plugin EC2 do Jenkins:
Vá para o Painel do Jenkins -> Gerenciar Jenkins -> Gerenciar Nós e Nuvens -> Configurar Nuvens.
Adicione uma nova Nuvem -> Amazon EC2.
- Nome:
AWS-Spot-Agents - Credenciais Amazon EC2: Adicione seu AWS Access Key ID e Secret Access Key (ou use uma função IAM para o controlador Jenkins).
- Regiões EC2: Selecione sua região (por exemplo,
us-east-1). - Limite de Instância: Defina um limite razoável (por exemplo,
10) para evitar custos excessivos. - Par de Chave SSH: Selecione um par de chave existente para acesso SSH aos agentes.
- Adicionar uma nova AMI:
- ID da AMI: Insira o ID da AMI que você criou.
- Descrição:
Agente de Build Java Ubuntu - Rótulos:
java-agent linux(usado pelos trabalhos do Jenkins para selecionar agentes). - Tipo de Instância:
t3.medium(ou o apropriado). - Zona de Disponibilidade: Selecione sua AZ preferida ou deixe em branco para aleatória.
- Instância Spot: Marque esta caixa.
- Preço Máximo Spot: Defina um lance máximo (por exemplo,
0.10). - Root FS Remoto:
/home/jenkins - Usuário Remoto:
ubuntu(ou o usuário da sua AMI). - Uso:
Somente trabalhos de build com expressões de rótulo correspondendo a este nó. - Tempo de Término Ocioso: Defina uma duração (por exemplo,
10minutos) após a qual um agente ocioso será encerrado.
- Nome:
-
Teste o Auto-Scaling:
Crie um trabalho no Jenkins e configure-o para ser executado em um agente com o rótulo
java-agent. Acione vários builds simultaneamente. Você deve observar novas Instâncias Spot EC2 sendo criadas na sua console AWS e conectando-se ao Jenkins. Após a conclusão dos builds e os agentes se tornarem ociosos pelo tempo configurado, eles serão encerrados.
Exemplo 2: GitLab CI com GitLab Runner em Docker Machine
GitLab CI integra-se perfeitamente com GitLab Runner, que pode ser configurado para auto-scaling usando Docker Machine em vários provedores de nuvem.
Pré-Requisitos:
- Uma instância GitLab em funcionamento (SaaS ou hospedada por conta própria).
- Um servidor (por exemplo, EC2, VM) para hospedar o gerenciador do GitLab Runner.
- Docker e Docker Machine instalados no servidor do gerenciador do GitLab Runner.
- Credenciais do provedor de nuvem (por exemplo, AWS Access Key ID e Secret Access Key configurados no gerenciador do Runner).
Etapas:
-
Instale e Registre o GitLab Runner:
No seu servidor dedicado do gerenciador do Runner, instale o GitLab Runner:
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash sudo apt install gitlab-runner # Registre o runner (obtenha seu token de registro nas configurações do projeto/grupo GitLab) sudo gitlab-runner register --url "https://gitlab.com/" --registration-token "<your-registration-token>" --description "Docker Machine Auto-scaling Runner" --tag-list "docker,aws" --executor "docker+machine" -
Configure
config.tomlpara Docker Machine:Edite o arquivo de configuração do Runner, normalmente em
/etc/gitlab-runner/config.toml.Adicione/modifique a seção
[[runners]]e adicione uma seção[runners.docker]e[runners.machine].[[runners]] name = "Docker Machine Auto-scaling Runner" url = "https://gitlab.com/" token = "<seu-token-de-registro>" executor = "docker+machine" [runners.docker] tls_verify = false image = "ubuntu:latest" # Imagem padrão para builds privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] shm_size = 0 [runners.machine] IdleCount = 1 # Mantenha pelo menos uma máquina ociosa IdleTime = 600 # Termine máquinas ociosas após 10 minutos MaxBuilds = 100 # Termine a máquina após 100 builds MachineDriver = "amazonec2" MachineName = "gitlab-runner-%s" MachineOptions = [ "amazonec2-instance-type=t3.medium", "amazonec2-ami=ami-0abcdef1234567890", # Use uma AMI base com Docker pré-instalado "amazonec2-region=us-east-1", "amazonec2-vpc-id=vpc-0123456789abcdef0", "amazonec2-subnet-id=subnet-0abcdef1234567890", "amazonec2-security-group=gitlab-runner-sg", "amazonec2-use-private-address=true", "amazonec2-tags=gitlab-runner-managed,project:my-project" ] # Opcional: Configure Docker Machine para Instâncias Spot # MachineOptions = [ # ..., # "amazonec2-request-spot-instance=true", # "amazonec2-spot-price=0.05", # ]Nota sobre AMI: Para Docker Machine, sua AMI precisa ter Docker pré-instalado e configurado para iniciar na inicialização. O Docker Machine irá usar essa AMI para provisionar novas instâncias.
-
Reiniciar GitLab Runner:
sudo gitlab-runner restart -
Testar Auto-Scaling:
Envie algumas alterações para um repositório GitLab que dispare um pipeline CI. Dispare múltiplos pipelines simultaneamente. Você deve ver novas instâncias EC2 sendo criadas (ou VMs na sua nuvem escolhida) e executando seus jobs. Após um período de inatividade, elas serão terminadas.
Exemplo 3: Kubernetes com Cluster Autoscaler
Para cargas de trabalho altamente dinâmicas e conteinerizadas, o Kubernetes oferece uma poderosa solução de auto-scaling. Aqui, seus agentes CI/CD rodam como pods, e o Cluster Autoscaler do Kubernetes ajusta o pool de nós subjacente.
Pré-requisitos:
- Um cluster Kubernetes em funcionamento (por exemplo, EKS, AKS, GKE ou autogerenciado).
kubectlconfigurado para acessar seu cluster.- Um sistema CI/CD capaz de implantar jobs como pods do Kubernetes (por exemplo, plugin Kubernetes do Jenkins, executor Kubernetes do GitLab CI, Tekton, Argo Workflows).
Passos (Conceitual para o Executor Kubernetes do GitLab CI):
-
Implantar o Cluster Autoscaler:
Siga a documentação para implantar o Cluster Autoscaler específico para seu provedor de nuvem (por exemplo, Cluster Autoscaler do EKS, Cluster Autoscaler do GKE). Este componente monitora pods pendentes e ajusta os grupos de nós para cima ou para baixo.
Exemplo (EKS – simplificado, consulte a documentação oficial):
# Crie uma Política IAM para o Cluster Autoscaler # Crie uma Função IAM e anexe a política # Crie uma Conta de Serviço e associe-a à Função IAM # Implante a implantação do Cluster Autoscaler usando Helm ou YAML # Exemplo de comando Helm para o Cluster Autoscaler do EKS helm upgrade --install cluster-autoscaler stable/cluster-autoscaler \ --namespace kube-system \ --set autoDiscovery.clusterName=<seu-nome-do-cluster> \ --set rbac.create=true \ --set serviceAccount.create=true \ --set serviceAccount.name=cluster-autoscaler \ --set image.repository=k8s.gcr.io/cluster-autoscaler \ --set image.tag=v1.22.0 # Combine com sua versão K8s -
Configurar Grupos de Nós Dinâmicos/Pooling de Nós:
Certifique-se de que seu cluster Kubernetes possui grupos de nós/pools configurados para auto-scaling. Defina tamanhos mínimos e máximos para esses grupos.
Exemplo (GKE):
gcloud container node-pools create ci-agents-pool \ --cluster <seu-nome-do-cluster> \ --machine-type=e2-medium \ --num-nodes=0 \ --min-nodes=0 \ --max-nodes=10 \ --enable-autoscaling \ --region=<sua-região> -
Configurar o Sistema CI/CD para usar o Executor Kubernetes:
Para GitLab CI, registre um Runner com o executor Kubernetes. Este executor irá iniciar um novo pod para cada job.
sudo gitlab-runner register --url "https://gitlab.com/" --registration-token "<seu-token-de-registro>" --description "Kubernetes CI Runner" --tag-list "kubernetes,docker" --executor "kubernetes"Edite
/etc/gitlab-runner/config.toml:[[runners]] name = "Kubernetes CI Runner" url = "https://gitlab.com/" token = "<seu-token-de-registro>" executor = "kubernetes" [runners.kubernetes] host = "" # Deixe vazio para configuração no cluster namespace = "gitlab-runner" cpu_limit = "500m" memory_limit = "1Gi" image = "docker:20.10.16-dind-rootless" # Ou sua imagem base preferida pull_policy = ["if-not-present", "always"] # Opcional: Configure uma imagem base para seus builds # helper_image = "gitlab/gitlab-runner-helper:latest" -
Testar Auto-Scaling:
Dispare múltiplos pipelines CI/CD. Observe novos pods sendo criados no namespace
gitlab-runner. Se não houver nós suficientes, o Cluster Autoscaler provisionará novos nós no seuci-agents-pool. Uma vez que os jobs sejam concluídos, os pods são terminados e os nós ociosos são escalonados para baixo.
Melhores Práticas para Agentes de Auto-Scaling
- Use Imagens de Agente Imutáveis: Construa suas imagens de agente (AMIs, imagens Docker) com todas as ferramentas necessárias pré-instaladas. Isso garante consistência e acelera os tempos de inicialização do agente.
- Use Instâncias Spot/Preemptíveis: Para builds não críticos ou tolerantes a falhas, usar instâncias spot pode reduzir dramaticamente os custos. Implemente lógica de re-tentativa em seu CI/CD caso os jobs possam ser interrompidos.
- Configurar Redução Agressiva: Para otimizar custos, configure os agentes para terminar rapidamente após ficarem ociosos.
- Defina Limites de Instância: Sempre defina limites máximos para seus grupos de auto-scaling ou pools de nós para evitar excessos inesperados de custo.
- Monitore Sua Infraestrutura: Fique atento às filas de build, utilização de agentes e custos de nuvem. Ajuste as políticas de escalonamento conforme necessário.
- Otimize o Tempo de Inicialização do Agente: Minimize o tempo que leva para um agente ficar pronto. Isso inclui otimizar o tamanho da imagem, usar scripts cloud-init de forma eficiente e armazenar em cache as dependências.
- Use Rótulos/Tags para Granularidade: Use rótulos (Jenkins, Kubernetes) ou tags (GitLab) para direcionar jobs específicos para agentes com as capacidades certas (por exemplo,
java-17,node-lts,gpu-enabled). - Considere Pools Quentes: Para cenários onde a escalabilidade rápida é crítica, mantenha um pequeno "piscina quente" de agentes ociosos prontos para pegar jobs instantaneamente, permitindo ainda mais escalonamento sob demanda.
Conclusão
A infraestrutura de agentes de auto-scaling não é mais um luxo, mas uma necessidade para pipelines CI/CD modernos. Ao ajustar dinamicamente sua capacidade de agentes, você pode alcançar economias significativas de custos, melhorar a produtividade dos desenvolvedores por meio de feedback mais rápido e construir um sistema de entrega mais resiliente e elástico. Seja escolhendo grupos de auto-scaling do provedor de nuvem, integrações específicas de CI/CD ou uma abordagem centrada no Kubernetes, os princípios permanecem os mesmos: automatizar, otimizar e escalar para atender à demanda. Comece com uma configuração simples, monitorize seu desempenho e refine iterativamente sua estratégia de auto-scaling para combinar perfeitamente com as necessidades de sua equipe.
🕒 Published: