Runner executors ​

L'executor est le programme qui tourne sur le runner et qui est en charge d'executer les jobs.

Différents types d'executors existent:

• Shell
• SSH
• VirtualBox, Parallels
• Docker
• Docker Machine, Docker Autoscaler
• Kubernetes
• Custom

Shell ​

L'executor Shell est l'un des executors les plus simples. Il va simplement exécuter le script du job dans un shell au sein de la machine où l'executor est installé et configuré.

Avec cette architecture, tous les outils qui peuvent être nécessaires pour l'exécution des jobs (python, node, docker...) doivent être installés au préalable sur la machine

SSH ​

L'executor SSH est assez similaire à l'executor Shell, mais va exécuter les commandes des jobs dans une machine distante via une connexion SSH. Il supporte l'authentification via username/mot de passe ou par une clé SSH.

VirtualBox, Parallels ​

Les executors VirtualBox et Parallels permettent d'utiliser des VM pour executer les scripts des jobs.

L'executor se base sur une VM de base qui doit être créée au préalable. L'executor va réaliser une copie de cette VM pour chacun des jobs, et executer leurs scripts au sein de ces VM.

Docker ​

L'executor Docker se base sur la conteneurisation pour pouvoir executer les différents travaux demandés. Chacun des jobs va s'exécuter dans un conteneur dédié, à partir d'une image donnée.

Au total 3 conteneurs seront créés :

1. Un conteneur pour les étapes de pré-build : clone du repo, récupération des artifacts et du cache
2. Un conteneur basé sur l'image spécifiée dans le job, ou une image par défaut, pour l'exécution des étapes du job
3. Un conteneur pour les étapes de post-build : récupération des artifacts et du cache

Docker Machine, Docker Autoscaler ​

Docker Machine et Docker Autoscaler sont deux executors basés sur l'executor Docker, mais qui fournissent en plus des fonctionnalités d'autoscaling de la capacité du runner, afin de supporter des charges variables.

À mesure que la charge du runner va varier, l'executor va créer plus ou moins de hosts Docker sur lesquels les jobs vont pouvoir s'executer.

[ref] [ref]

Ces executors s'appuient sur des solutions de virtualisations qui sont en charge de gérer les hosts sur lesquels tournent les jobs.

Docker Machine supporte de nombreux outils de virtualisation : AWS, Azure, GCP, OpenStack, HyperV... (liste complète)

Docker Autoscaler est similaire à Docker Machine, mais supporte, pour le moment, moins de provider (AWS, Azure, GCP, Parallels)

Kubernetes ​

L'executor Kubernetes permet de faire fonctionner les jobs au sein de pods sur un cluster Kubernetes.

Lorsque l'executor reçoit la demande d'exécution d'un nouveau job, il va créer un pod avec 3 conteneurs :

1. Un conteneur pour les étapes de pré-build : clone du repo, récupération des artifacts et du cache
2. Un conteneur basé sur l'image spécifiée dans le job, ou une image par défaut, pour l'exécution des étapes du job
3. Un conteneur pour les étapes de post-build : récupération des artifacts et du cache

Custom ​

Gitlab permet l'utilisation d'executors custom afin de permettre le support de cas qui ne sont pas couverts par les executors déjà présents, comme par exemple l'utilisation de LXD ou libvirt pour la construction de conteneurs.

Pour cet executor, il est nécessaire de configurer les commandes à exécuter pour les différentes étapes des jobs.

runners:
  - name: custom runner
    url: 'https://gitlab.com'
    token: <RUNNERS TOKEN>

    executor: custom
    custom:
      config_exec: /path/to/config.sh
      config_args:
        - SomeArg

      prepare_exec: /path/to/script.sh
      prepare_args:
        - SomeArg

      run_exec: /path/to/binary
      run_args:
        - SomeArg

      cleanup_exec: /path/to/executable
      cleanup_args:
        - SomeArg

[ref]

Comparaison ​

1. Possible mais risqué dans les cas où le job utilise des services ou outils installés sur le runner
2. Nécessite au préalable l'installation et la configuration des dépendances

[ref]