Jenkins em escala

Disclaimer Muito desse material foi retirado da documentação oficial e traduzido livremente, veja a documentação oficial aqui.
A motivação de fazer isso e por ser um material muito rico que não se encontra em português.

À medida que uma organização amadurece do ponto de vista de entrega contínua, seus requisitos de Jenkins também crescem. Esse crescimento é frequentemente refletido na arquitetura Jenkins, seja um crescimento "vertical" ou "horizontal".

O crescimento vertical é quando a carga em uma carga do controlador Jenkins é aumentada por ter mais trabalhos configurados ou orquestrar compilações mais frequentes. Isso também pode significar que mais equipes dependem desse controlador.

O crescimento horizontal é a criação de controladores Jenkins adicionais para acomodar novas equipes ou projetos, em vez de adicionar novas equipes ou projetos a um controlador existente.

Existem armadilhas potenciais associadas a cada abordagem para dimensionar o Jenkins, mas com um planejamento cuidadoso, muitas delas podem ser evitadas ou gerenciadas. Aqui estão algumas coisas a serem consideradas ao escolher uma estratégia para dimensionar as instâncias do Jenkins da sua organização:

• Você tem os recursos para executar um sistema de compilação distribuído?
• Você tem os recursos para manter vários controladores?
• Quão críticos são os projetos de cada equipe?
• Qual é a importância de um tempo de inicialização rápido para sua instância do Jenkins?

Arquitetura de builds distribuídos

Um controlador Jenkins pode operar sozinho gerenciando o ambiente de compilação e executando as compilações com seus próprios executores e recursos. Se você ficar com essa configuração "independente", provavelmente ficará sem recursos quando o número ou a carga de seus projetos aumentarem.

Para voltar a funcionar com sua infraestrutura Jenkins, você precisará aprimorar o controlador (aumentando a memória, o número de CPUs, etc). O tempo que leva para manter e atualizar a máquina, o controlador junto com todo o ambiente de compilação ficará inativo, os trabalhos serão interrompidos e toda a infraestrutura do Jenkins ficará inutilizável.

Escalar o Jenkins em tal cenário seria extremamente doloroso e introduziria muitos períodos "ociosos" em que todos os recursos atribuídos ao seu ambiente de compilação são inúteis.

Além disso, a execução de trabalhos no controlador apresenta um problema de "segurança": o usuário "jenkins" que o Jenkins usa para executar os trabalhos teria permissões totais em todos os recursos do Jenkins no controlador. Isso significa que, com um simples script, um usuário mal-intencionado pode ter acesso direto a informações privadas cuja integridade e privacidade não poderiam ser, assim, garantidas. Consulte Distributed Builds no capítulo Protegendo Jenkins para obter mais informações.

Por todos esses motivos, o Jenkins oferece suporte a agentes, onde a carga de trabalho dos projetos de construção é delegada a vários agentes.

Um agente é uma máquina configurada para descarregar projetos do controlador. O método com o qual as compilações são agendadas depende da configuração dada a cada projeto. Por exemplo, alguns projetos podem ser configurados para "restringir onde este projeto é executado", o que vincula o projeto a um agente específico ou a um conjunto de agentes rotulados. Outros projetos que omitem essa configuração selecionam um agente do pool disponível no Jenkins.

Em um ambiente de compilação distribuído, o controlador Jenkins usará seus recursos para lidar apenas com solicitações HTTP e gerenciar o ambiente de compilação. A execução real das compilações será delegada aos agentes. Com essa configuração é possível dimensionar horizontalmente uma arquitetura, o que permite que uma única instalação do Jenkins hóspede um grande número de projetos e ambientes de construção.

Escalabilidade do Jenkins

Ao usar o servidor Jenkins autônomo, você não precisa se preocupar com vários servidores e nós. No entanto, o problema com essa configuração é que seu servidor pode ficar sobrecarregado com vários trabalhos em execução ao mesmo tempo. Existem maneiras de resolver esse problema aumentando o número de executores, mas logo você acaba atingindo um limite de desempenho.

Para superar esse problema, você pode transferir alguns dos trabalhos para diferentes máquinas chamadas de agentes Jenkins.

A escalabilidade é uma medida que mostra a capacidade de um sistema de expandir seus recursos para lidar com carga adicional. Um dos lados mais fortes do Jenkins é que ele possui um recurso de dimensionamento pronto para uso. O escalonamento de Jenkins é baseado no modelo de controlador/agentes, onde você tem várias instâncias de agente e uma instância principal de Jenkins chamada de controlador que é responsável principalmente por distribuir tarefas entre os agentes. Os agentes Jenkins executam um pequeno programa que se comunica com o controlador Jenkins para verificar se há algum trabalho que possa ser executado. Quando o Jenkins encontra um trabalho agendado, ele transfere a compilação para o agente.

Escalando Jenkins no Kubernetes

Dando um passo adiante, executando um orquestrador de contêiner como o Kubernetes, você pode fazer com que o Jenkins faça coisas mais inteligentes. O controlador Jenkins é responsável pela configuração de hospedagem e distribuição de trabalhos para vários agentes. No entanto, você não precisa que os agentes sejam preexistentes, eles podem ser criados na hora, como quando são necessários.

Vantagens de dimensionar Jenkins no Kubernetes

A recuperação automática é possível
Se sua compilação ou seu agente for corrompido, você não precisa mais se preocupar - o Jenkins removerá a instância não íntegra e criará uma nova.

Executar compilações em paralelo
Você não precisa mais planejar os executores e limitá-los; em vez disso, o Jenkins ativará uma instância do agente e executará sua compilação nela.

Distribuição de carga uniforme
O Kubernetes gerencia bem as cargas e garante que seus agentes Jenkins sejam ativados no melhor servidor disponível, o que torna suas compilações mais rápidas e eficientes.

Motivação dessa série

1. Tivemos semanas sombrias com Github tendo várias falhas e ficando fora de serviço u.u
2. Pessoas justificando que preferem Github pois Jankins não escala. Jura?
3. Vi em poucas empresas times usando Jenkins realmente em escala. Empresas como Itaú e Creditas em geral usavam um mega Jenkins que eram gargalo para todas as equipes de desenvolvimento. Talvez não seja tão difundido como trabalhar com Jenkins em escala.

Então vamos sair do as is para o to be abaixo:

Vlw flw