GitLab Runner

gitlab-runner despliega una VM con un GitLab Runner en un contenedor de Docker, con un disco de datos para las imágenes, la caché de compilación y la de los jobs, y una limpieza semanal que evita que se llene. Un stack por runner.

Fase	Trabajo	Despliega
1 infra	vm	La máquina
2 host	docker	Docker, con sus datos en /data
3 runner	runner	El config.toml, el contenedor y la comprobación de que se ha registrado
3 runner	prune	La limpieza programada

Por defecto: 4 núcleos, 8 GiB, disco raíz de 32 GiB y de datos de 100 GiB, concurrent = 2 y una limpieza cada lunes a las 03:00 que mantiene siete días.

Despliegue

1. En Horizon, crear el registro DNS de la máquina con su propia MAC.
2. En GitLab, crear el runner (Settings › CI/CD › Runners › New runner) y copiar su token glrt-. La descripción, los tags y el tiempo máximo pertenecen al runner en GitLab.
3. Desplegar la plantilla GitLab Runner, respondiendo:
   • gitlab_runner_token: el token del paso anterior.
   • docker_access: dind da a cada job su propio daemon de Docker; socket monta el socket de la máquina, más rápido pero equivalente a dar root en la máquina a cada job. dind salvo que los proyectos sean de confianza.

El runner no se registra con gitlab-runner register: todo el config.toml se escribe desde el repositorio, así que cada ajuste es visible y cambiarlo es editar el stack. Si el token no es válido, el despliegue falla en lugar de dejar una máquina vacía.

información

El mismo token se puede usar en varias máquinas: cada una aparece en GitLab como un runner manager del mismo runner.

Cambios

No hay acciones. Cada ajuste es una variable de su trabajo:

Para cambiar	Editar
Versión, concurrencia, imagen por defecto, acceso a Docker, volúmenes o entorno	El trabajo runner
Los registry mirrors	El trabajo docker
El horario o la retención de la limpieza	El trabajo prune
El tamaño de la máquina	El trabajo vm

La limpieza se puede lanzar a mano:

sudo /opt/gitlab-runner/prune.sh

Monitorización

Además de los checks base, Nagios vigila Docker, el runner y sus métricas. No tiene check de carga: un pipeline usa todos los núcleos a propósito, y una alerta en cada ejecución es una alerta que nadie lee.

Documentación

• architecture.md: el contenedor, los discos, los modos de acceso a Docker y el tamaño.
• operations.md: fases, actualizaciones, la limpieza y qué hacer cuando algo falla.