Performance e Limites

Vamos começar nossa pipeline com a imagem node:22 e fazer uns testes. Adicione o .gitlab-ci.yml na raiz do projeto. Se não quiser usar o runner específico que você preparou, então remova a tag.

default:
  tags:
    - general # Rodando no nosso runner..
test:
  image: node:22
  script:
    - node --version
    - npm --version

❯ git add .gitlab-ci.yml  
❯ git cm "add ci"  
❯ git push origin pipe/base  

E teremos esse log no job.

Running with gitlab-runner 17.11.0 (0f67ff19)
  on general-debian jyvyfkmfg, system ID: r_szdZCOX2meST
Preparing the "docker" executor
00:57
Using Docker executor with image node:22 ...
Using helper image:  registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v17.11.0
Authenticating with credentials from job payload (GitLab Registry)
Pulling docker image registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v17.11.0 ...
Using docker image sha256:c7faacb47f4dbac2ce2a8181978106fdd2632d6abf2979bd22cb2fc038af0067 for registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper:x86_64-v17.11.0 with digest registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper@sha256:02f7f7d9d1d9cadbcb359b03d51bb32558dd147b00bf77a98d6c1673397616b0 ...
Pulling docker image node:22 ...
Using docker image sha256:c5602f2ebc084a8e7e1fb08f993c842c4667f50fd93af7da35a40096f0c0ee11 for node:22 with digest node@sha256:473b4362b26d05e157f8470a1f0686cab6a62d1bd2e59774079ddf6fecd8e37e ...
Preparing environment
00:01
Running on runner-jyvyfkmfg-project-69186599-concurrent-0 via 1d8224d47375...
Getting source from Git repository
00:03
Fetching changes with git depth set to 20...
Initialized empty Git repository in /builds/puziol/learn-gitlab-app/.git/
Created fresh repository.
Checking out 7a54fc17 as detached HEAD (ref is pipe/base)...
Skipping Git submodules setup
Executing "step_script" stage of the job script
00:01
Using docker image sha256:c5602f2ebc084a8e7e1fb08f993c842c4667f50fd93af7da35a40096f0c0ee11 for node:22 with digest node@sha256:473b4362b26d05e157f8470a1f0686cab6a62d1bd2e59774079ddf6fecd8e37e ...
$ node --version
v22.15.0
$ npm --version
10.9.2
Cleaning up project directory and file based variables
00:01
Job succeeded

Ele baixou a imagem node:22 para o host, pois não existia no sistema.

 docker images | grep node
node                                                                22                c5602f2ebc08   4 days ago      1.12GB

Precisamos mesmo de 1.1Gb de imagem? Claro que não, vamos resolver isso mudando para uma imagem menor e direto ao ponto.

Imagem	Tamanho	Observação
node:22	~1.1GB	Cheia, completa, lenta.
node:22-slim	~200MB	Melhor escolha para 90% dos projetos.
node:22-alpine	~60MB	Muito leve, mas pode faltar lib (ex: glibc, python).

Vamos optar por node:22-slim para começar e ao final de tudo, podemos mudar para node:22-alpine para afinar o pipeline.

Dicas

1. Busque por imagens oficiais no dockerhub ao invés de utilizar imagens da comunidade para evitar problemas de segurança. Qualquer um pode criar uma imagem e publicar com o que bem entender.
2. Utilizar imagens oficiais correm menos riscos de serem removidas do dockerhub.
3. Evite imagens grandes para ganhar performance e gastar menos recurso. É necessário procurar as imagens mais utilizadas de acordo com cada tipo de projeto. Geralmente sempre reduzem utilizando como base o alpine.
4. Se for utilizar algo não oficial, conheça o projeto e a confiabilidade deste.
5. Confira a documentação da ferramenta ou framework que esta utilizando que geralmente indicam imagens que funcionam bem.
6. O dockerhub possui limitações de pull, por isso é bom que você tenha essas imagens em algum lugar que é só seu para remover esse limite que pode parar sua pipeline.
   • Rate limit do Docker Hub: se você não estiver logado (anônimo), é 100 pulls por 6 horas por IP. Se estiver logado (free account), é 200 pulls por 6 horas.
   • Se estourar esse limite, você vai começar a tomar erro 429 Too Many Requests.
   • Performance: cada pull baixa a imagem inteira (se não tiver cacheado no runner), o que é lento e gasta banda.
   • Confiabilidade: se o Docker Hub tiver instabilidade (rola às vezes), tua pipeline pode falhar sem nem ser culpa sua.

É... é assim que eles ganham dinheiro.

O que podemos fazer? Avisar para o gitlab-runner somente baixar caso não tenha a imagem, isso já irá diminuir drasticamente. No arquivo config.toml do gitlab-runner podemos passar essa configuração.

  [runners.docker]
    tls_verify = false
    image = "debian:bullseye-slim"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    network_mtu = 0
    pull_policy = "if-not-present"  # <<< adicionado aqui

Com a nova imagem que vamos utilizar (node:22-slim) vamos testar, inclusive o tempo.

default:
  tags:
    - general # Rodando no nosso runer..
test:
  image: node:22-slim
  script:
    - node --version
    - npm --version

❯ git add .gitlab-ci.yml  
❯ git cm "change image to slim"  
❯ git push origin pipe/base  

Limite de Namespace

O GitLab te dá 10 GB por namespace (inclui repositórios + artifacts + container registry).

Mais pra frente veremos mais sobre artefatos e como eles são gerados e dependendo do plano que tiver no GitLab , não vale a pena guardar artefatos por muito tempo sendo uma boa idéia manter só os artefatos da branch main/master por mais tempo.

Container Images podemos guardar fora do GitLab, geralmente na cloud é barato demais então vale a pena usar, ou utilizar um registry seu como o Harbor por exemplo.

Guardar reports de testes é muito melhor que seja feito no próprio GitLab para não perder a integração com as ferramentas do GitLab, veremos sobre reports mais pra frente.