Você sabia que muitas empresas desperdiçam dinheiro mantendo instâncias do Jenkins ociosas? Se sua equipe usa o Jenkins só de vez em quando para implantações, pull requests ou CI/CD pipelines, é bem provável que você esteja pagando a mais por recursos de computação. Mas calma, existe uma solução!
Neste artigo, vamos mostrar como usar uma solução serverless para desligar o Jenkins quando ele não estiver sendo usado e ligá-lo automaticamente quando precisar fazer um novo build. Vamos nessa?
Como Funciona a Mágica da Economia de Custos no Jenkins
A solução que vamos apresentar usa duas funções AWS Lambda. A primeira função, “Parar Jenkins“, fica de olho na atividade e desliga a instância EC2 quando ela está ociosa. Já a segunda função, “Iniciar Jenkins“, liga a instância quando um webhook do GitHub dispara um build e manda o pedido para o Jenkins. Usando a instância EC2 só durante os builds, você elimina os gastos com computação ociosa.
Atenção: essa abordagem pode atrapalhar tarefas agendadas no Jenkins, como builds noturnos. Certifique-se de que sua instância só funcione sob demanda, através de webhook triggers, e que não dependa de agendamentos.
Vale lembrar que este guia usa o GitHub plugin para disparar builds quando há push events no GitHub. Se sua configuração for diferente, ajuste o código de acordo.
Desligando o Jenkins: O Fluxo de Trabalho
A função “Parar Jenkins” roda periodicamente, usando o event bridge scheduler para verificar a cada 5 minutos se o servidor Jenkins está ocioso. Se estiver, a função Lambda desliga o servidor. Para saber se o Jenkins está ocioso, usamos a Jenkins computer api /computer/api/json, que fornece informações sobre o status dos computadores conectados ao Jenkins.
Confira abaixo o código Python para a função “Parar Jenkins“. Ele usa a biblioteca boto3 para interagir com a AWS, e as bibliotecas urllib e json para verificar o status do Jenkins.
O código verifica se a instância está parada. Se não estiver, ele usa a API do Jenkins para verificar se há builds rodando. Se o Jenkins estiver ocioso, o código para a instância EC2.
O código também inclui tratamento de erros, para garantir que a função Lambda lide com qualquer problema que possa aparecer.
Iniciando o Jenkins: O Fluxo de Trabalho
Quando um webhook do GitHub é disparado, a função Lambda “Iniciar Jenkins” verifica se a instância está rodando. Se estiver parada, ela liga a instância e espera até que ela esteja saudável. Assim que o Jenkins está ativo, a função Lambda envia o webhook payload para /github-webhook/.
Veja abaixo o código Python para a função “Iniciar Jenkins“. Ele usa a biblioteca boto3 para interagir com a AWS, e as bibliotecas time, urllib e json para controlar o status da instância EC2 e do Jenkins.
O código verifica o payload, verifica se a instância está parada, liga a instância EC2 se necessário, espera até que o Jenkins esteja pronto e dispara o build.
Assim como na função “Parar Jenkins“, o código também inclui tratamento de erros para garantir que a função Lambda lide com qualquer problema.
Principais Vantagens da Economia de Custos no Jenkins
Usar essa solução traz várias vantagens. A primeira é a economia de custos: você paga só pelo tempo de build ativo. Por exemplo, se você usa o Jenkins por 2 horas por dia para builds, seu tempo de atividade mensal totaliza 60 horas (contra 720 horas de operação 24/7), gerando uma economia de mais de 90%. Além disso, a solução é toda automatizada, sem necessidade de intervenção manual.
Se você precisar usar o servidor Jenkins por mais tempo (por exemplo, para debugging), pode desativar temporariamente o EventBridge scheduler para evitar desligamentos automáticos, ou habilitar a proteção contra parada na instância EC2 até terminar o debugging. Isso garante acesso ininterrupto, mantendo a otimização de custos como comportamento padrão.
Já pensou em usar essa solução no seu ambiente? Compartilhe suas ideias na seção de comentários!
Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.
Via Dev.to