Rendimiento y Límites

Vamos a comenzar nuestro pipeline con la imagen node:22 y hacer algunas pruebas. Agrega el .gitlab-ci.yml en la raíz del proyecto. Si no quieres usar el runner específico que preparaste, entonces elimina el tag.

default:
  tags:
    - general # Ejecutando en nuestro runner..
test:
  image: node:22
  script:
    - node --version
    - npm --version

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

Y tendremos este log en el 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

Descargó la imagen node:22 al host, pues no existía en el sistema.

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

¿Realmente necesitamos 1.1GB de imagen? Claro que no, vamos a resolver esto cambiando a una imagen más pequeña y directa al punto.

Imagen	Tamaño	Observación
node:22	~1.1GB	Completa, pesada, lenta.
node:22-slim	~200MB	Mejor opción para el 90% de los proyectos.
node:22-alpine	~60MB	Muy ligera, pero pueden faltar librerías (ej: glibc, python).

Vamos a optar por node:22-slim para comenzar y al final de todo, podemos cambiar a node:22-alpine para afinar el pipeline.

Consejos

1. Busca imágenes oficiales en dockerhub en lugar de utilizar imágenes de la comunidad para evitar problemas de seguridad. Cualquiera puede crear una imagen y publicar lo que quiera.
2. Utilizar imágenes oficiales tiene menos riesgos de ser eliminadas de dockerhub.
3. Evita imágenes grandes para ganar rendimiento y gastar menos recursos. Es necesario buscar las imágenes más utilizadas según cada tipo de proyecto. Generalmente siempre reducen utilizando como base alpine.
4. Si vas a utilizar algo no oficial, conoce el proyecto y la confiabilidad de este.
5. Revisa la documentación de la herramienta o framework que estás utilizando que generalmente indican imágenes que funcionan bien.
6. Dockerhub tiene limitaciones de pull, por eso es bueno que tengas esas imágenes en algún lugar que sea solo tuyo para eliminar ese límite que puede parar tu pipeline.
   • Rate limit de Docker Hub: si no estás logueado (anónimo), son 100 pulls por 6 horas por IP. Si estás logueado (cuenta gratuita), son 200 pulls por 6 horas.
   • Si superas ese límite, vas a empezar a recibir error 429 Too Many Requests.
   • Rendimiento: cada pull descarga la imagen completa (si no está cacheada en el runner), lo que es lento y gasta ancho de banda.
   • Confiabilidad: si Docker Hub tiene inestabilidad (sucede a veces), tu pipeline puede fallar sin ni siquiera ser culpa tuya.

Sí... así es como ganan dinero.

¿Qué podemos hacer? Avisar a gitlab-runner que solo descargue si no tiene la imagen, esto ya disminuirá drásticamente. En el archivo config.toml de gitlab-runner podemos pasar esta configuración.

  [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"  # <<< agregado aquí

Con la nueva imagen que vamos a utilizar (node:22-slim) vamos a probar, incluso el tiempo.

default:
  tags:
    - general # Ejecutando en nuestro runner..
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

Límite de Namespace

GitLab te da 10 GB por namespace (incluye repositorios + artifacts + container registry).

Más adelante veremos más sobre artefactos y cómo se generan y dependiendo del plan que tengas en GitLab, no vale la pena guardar artefactos por mucho tiempo siendo una buena idea mantener solo los artefactos de la rama main/master por más tiempo.

Container Images podemos guardar fuera de GitLab, generalmente en la nube es muy barato así que vale la pena usar, o utilizar un registry propio como Harbor, por ejemplo.

Guardar reportes de tests es mucho mejor que se haga en el propio GitLab para no perder la integración con las herramientas de GitLab, veremos sobre reportes más adelante.