Cómo administrar la concurrencia de GitLab Runner para trabajos paralelos de CI

Las canalizaciones de integración continua (CI) de GitLab son una forma popular de automatizar compilaciones, pruebas y lanzamientos cada vez que inserta código en su repositorio. Los oleoductos se ejecutan simultáneamente y consisten en etapas secuenciales; cada etapa puede incluir varios trabajos que se ejecutan en paralelo durante la etapa. La concurrencia máxima de trabajos paralelos y canalizaciones entre instancias depende de la configuración de su servidor.

Los trabajos son ejecutados por instancias de GitLab Runner. Los corredores operan como procesos aislados que reciben nuevos trabajos de su servidor GitLab de control. Cuando se emite un trabajo, el ejecutor creará un subproceso que ejecuta el script de CI. Existen múltiples variables que controlan cuándo un corredor aceptará un trabajo y comenzará a ejecutarlo. En esta guía, veremos las formas en que puede configurar trabajos y canalizaciones paralelos.

→ Índice de contenidos

Aumentar el número de corredores

Una forma de permitir que se ejecuten más trabajos simultáneamente es simplemente registrar más ejecutores. Cada instalación de GitLab Runner puede registrar varias instancias de ejecución distintas. Funcionan de forma independiente entre sí y no es necesario que todos se refieran al mismo servidor de coordinación.

Utilizar el gitlab-runner register comando para agregar un nuevo corredor:

sudo gitlab-runner register

Se le pedirá que proporcione la información de registro de su servidor GitLab. Puede encontrar esto en la página Configuración> CI/CD de un proyecto o grupo de GitLab, o dirigirse a Descripción general> Ejecutores en el Centro de administración para un ejecutor a nivel de instancia. Los ejecutores solo ejecutarán trabajos que se originen dentro del ámbito en el que están registrados.

Cada corredor registrado tiene su propia sección en su /etc/gitlab-runner/config.toml expediente:

# Runner 1
[[runners]]
    executor = "shell"
    ...

# Runner 2
[[runners]]
    executor = "shell"
    ...

# Runner 3
[[runners]]
    executor = "shell"
    ...

Si los tres ejecutores estuvieran registrados en el mismo servidor, ahora vería hasta tres trabajos ejecutándose en paralelo.

Aumento del límite de concurrencia

Puede establecer la concurrencia permitida de un registro de corredor específico usando el limit campo dentro de su bloque de configuración:

# Runner 1
[[runners]]
    executor = "shell"
    limit = 4

Este cambio permite que el primer ejecutor ejecute hasta cuatro trabajos simultáneos en subprocesos. Registrar otro corredor con limit = 2 elevaría el nivel de simultaneidad a un total de seis trabajos, suponiendo que ambos corredores hicieran referencia al mismo servidor GitLab de control.

Manejo de "Solicitud de concurrencia"

La cantidad de trabajos en vivo en ejecución no es la única variable que afecta la simultaneidad. GitLab Runner gestiona el número de solicitudes de trabajo puede aceptar a través del separado request_concurrency variable.

Este valor controla la cantidad de solicitudes en cola que el corredor tomará de GitLab. Cuando el servidor necesita programar un nuevo trabajo de CI, los ejecutores deben indicar si tienen suficiente capacidad para recibirlo. El ejecutor no aceptará el trabajo si ya tiene más solicitudes en cola que request_concurrency permisos

Considere este ejemplo:

# Runner 1
[[runners]]
    executor = "shell"
    limit = 2
    request_concurrency = 4

Este ejecutor aceptará hasta cuatro solicitudes de trabajo simultáneas y ejecutará hasta dos simultáneamente. No se aceptarán trabajos adicionales hasta que se hayan completado los dos iniciales.

El nivel de concurrencia global

GitLab Runner también mantiene un factor de concurrencia global que coloca un límite general en el limit valores expuestos por registros individuales. Puede controlar este valor con el concurrency ajuste en la parte superior de su config.toml:

concurrency = 4

# Runner 1
[[runners]]
    executor = "shell"
    limit = 4

# Runner 2
[[runners]]
    executor = "shell"
    limit = 2

Aquí, la configuración de los dos corredores sugiere una simultaneidad de trabajo total de seis. Sin embargo, la presencia del mundo concurrency significa que no se ejecutarán más de cuatro trabajos simultáneamente. Este valor limita la cantidad total de subprocesos que puede crear toda la instalación de GitLab Runner.

Aplicar cambios

Una vez que haya realizado los cambios que necesita, puede guardar su config.toml y vuelva a ejecutar sus canalizaciones. Las modificaciones al archivo son detectadas automáticamente por GitLab Runner y deberían aplicarse casi de inmediato.

Puede intentar reiniciar el proceso de GitLab Runner si el nuevo nivel de concurrencia no parece haberse aplicado:

sudo gitlab-runner restart

Esto detiene e inicia el servicio GitLab Runner, recargando el archivo de configuración.

Organizar sus tuberías para trabajos paralelos

Si sus trabajos en una sola canalización no se están paralelizando, vale la pena revisar los conceptos básicos de su .gitlab-ci.yml configuración. Es sólo trabajos que se ejecutan simultáneamente de forma predeterminada, no las etapas de canalización:

stages:
  test:
  build:
  deploy:

test:
  stage: test
  # ...

build_ios:
  stage: build
  # ...

build_android:
  stage: build
  # ...

deploy_ios:
  stage: deploy
  # ...

deploy_android:
  stage: deploy
  # ...

Esta canalización define tres etapas que se muestran horizontalmente en la interfaz de usuario de GitLab. Cada etapa debe completarse antes de que pueda comenzar la siguiente. los build y deploy Las etapas tienen dos trabajos cada una. Estos trabajos se ejecutan en paralelo si sus ejecutores tienen suficiente capacidad para mantenerse dentro de los límites de simultaneidad configurados.

Es posible romper la regla de "las etapas se ejecutan secuencialmente" usando el needs palabra clave para construir un gráfico acíclico dirigido:

stages:
  test:
  build:
  deploy:

test:
  stage: test
  # ...

build_ios:
  stage: build
  # ...

build_android:
  stage: build
  # ...

deploy_ios:
  stage: deploy
  needs: ["test", "build_ios"]
  # ...

deploy_android:
  stage: deploy
  needs: ["test", "build_android"]
  # ...

Aquí se permite que la implementación de iOS continúe tan pronto como el build_ios el trabajo ha terminado, incluso si el resto del build etapa no ha terminado. Utilizando needs hace que sus canalizaciones sean más flexibles al agregar nuevas oportunidades para la paralelización. Sin embargo, también trae consigo una complejidad que puede ser más difícil de mantener con el tiempo a medida que agrega más trabajos a su canalización.

¿Qué pasa con el almacenamiento en caché?

El uso de la concurrencia significa que sus trabajos pueden ser recogidos por diferentes ejecutores en cada paso a través de una canalización en particular. Los ejecutores mantienen sus propias instancias de caché, por lo que no se garantiza que un trabajo llegue a un caché, incluso si una ejecución anterior a través de la tubería llenó una. La memoria caché puede residir en un corredor diferente al que ejecuta el segundo trabajo.

Puede abordar esto configurando un proveedor de caché compartido mediante un sistema de almacenamiento de objetos compatible con S3. Esto hará que los cachés se carguen en ese proveedor después de que se complete el trabajo, almacenando el contenido independientemente de cualquier corredor específico. Otras instancias de ejecución podrán recuperar la memoria caché del servidor de almacenamiento de objetos incluso si no la crearon.

El almacenamiento en caché compartido puede mejorar el rendimiento al aumentar la probabilidad de un acierto de caché, lo que reduce el trabajo que deben completar sus trabajos. Sus tuberías no deberían exigir Sin embargo, la resolución de la memoria caché es satisfactoria: las memorias caché se utilizan según el mejor esfuerzo, por lo que los scripts de CI están destinados a ser resistentes a los errores.

Resumen

GitLab Runner le brinda tres controles principales para administrar la concurrencia: el limit y request_concurrency campos en corredores individuales, y el concurrency valor de la instalación total. Una instalación de Runner en particular no ejecutará más de <concurrency> empleos simultáneamente, incluso si la suma de sus registros limit valores sugiere que podría tomar más.

Agregar más corredores es otra forma de afectar la simultaneidad general. En general, es mejor aumentar la simultaneidad en un ejecutor existente si simplemente desea ejecutar más trabajos con la misma configuración. Agregue un nuevo corredor y establezca su limit valor cuando necesita ejecutar trabajos con un nuevo ejecutor o configuraciones que difieren de su flota existente.

Subir Change privacy settings