Dando mais um passo em relação a como configurar uma CI completa, neste artigo vamos comparar os principais tipos de Runners e quais as vantagens e desvantagens. Caso não tenha visto o primeiro artigo, recomendamos: Como Criar uma Integração Contínua com GitLab em 5 Passos Simples.
Antes de iniciar a explicação vale alguns destaques, esse artigo é especialmente útil para quem deseja ter os próprios runners, caso use os fornecidos pelo gitlab pode ir para o próximo artigo, além disso até este momento não temos restrição de licença para usar os runners.
Porque usar o runner local em vez de usar o fornecido do gitlab?
Além do motivo financeiro, que pode ser consultado em mais detalhes no gitlab.com, que limita os minutos de execução das suas CIs caso use o gitlab.com, também temos também a restrição de redes: Se você tiver algum gerenciador de artefatos e dependências instalado na sua infra, por padrão, se esse serviço não for acessível publicamente, os runners do gitlab.com não vão conseguir acessar nada da sua rede. O mesmo não acontece se você tiver o seu próprio runner. Detalhe que isso se aplica a quem usa o gitlab.com, já que se você fez a instalação do seu gitlab você já não conta com runners do gitlab.
Principais Diferenças
Para não falar de todos os tipos individualmente vamos separar eles em 2 grandes grupos e a partir deles fazer os comparativos.
Instalação manual de dependências
Temos então o tipo que toda dependência do seu projeto precisa ter instalado na máquina e não só isso, como também temos que manter todas essas dependências compatíveis entre si. Com isso, caso você tenha um projeto Java 21 e outro Java 11 vamos ter 2 opções: ou ter 2 runners um com Java 21 e outro com 11 ou em uma máquina devemos ter ambos, com isso nossa manutenção tem sua complexidade elevada a depender da variedade de projetos e dependências e quantas máquinas você tem no seu parque de runners.
Instalação automática de dependências
O oposto do cenário anterior é colocar a responsabilidade de baixar as dependências dos projetos pela CI do próprio projeto. Neste cenário temos runners “limpos”, isso é, sem dependências dos projetos que vão ser baixados das imagens prontas que cada projeto usar, o que simplifica e muito a manutenção dos runners, uma vez que o número de projetos não vai afetar a complexidade dos runners.
Executor SSH e Shell
Resumo: Temos dois runners simples de instalar e manter porém entre os 2 o gitlab não recomenda o SSH por ter um suporte inferior ao shell, além disso ambos vão precisar ter as dependências previamente instaladas e em questão de segurança cada execução do job poderá acessar todo o sistema de arquivos.
Prós:
- Acesso fácil ao log e formas de debugar
- Clone reaproveitado entre execuções
Contras:
- Cada execução deixa “Lixo” no runners
- Acesso irrestrito ao sistema de arquivos
- Sem suporte a execução de jobs simultâneos por projetos
- Requer instalação prévia das dependências dos projetos
Executor Docker, Docker Maquina e Kubernetes
Resumo: Aqui estamos falando do tipo que não precisa ter nada além do docker ou k8s em sua máquina/cluster, ou seja, todas as dependências vem na imagem usada pelo projeto na CI.
Também temos a questão de segurança onde cada job é isolado entre si e só consegue acessar seu workdir próprio. E Por ultimo, a principal diferença entre docker para docker maquina e k8s é que o segundo tipo permite escabilidade para subir máquinas.
Prós:
- Ambiente de construção limpo para cada construção
- Acesso ao sistema de arquivos do executor protegido
- Migração do JOB entre máquinas executoras
- Suporte de configuração para compilações simultâneas
- Acesso fácil ao log
Contras:
- Acesso difícil a formas de debugar
Conclusão
Já conhecia todos esses tipos de executores? Em nossa opinião os runners docker maquina, k8s e docker são os melhores tipos para a maioria dos cenários em que não se precisa de alguma dependência que não consiga rodar nesses ambientes em seu cenário você usa outro tipo? Quer saber mais? A gitlab oferece uma documentação completa, caso tenha alguma dúvida não deixe de comentar.
