Hosting de GitLab Runner, en una máquina que es suya
Un runner autogestionado en Praga o Covilhã con todo el disco para él, de modo que la caché de capas de Docker sigue ahí en la segunda pipeline del día y la factura no se mueve cuando lo hace la compilación.
Para quién es
Un equipo que compra minutos de cómputo
La suite de pruebas creció, la pipeline se alargó y la factura subió - y la única palanca que ofrece el plan es comprar más de exactamente los mismos minutos.
Una pipeline que quiere la misma máquina dos veces
Cada trabajo arranca con el disco vacío. La imagen base se descarga otra vez, las dependencias se traen otra vez, y subir la caché tarda más que el paso que pretendía ahorrar.
Un repositorio bajo una norma de residencia
El código, los artefactos y las claves de despliegue pasan todos por el runner, y "una flota compartida, en algún sitio" es la respuesta que su auditor sigue rodeando en rojo.
Lo que le devuelve un runner autogestionado
- Una caché de capas de Docker caliente en NVMe local, para que la segunda pipeline del día empiece donde terminó la primera en lugar de con el disco vacío.
- Cualquier executor que quiera - docker, shell, docker-autoscaler, instance o kubernetes - elegido por runner y no asignado por un plan.
- Su propia concurrencia, puesta como un número en config.toml en lugar de comprada como el siguiente escalón.
- Modo privilegiado cuando de verdad necesita Docker-in-Docker, algo que ninguna flota compartida le dará jamás.
- Una IPv4 saliente estática de AS204057, para que un destino de despliegue, un espejo de paquetes o el cortafuegos de una base de datos pueda autorizar el runner por dirección.
- Lo que la compilación realmente necesita en el host: una cadena de herramientas antigua, un SDK con licencia o un conjunto de datos de prueba que nadie quiere descargar una vez por trabajo.
Dimensionado por lo que la pipeline hace de verdad
GitLab no publica requisitos de hardware para el runner en sí, y no es un descuido: el proceso del runner es pequeño y la compilación no lo es, así que el número que importa es el trabajo. Parta del trabajo más pesado que ejecuta hoy, multiplique por la concurrencia que quiere y sea generoso con el disco - la caché de capas y el espacio de trabajo son lo que lo llena, y un disco lleno hace fallar una pipeline de una forma que parece un test roto. Hay algo que un host mensual fijo no hace: desaparecer en una semana tranquila. Los minutos alojados no cuestan nada cuando nadie sube código, y esto cuesta lo mismo. Sale a cuenta a partir del punto en que la pipeline se ejecuta casi todos los días.
Cómo instalar GitLab Runner en un host nuevo
Debian o Ubuntu, desde un servidor limpio, en el orden que documenta GitLab. Todo lo de abajo es su secuencia, no la nuestra.
-
Añadir el repositorio oficial de paquetes
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" -o script.deb.sh less script.deb.sh sudo bash script.deb.shGitLab distribuye el repositorio como un script de instalación y pide que lo lea antes de ejecutarlo, y por eso sus propias instrucciones lo descargan primero en lugar de canalizarlo directamente a una shell.
-
Instalar el runner
sudo apt install gitlab-runnerEl paquete crea un usuario de sistema gitlab-runner cuyo directorio personal se crea vacío, sin ficheros de esqueleto. Para fijar una versión, instale gitlab-runner y gitlab-runner-helper-images juntos en la misma versión - desde 17.7.1 van en pareja, y nombrar solo uno falla con un error de dependencias.
-
Instalar Docker, si los trabajos se ejecutan en contenedores
sudo apt install docker.io sudo systemctl enable --now dockerEl executor docker habla con un Docker Engine local por la API v1.25, así que el demonio tiene que estar en el propio host del runner. El paquete de la distribución basta para empezar; el repositorio propio de Docker lleva las versiones más nuevas si alguna compilación las necesita.
-
Registrar el runner
sudo gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --token "$RUNNER_TOKEN" \ --executor "docker" \ --docker-image alpine:latest \ --docker-pull-policy "if-not-present" \ --description "docker-runner"Cree primero el runner en GitLab, en Settings, luego CI/CD, luego Runners, y le devolverá un token de autenticación que empieza por glrt- y que va en --token. Las etiquetas del trabajo y la opción de trabajos sin etiqueta se ponen en ese mismo formulario: con tokens de autenticación pertenecen al runner, no al comando register. El flujo anterior con --registration-token está obsoleto y previsto para eliminarse en GitLab 20.0.
-
Fijar la concurrencia y arrancarlo
sudo sed -i "s/^concurrent = .*/concurrent = 4/" /etc/gitlab-runner/config.toml sudo gitlab-runner restart sudo gitlab-runner statusconfig.toml vive en /etc/gitlab-runner cuando el runner se ejecuta como root. concurrent es un techo para todos los runners registrados en este host, no un ajuste por runner, y cada runner puede llevar por debajo un límite propio más pequeño.
-
Comprobarlo con un trabajo
stages: [test] smoke: stage: test tags: [docker-runner] script: - cat /etc/os-release - echo "built on $CI_RUNNER_DESCRIPTION"Haga commit de eso como .gitlab-ci.yml, suba los cambios y el trabajo debería aterrizar en su host en unos segundos. Si se queda en cola, las etiquetas no coinciden con las que puso en la interfaz, o el runner está bloqueado a otro proyecto.
Comprobado con la documentación oficial el 2026-08-15 — leer la fuente
Lo que no somos
- No somos GitLab. GitLab, GitLab CI/CD y GitLab Runner son suyos, y nada de esta página cuenta con su respaldo. Lo que vendemos es la máquina donde se ejecuta un runner.
- Esta página no trata de alojar GitLab en sí. Una instancia de GitLab autogestionada es una caja mayor y otra conversación - pregúntenos y la dimensionamos, pero no es lo que aquí tiene precio.
- No escribimos su .gitlab-ci.yml. La pipeline es suya; el host, la red y la dirección son nuestros.
- El runner no se gestiona por usted salvo que lo pida. Lo instala usted, o añade nuestro servicio de administración y lo mantenemos parcheado, registrado y vigilado.
- Su suscripción de GitLab sigue siendo de GitLab. Un runner autogestionado no consume sus minutos de cómputo, que es de lo que se trata, pero tampoco sustituye las licencias de usuario.
Las partes que los equipos descubren tarde
- El flujo del token de registro está de salida. Un runner creado en la interfaz devuelve un token de autenticación glrt- que gitlab-runner register acepta como --token, y --registration-token está previsto para eliminarse en GitLab 20.0.
- Las etiquetas se fueron con él. Con un token de autenticación, las etiquetas del trabajo, la opción de trabajos sin etiqueta y el bloqueo pertenecen al objeto runner que creó en la interfaz, así que los flags que antes los fijaban en la línea de comandos ya no deciden nada.
- Fijar una versión significa fijar dos paquetes. Desde 17.7.1, una versión explícita de gitlab-runner necesita también gitlab-runner-helper-images en la misma versión, o apt rechaza la instalación.
- check_interval está por defecto en 3 segundos. En un host con muchos runners registrados eso es muchísimo sondeo; súbalo antes de culpar a la red.
- Docker-in-Docker necesita modo privilegiado, lo que en la práctica da al trabajo root sobre el host. Si la pipeline solo construye imágenes, un constructor sin root como Kaniko o Buildah es el trato más barato.
- Los artefactos y las cachés siguen viajando a GitLab salvo que apunte la caché a su propio bucket compatible con S3. En un runner que trasladó a la UE a propósito, ese suele ser el último salto que queda por mover.
Minutos de CI alojados frente a un runner propio
| Minutos de CI alojados por el proveedor | Un runner en DCXV | |
|---|---|---|
| Por lo que paga | Cada minuto de cada trabajo, mientras exista el proyecto | Un host mensual fijo, haga lo que haga la pipeline ese mes |
| Una compilación que se vuelve más lenta | Cuesta más cada mes que siga siendo lenta | No cuesta nada más - la máquina ya está pagada |
| Caché de capas de Docker | Fría en cada trabajo salvo que la suba y la baje usted mismo | Caliente en NVMe local, entre trabajos y entre días |
| Concurrencia | Un escalón de plan que se contrata | Un número que usted pone en su propio fichero de configuración |
| Dónde aterriza el checkout | Una flota compartida, a menudo en una región que no puede fijar | Una máquina en Praga o Covilhã, bajo contrato chipriota |
| Dirección saliente | Un rango compartido enorme que nada puede autorizar | Una IPv4 estática de AS204057, suya para autorizar |
| Lo que la máquina puede contener | Lo que la imagen del runner traiga de serie | Cualquier cadena de herramientas, licencia o conjunto de datos que instale una vez |
Cómo se pone esto en marcha en su host
Díganos qué hace la pipeline
El trabajo más pesado que ejecuta hoy, cuántos quiere a la vez y si construye imágenes de contenedor. Con eso basta para dimensionar un host sin adivinar.
Le entregamos la máquina
Praga o Covilhã, acceso root y una IPv4 estática, en menos de diez minutos. Traiga su propia imagen si el runner ya viene dentro.
Siga el paso a paso de esta página
Es la secuencia del fabricante, tomada de su documentación actual y no de una entrada de blog, y lleva unos minutos en un host limpio.
Haga un snapshot y añada el segundo
Haga un snapshot en cuanto la primera pipeline esté en verde, para que la siguiente máquina sea una restauración y no una reconstrucción. Un grupo crece añadiendo hosts, no haciendo uno enorme.
Por qué elegirnos
- Instalaciones certificadas Tier III, SLA de instalación del 99,982 %
- Red propia, AS204057, IPv4 e IPv6
- Soporte 24/7/365 con unos 10 minutos de respuesta media
- Sociedad chipriota, jurisdicción de la UE, conforme al RGPD desde 2007
FAQ
- ¿Cuál es la diferencia entre un runner compartido y uno autogestionado?
Un runner compartido es la máquina de GitLab y usted paga por los minutos que dedica a su trabajo. Un runner autogestionado es su máquina: instala gitlab-runner en ella, la registra contra su proyecto, grupo o instancia, y no consume minutos de cómputo en absoluto. Los espacios de nombres del plan gratuito de GitLab reciben 400 minutos de cómputo al mes, y una pipeline activa se los come en días
- ¿Cómo instalo y registro GitLab Runner?
Añada su repositorio apt desde el script de instalación de packages.gitlab.com, instale el paquete gitlab-runner y ejecute después gitlab-runner register en modo no interactivo con el token de autenticación que GitLab le da al crear el runner en la interfaz. La secuencia completa con los comandos exactos está en esta página, tomada de su documentación y no de una entrada de blog
- ¿Se sigue registrando un runner con el token de registro?
No, y es el cambio que rompe la mayoría de las guías antiguas. Cree primero el runner en la interfaz de GitLab y le devolverá un token de autenticación que empieza por glrt-, que gitlab-runner register acepta como --token. El antiguo flujo con --registration-token está obsoleto y previsto para eliminarse en GitLab 20.0. Las etiquetas del trabajo, la opción de trabajos sin etiqueta y el bloqueo pertenecen ahora al objeto runner que creó en la interfaz, no al comando register
- ¿Qué tamaño de servidor necesita un GitLab Runner?
GitLab no publica requisitos de hardware para el runner en sí, porque el proceso del runner es pequeño y su compilación no lo es. Dimensione por el trabajo más pesado multiplicado por la concurrencia que quiere. En la práctica 4 vCPU, 8 GB y 120 GB de NVMe llevan dos o tres trabajos a la vez; 8 vCPU, 16 GB y 240 GB llevan de seis a ocho. Sea generoso con el disco - la caché de capas de Docker y el espacio de trabajo son lo que lo llena
- ¿Necesito Docker en el host del runner?
Solo si usa el executor docker, que es lo que hace casi todo el mundo. Habla con un Docker Engine local por la API v1.25, así que el demonio tiene que estar instalado en el propio host del runner. El executor shell no necesita Docker en absoluto, y los executors instance y docker-autoscaler crean máquinas en otro sitio
- ¿Pueden compartir un host varios runners?
Sí, y es la forma normal. Registre tantos como quiera contra la misma instalación; el ajuste concurrent en /etc/gitlab-runner/config.toml es un techo para todos ellos, y cada runner puede llevar por debajo un límite propio más pequeño. Vigile check_interval, que está por defecto en 3 segundos y se convierte en mucho sondeo en cuanto un host lleva una docena de runners
Si necesita asistencia o tiene preguntas adicionales, por favor contacte a los gerentes o escriba al equipo de soporte en support@dcxv.com
¿Listo para comenzar?
Facturación mensual, sin cuota de instalación, sin compromiso