Déploiement de groupes identiques d’exécuteurs avec Actions Runner Controller

Déploiement d’un groupe identique d’exécuteurs

Pour déployer un ensemble d'échelles d'exécuteurs, vous devez avoir ARC en cours d'exécution. Pour plus d’informations, consultez « AUTOTITLE ».

Vous pouvez déployer des groupes identiques d’exécuteurs avec les charts Helm d’ARC ou en déployant les manifestes nécessaires. L’utilisation des charts Helm d’ARC est la méthode recommandée, en particulier si vous n’avez pas d’expérience préalable avec ARC.

1. Pour configurer votre ensemble échelonné d’exécuteurs, exécutez la commande suivante dans votre terminal en utilisant les valeurs de la configuration de votre ARC.

   Lorsque vous exécutez la commande, gardez les points suivants à l’esprit.

   • Mettez à jour la valeur en faisant bien attention. Vous utiliserez le nom de l’installation comme valeur de dans vos workflows.

   • Mettez à jour la valeur à l'emplacement où vous souhaitez que les pods de runner soient créés.

   • Définissez la valeur sur l’URL de votre dépôt, de votre organisation ou de votre entreprise. Il s'agit de l'entité dont les coureurs feront partie.

   • Cet exemple de commande installe la dernière version du chart Helm. Pour installer une version spécifique, vous pouvez passer l’argument avec la version du chart que vous voulez installer. Vous trouverez la liste des versions dans le dépôt .

     Bash

     INSTALLATION_NAME="arc-runner-set"
     NAMESPACE="arc-runners"
     GITHUB_CONFIG_URL="https://github.com/<your_enterprise/org/repo>"
     GITHUB_PAT="<PAT>"
     helm install "${INSTALLATION_NAME}" \
         --namespace "${NAMESPACE}" \
         --create-namespace \
         --set githubConfigUrl="${GITHUB_CONFIG_URL}" \
         --set githubConfigSecret.github_token="${GITHUB_PAT}" \
         oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set
     

     Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

2. Pour vérifier votre installation, exécutez la commande suivante dans votre terminal.

   Bash

   helm list -A
   

   Le résultat ressemble à ce qui suit.

   NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                                       APP VERSION
   arc             arc-systems     1               2023-04-12 11:45:59.152090536 +0000 UTC deployed        gha-runner-scale-set-controller-0.4.0       0.4.0
   arc-runner-set  arc-systems     1               2023-04-12 11:46:13.451041354 +0000 UTC deployed        gha-runner-scale-set-0.4.0                  0.4.0
   

3. Pour vérifier le pod de gestionnaire, exécutez la commande suivante dans votre terminal.

   Bash

   kubectl get pods -n arc-systems
   

   Si l’installation a réussi, les pods affichent l’état .

   NAME                                                   READY   STATUS    RESTARTS   AGE
   arc-gha-runner-scale-set-controller-594cdc976f-m7cjs   1/1     Running   0          64s
   arc-runner-set-754b578d-listener                       1/1     Running   0          12s
   

Si votre installation n’a pas réussi, consultez « AUTOTITLE » pour obtenir des informations de dépannage.

Utilisation des options de configuration avancées

ARC offre plusieurs options de configuration avancées.

Configurer le nom de l'ensemble échelonné d'exécuteurs

Pour configurer le nom de l’ensemble d’échelle des coureurs, vous pouvez définir une variable ou définir la valeur de cette variable dans votre copie du fichier de configuration.

## The name of the runner scale set to create, which defaults to the Helm release name
runnerScaleSetName: "my-runners"

Veillez à passer le fichier dans votre commande . Pour plus d’informations, consultez la documentation d'installation de Helm.

Choix des destinations des exécuteurs

Les ensembles de taille des runners peuvent être déployés au niveau du dépôt, de l'organisation ou de l'entreprise.

Pour déployer des ensembles d'échelles d'exécution à un niveau spécifique, définissez la valeur dans votre copie du fichier correspondant à l'URL de votre dépôt, organisation ou entreprise.

L’exemple suivant montre comment configurer ARC pour ajouter des exécuteurs à .

githubConfigUrl: "https://github.com/octo-ent/octo-org/octo-repo"

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Utilisation d’une GitHub App pour l’authentification

Si vous n’utilisez pas d’agents au niveau de l’entreprise, vous pouvez utiliser GitHub Apps pour vous authentifier auprès de l’API GitHub. Pour plus d’informations, consultez « AUTOTITLE ».

Vous pouvez créer un secret Kubernetes ou spécifier des valeurs dans votre fichier .

Option 1 : Créer un secret Kubernetes (recommandé)

Une fois que vous avez créé votre GitHub App, créez un secret Kubernetes et passez la référence à ce secret dans votre copie du fichier .

kubectl create secret generic pre-defined-secret \
  --namespace=arc-runners \
  --from-literal=github_app_id=123456 \
  --from-literal=github_app_installation_id=654321 \
  --from-file=github_app_private_key=private-key.pem

Dans votre copie du fichier, passez le nom du secret en tant que référence.

githubConfigSecret: pre-defined-secret

Option 2 : Spécifier des valeurs dans votre fichier

Vous pouvez également spécifier les valeurs de , et dans votre copie du fichier .

## githubConfigSecret is the Kubernetes secret to use when authenticating with GitHub API.
## You can choose to use a GitHub App or a personal access token (classic)
githubConfigSecret:
  ## GitHub Apps Configuration
  ## IDs must be strings, use quotes
  github_app_id: "123456"
  github_app_installation_id: "654321"
  github_app_private_key: |
    -----BEGIN RSA PRIVATE KEY-----
    ...
    HkVN9...
    ...
    -----END RSA PRIVATE KEY-----

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Gestion de l’accès avec des groupes de runners

Vous pouvez utiliser des groupes d’exécuteurs pour contrôler les organisations ou dépôts qui ont accès à vos grandes échelles d’exécuteurs. Pour plus d’informations sur les groupes de runners, consultez « AUTOTITLE ».

Pour ajouter un ensemble d'échelles de coureurs à un groupe d’exécuteurs, vous devez déjà avoir créé un groupe d’exécuteurs. Ensuite, définissez la propriété dans votre copie du fichier. L'exemple suivant ajoute un ensemble évolutif d’exécuteurs au groupe d’exécuteurs Octo-Group.

runnerGroup: "Octo-Group"

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Configuration d’un proxy sortant

Pour forcer le trafic HTTP du contrôleur et des exécuteurs à passer par votre proxy sortant, définissez les propriétés suivantes dans votre Helm chart.

proxy:
  http:
    url: http://proxy.com:1234
    credentialSecretRef: proxy-auth # a Kubernetes secret with `username` and `password` keys
  https:
    url: http://proxy.com:1234
    credentialSecretRef: proxy-auth # a Kubernetes secret with `username` and `password` keys
  noProxy:
    - example.com
    - example.org

ARC prend en charge l’utilisation de proxys anonymes ou authentifiés. Si vous utilisez des proxys authentifiés, vous devez définir la valeur pour référencer un secret Kubernetes. Vous pouvez créer un secret avec vos informations d’identification de proxy avec la commande suivante.

  kubectl create secret generic proxy-auth \
    --namespace=arc-runners \
    --from-literal=username=proxyUsername \
    --from-literal=password=proxyPassword \

  kubectl create secret generic proxy-auth \
    --namespace=arc-runners \
    --from-literal=username=proxyUsername \
    --from-literal=password=proxyPassword \

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Définition du nombre maximal et minimal d’exécuteurs

Les propriétés et vous fournissent un éventail d’options pour personnaliser votre configuration ARC.

Exemple : Nombre non délimité d’exécuteurs

Si vous commentez à la fois les propriétés et , ARC effectue un scale-up jusqu’au nombre de travaux attribués au groupe identique d’exécuteurs et effectue un scale-down à 0 s’il n’y a aucun travail actif.

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
# maxRunners: 0

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
# minRunners: 0

Exemple : Nombre minimal d’exécuteurs

Vous pouvez définir le paramètre sur n’importe quel nombre, et ARC veillera à ce qu'il y ait toujours le nombre spécifié d'agents actifs et disponibles pour prendre en charge les tâches assignées au groupe de mise à l'échelle des agents.

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
# maxRunners: 0

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 20

Exemple : Définir le nombre maximal et minimal d’exécuteurs

Dans cette configuration, Actions Runner Controller effectue un scale-up jusqu’à un maximum de exécuteurs et un scale-down à exécuteurs quand les travaux sont terminés.

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
maxRunners: 30

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 20

Exemple : Drainage de la file d'attente de tâches

Dans certains scénarios, vous pourriez vouloir vider la file d’attente des tâches pour résoudre un problème ou effectuer une maintenance sur votre cluster. Si vous définissez les deux propriétés sur une valeur donnée, Actions Runner Controller ne créera pas de nouveaux pods d’exécuteur lorsque de nouveaux travaux seront disponibles et attribués.

## maxRunners is the max number of runners the auto scaling runner set will scale up to.
maxRunners: 0

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 0

Certificats TLS personnalisés

Certains environnements demandent des certificats TLS signés par une autorité de certification personnalisée. Étant donné que les certificats d’autorité de certification personnalisés ne sont pas regroupés avec les conteneurs de contrôleur ou d’exécuteur, vous devez les injecter dans leur magasin de confiance respectif.

githubServerTLS:
  certificateFrom:
    configMapKeyRef:
      name: config-map-name
      key: ca.crt
  runnerMountPath: /usr/local/share/ca-certificates/

Lorsque vous effectuez cette opération, veillez à utiliser le format PEM (Privacy Enhanced Mail) et vérifiez que l’extension de votre certificat est . Toutes les autres seront ignorées.

Le contrôleur exécute les actions suivantes.

• Crée un volume contenant le certificat spécifié dans .
• Monte le volume sur le chemin.
• Définit la variable d’environnement sur ce même chemin.
• Définit la variable d’environnement sur (à partir de la version , cela indique à l’exécuteur de recharger les certificats sur l’hôte).

ARC observe les valeurs définies dans le modèle de pod d’exécuteur et ne les remplace pas.

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Utilisation d’un registre de conteneurs privé

Pour utiliser un registre de conteneurs privé, vous pouvez copier l’image du contrôleur et l’image de l’exécuteur dans votre registre de conteneurs privé. Configurez ensuite les liens vers ces images et définissez les valeurs et .

Configuration de l’image du contrôleur

Vous pouvez mettre à jour votre copie du fichier et définir les propriétés comme suit.

image:
  repository: "custom-registry.io/gha-runner-scale-set-controller"
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "0.4.0"

imagePullSecrets:
  - name: <registry-secret-name>

Le conteneur d’écoute hérite de la configuration définie pour le contrôleur.

Configuration de l’image de l’exécuteur

Vous pouvez mettre à jour votre copie du fichier et définir les propriétés afin de configurer le pod exécuteur pour votre cas d’usage spécifique.

Voici un exemple de configuration :

template:
  spec:
    containers:
      - name: runner
        image: "custom-registry.io/actions-runner:latest"
        imagePullPolicy: Always
        command: ["/home/runner/run.sh"]
    imagePullSecrets:
      - name: <registry-secret-name>

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Mise à jour de la spécification du pod pour le pod de runner

Vous pouvez entièrement personnaliser le PodSpec du pod de l’exécuteur, et le contrôleur appliquera la configuration que vous spécifiez. Voici un exemple de spécification de pod.

template:
  spec:
    containers:
      - name: runner
        image: ghcr.io/actions/actions-runner:latest
        command: ["/home/runner/run.sh"]
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
        securityContext:
          readOnlyRootFilesystem: true
          allowPrivilegeEscalation: false
          capabilities:
            add:
              - NET_ADMIN

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Mise à jour de la spécification du pod pour le pod de l’écouteur

Vous pouvez personnaliser le PodSpec du pod d’écouteur et le contrôleur appliquera la configuration que vous avez spécifiée. Voici un exemple de spécification de pod.

listenerTemplate:
  spec:
    containers:
    # If you change the name of the container, the configuration will not be applied to the listener,
    # and it will be treated as a sidecar container.
    - name: listener
      securityContext:
        runAsUser: 1000
      resources:
        limits:
          cpu: "1"
          memory: 1Gi
        requests:
          cpu: "1"
          memory: 1Gi

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Utilisation du mode Docker-in-Docker ou Kubernetes pour les conteneurs

Si vous utilisez des tâches et des services de conteneur ou des actions de conteneur, vous devez définir la valeur à X ou Y. Pour utiliser un mode de conteneur personnalisé, commentez ou supprimez , puis ajoutez la configuration souhaitée dans la section . Consultez Personnalisation des modes de conteneur.

• Pour plus d’informations sur les travaux et services de conteneur, consultez « AUTOTITLE ».
• Pour plus d’informations sur les actions de conteneur, consultez « AUTOTITLE ».

Utilisation du mode Docker-in-Docker

Le mode Docker-in-Docker est une configuration qui vous permet d’exécuter Docker au sein d’un conteneur Docker. Dans cette configuration, pour chaque runner pod créé, ARC crée les conteneurs suivants.

• Un conteneur
• Un conteneur
• Un conteneur

Pour activer le mode Docker-in-Docker, définissez la valeur sur comme suit.

containerMode:
  type: "dind"

L'objet sera mis à jour avec la configuration par défaut suivante.

Pour les versions de Kubernetes , un conteneur sidecar sera utilisé pour exécuter le démon Docker.

template:
  spec:
    initContainers:
      - name: init-dind-externals
        image: ghcr.io/actions/actions-runner:latest
        command: ["cp", "-r", "/home/runner/externals/.", "/home/runner/tmpDir/"]
        volumeMounts:
          - name: dind-externals
            mountPath: /home/runner/tmpDir
      - name: dind
        image: docker:dind
        args:
          - dockerd
          - --host=unix:///var/run/docker.sock
          - --group=$(DOCKER_GROUP_GID)
        env:
          - name: DOCKER_GROUP_GID
            value: "123"
        securityContext:
          privileged: true
        restartPolicy: Always
        startupProbe:
          exec:
            command:
              - docker
              - info
          initialDelaySeconds: 0
          failureThreshold: 24
          periodSeconds: 5
        volumeMounts:
          - name: work
            mountPath: /home/runner/_work
          - name: dind-sock
            mountPath: /var/run
          - name: dind-externals
            mountPath: /home/runner/externals
    containers:
      - name: runner
        image: ghcr.io/actions/actions-runner:latest
        command: ["/home/runner/run.sh"]
        env:
          - name: DOCKER_HOST
            value: unix:///var/run/docker.sock
          - name: RUNNER_WAIT_FOR_DOCKER_IN_SECONDS
            value: "120"
        volumeMounts:
          - name: work
            mountPath: /home/runner/_work
          - name: dind-sock
            mountPath: /var/run
    volumes:
      - name: work
        emptyDir: {}
      - name: dind-sock
        emptyDir: {}
      - name: dind-externals
        emptyDir: {}

Pour les versions de Kubernetes , la configuration suivante sera appliquée :

template:
  spec:
    initContainers:
      - name: init-dind-externals
        image: ghcr.io/actions/actions-runner:latest
        command:
          ["cp", "-r", "/home/runner/externals/.", "/home/runner/tmpDir/"]
        volumeMounts:
          - name: dind-externals
            mountPath: /home/runner/tmpDir
    containers:
      - name: runner
        image: ghcr.io/actions/actions-runner:latest
        command: ["/home/runner/run.sh"]
        env:
          - name: DOCKER_HOST
            value: unix:///var/run/docker.sock
        volumeMounts:
          - name: work
            mountPath: /home/runner/_work
          - name: dind-sock
            mountPath: /var/run
      - name: dind
        image: docker:dind
        args:
          - dockerd
          - --host=unix:///var/run/docker.sock
          - --group=$(DOCKER_GROUP_GID)
        env:
          - name: DOCKER_GROUP_GID
            value: "123"
        securityContext:
          privileged: true
        volumeMounts:
          - name: work
            mountPath: /home/runner/_work
          - name: dind-sock
            mountPath: /var/run
          - name: dind-externals
            mountPath: /home/runner/externals
    volumes:
      - name: work
        emptyDir: {}
      - name: dind-sock
        emptyDir: {}
      - name: dind-externals
        emptyDir: {}

Les valeurs dans sont automatiquement injectées et ne peuvent pas être remplacées. Si vous souhaitez personnaliser cet ensemble, vous devez le désactiver, puis copier cette configuration et l'appliquer directement dans votre copie du fichier.

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Utilisation du mode Kubernetes

En mode Kubernetes, ARC utilise des hooks de conteneur d'exécution pour créer un nouveau pod dans le même espace de noms pour exécuter le service, la tâche de conteneur ou l'action.

Prérequis

Le mode Kubernetes prend en charge deux approches pour partager les données de travail entre le pod d’exécuteur et le pod de travail de conteneur. Vous pouvez utiliser des volumes persistants, qui restent l’option recommandée pour les scénarios nécessitant un accès en écriture simultané, ou vous pouvez utiliser des hooks de cycle de vie de conteneur pour restaurer et exporter des systèmes de fichiers de travail entre les pods sans compter sur les volumes RWX. L’approche du hook de cycle de vie améliore la portabilité et les performances en tirant parti du stockage local et est idéale pour les clusters sans stockage partagé.

Configuration du mode Kubernetes avec des volumes persistants

Pour utiliser le mode Kubernetes, vous devez créer des volumes persistants réclamés par les pods de runner et utiliser une solution qui approvisionne automatiquement ces volumes à la demande. Pour les tests, vous pouvez utiliser une solution comme OpenEBS.

Pour activer le mode Kubernetes, définissez sur dans votre fichier .

containerMode:
  type: "kubernetes"
  kubernetesModeWorkVolumeClaim:
    accessModes: ["ReadWriteOnce"]
    storageClassName: "dynamic-blob-storage"
    resources:
      requests:
        storage: 1Gi

Pour obtenir d’autres options de configuration de Helm, consultez values.yaml dans le référentiel ARC.

Configuration du mode Kubernetes avec des hooks de cycle de vie de conteneur

Pour activer le mode Kubernetes à l’aide des hooks du cycle de vie du conteneur, définissez à dans le fichier .

containerMode:
  type: "kubernetes-novolume"

Résolution des problèmes liés au mode Kubernetes

Lorsque le mode Kubernetes est activé, les workflows qui ne sont pas configurés avec un travail de conteneur échouent avec une erreur semblable à :

Jobs without a job container are forbidden on this runner, please add a 'container:' to your job or contact your self-hosted runner administrator.

Pour permettre aux travaux sans conteneur de travail de s’exécuter, définissez sur au niveau de votre conteneur d’exécuteur. Cela indique à l’exécuteur de désactiver cette vérification.

  template:
    spec:
      containers:
        - name: runner
          image: ghcr.io/actions/actions-runner:latest
          command: ["/home/runner/run.sh"]
          env:
            - name: ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER
              value: "false"

Personnalisation des modes de conteneur

Lorsque vous définissez dans le fichier pour le graphique Helm , vous pouvez utiliser l’une des valeurs suivantes :

• ou
• kubernetes

En fonction de la valeur que vous définissez pour , une configuration sera automatiquement injectée dans la section du fichier pour le graphique Helm .

• Voir la configuration.
• Veuillez consulter la configuration.

Pour personnaliser la spécification, mettez en commentaire ou supprimez , et ajoutez la configuration que vous voulez dans la section .

Exemple : fonctionnement

Avant de décider d'exécuter un programme, assurez-vous de connaître les limitations connues.

Pour les versions de Kubernetes >= v1.29, un conteneur sidecar sera utilisé pour exécuter le démon Docker.

## githubConfigUrl is the GitHub url for where you want to configure runners
## ex: https://github.com/myorg/myrepo or https://github.com/myorg
githubConfigUrl: "https://github.com/actions/actions-runner-controller"

## githubConfigSecret is the k8s secrets to use when auth with GitHub API.
## You can choose to use GitHub App or a PAT token
githubConfigSecret: my-super-safe-secret

## maxRunners is the max number of runners the autoscaling runner set will scale up to.
maxRunners: 5

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 0

runnerGroup: "my-custom-runner-group"

## name of the runner scale set to create. Defaults to the helm release name
runnerScaleSetName: "my-awesome-scale-set"

## template is the PodSpec for each runner Pod
## For reference: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec
template:
  spec:
    initContainers:
    - name: init-dind-externals
      image: ghcr.io/actions/actions-runner:latest
      command: ["cp", "-r", "/home/runner/externals/.", "/home/runner/tmpDir/"]
      volumeMounts:
        - name: dind-externals
          mountPath: /home/runner/tmpDir
    - name: init-dind-rootless
      image: docker:dind-rootless
      command:
        - sh
        - -c
        - |
          set -x
          cp -a /etc/. /dind-etc/
          echo 'runner:x:1001:1001:runner:/home/runner:/bin/ash' >> /dind-etc/passwd
          echo 'runner:x:1001:' >> /dind-etc/group
          echo 'runner:100000:65536' >> /dind-etc/subgid
          echo 'runner:100000:65536' >> /dind-etc/subuid
          chmod 755 /dind-etc;
          chmod u=rwx,g=rx+s,o=rx /dind-home
          chown 1001:1001 /dind-home
      securityContext:
        runAsUser: 0
      volumeMounts:
        - mountPath: /dind-etc
          name: dind-etc
        - mountPath: /dind-home
          name: dind-home
    - name: dind
      image: docker:dind-rootless
      args:
        - dockerd
        - --host=unix:///run/user/1001/docker.sock
      securityContext:
        privileged: true
        runAsUser: 1001
        runAsGroup: 1001
      restartPolicy: Always
      startupProbe:
        exec:
          command:
            - docker
            - info
        initialDelaySeconds: 0
        failureThreshold: 24
        periodSeconds: 5
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /run/user/1001
        - name: dind-externals
          mountPath: /home/runner/externals
        - name: dind-etc
          mountPath: /etc
        - name: dind-home
          mountPath: /home/runner
    containers:
    - name: runner
      image: ghcr.io/actions/actions-runner:latest
      command: ["/home/runner/run.sh"]
      env:
        - name: DOCKER_HOST
          value: unix:///run/user/1001/docker.sock
      securityContext:
        privileged: true
        runAsUser: 1001
        runAsGroup: 1001
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /run/user/1001
    volumes:
    - name: work
      emptyDir: {}
    - name: dind-externals
      emptyDir: {}
    - name: dind-sock
      emptyDir: {}
    - name: dind-etc
      emptyDir: {}
    - name: dind-home
      emptyDir: {}

Pour les versions de Kubernetes , la configuration suivante sera appliquée :

## githubConfigUrl is the GitHub url for where you want to configure runners
## ex: https://github.com/myorg/myrepo or https://github.com/myorg
githubConfigUrl: "https://github.com/actions/actions-runner-controller"

## githubConfigSecret is the k8s secrets to use when auth with GitHub API.
## You can choose to use GitHub App or a PAT token
githubConfigSecret: my-super-safe-secret

## maxRunners is the max number of runners the autoscaling runner set will scale up to.
maxRunners: 5

## minRunners is the min number of idle runners. The target number of runners created will be
## calculated as a sum of minRunners and the number of jobs assigned to the scale set.
minRunners: 0

runnerGroup: "my-custom-runner-group"

## name of the runner scale set to create. Defaults to the helm release name
runnerScaleSetName: "my-awesome-scale-set"

## template is the PodSpec for each runner Pod
## For reference: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec
template:
  spec:
    initContainers:
    - name: init-dind-externals
      image: ghcr.io/actions/actions-runner:latest
      command: ["cp", "-r", "/home/runner/externals/.", "/home/runner/tmpDir/"]
      volumeMounts:
        - name: dind-externals
          mountPath: /home/runner/tmpDir
    - name: init-dind-rootless
      image: docker:dind-rootless
      command:
        - sh
        - -c
        - |
          set -x
          cp -a /etc/. /dind-etc/
          echo 'runner:x:1001:1001:runner:/home/runner:/bin/ash' >> /dind-etc/passwd
          echo 'runner:x:1001:' >> /dind-etc/group
          echo 'runner:100000:65536' >> /dind-etc/subgid
          echo 'runner:100000:65536' >> /dind-etc/subuid
          chmod 755 /dind-etc;
          chmod u=rwx,g=rx+s,o=rx /dind-home
          chown 1001:1001 /dind-home
      securityContext:
        runAsUser: 0
      volumeMounts:
        - mountPath: /dind-etc
          name: dind-etc
        - mountPath: /dind-home
          name: dind-home
    containers:
    - name: runner
      image: ghcr.io/actions/actions-runner:latest
      command: ["/home/runner/run.sh"]
      env:
        - name: DOCKER_HOST
          value: unix:///run/user/1001/docker.sock
      securityContext:
        privileged: true
        runAsUser: 1001
        runAsGroup: 1001
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /run/user/1001
    - name: dind
      image: docker:dind-rootless
      args:
        - dockerd
        - --host=unix:///run/user/1001/docker.sock
      securityContext:
        privileged: true
        runAsUser: 1001
        runAsGroup: 1001
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /run/user/1001
        - name: dind-externals
          mountPath: /home/runner/externals
        - name: dind-etc
          mountPath: /etc
        - name: dind-home
          mountPath: /home/runner
    volumes:
    - name: work
      emptyDir: {}
    - name: dind-externals
      emptyDir: {}
    - name: dind-sock
      emptyDir: {}
    - name: dind-etc
      emptyDir: {}
    - name: dind-home
      emptyDir: {}

Comprendre runner-container-hooks

Lorsqu'un exécuteur détecte un flux de travail utilisant un travail de conteneur, un conteneur de service, ou une action Docker, il appellera runner-container-hooks pour créer un nouveau pod. L’exécuteur s’appuie sur runner-container-hooks pour appeler les API Kubernetes et créer un nouveau pod dans le même espace de noms que le pod d’exécuteur. Ce nouveau pod sera utilisé pour exécuter la tâche de conteneur, le conteneur de service ou l’opération Docker. Pour plus d'informations, consultez le dépôt .

Configuration des extensions de hook

À partir de la version 0.4.0 d’ARC, runner-container-hooks prend en charge les extensions de hook. Vous pouvez les utiliser pour configurer le pod créé par runner-container-hooks. Par exemple, vous pouvez utiliser une extension de hook pour définir un contexte de sécurité pour le pod. Les extensions de hook vous permettent de spécifier un fichier YAML qui est utilisé pour mettre à jour le PodSpec du pod créé par runner-container-hooks.

Il existe deux options pour configurer les extensions de hook.

• Stocker dans votre image d’exécuteur personnalisée. Vous pouvez stocker le PodSpec dans un fichier YAML n’importe où dans votre image d’exécuteur personnalisée. Pour plus d’informations, consultez « AUTOTITLE ».
• Stocker dans un ConfigMap. Vous pouvez créer un ConfigMap avec le PodSpec et monter ce ConfigMap dans le conteneur d’exécuteur. Pour plus d’informations, consultez ConfigMaps dans la documentation Kubernetes.

Exemple : Utilisation d’un ConfigMap pour définir securityContext

Créez un ConfigMap dans le même espace de noms que les pods d'exécuteur. Par exemple :

apiVersion: v1
kind: ConfigMap
metadata:
  name: hook-extension
  namespace: arc-runners
data:
  content: |
    metadata:
      annotations:
        example: "extension"
    spec:
      containers:
        - name: "$job" # Target the job container
          securityContext:
            runAsUser: 1000

• Les champs et seront ajoutés tels quels, sauf si leurs clés sont réservées. Vous ne pouvez pas remplacer les champs et .
• La majorité des champs de PodSpec sont appliqués à partir du modèle spécifié et remplacent les valeurs transmises par le fichier de votre graphique Helm.
• Si vous spécifiez des volumes supplémentaires, ils seront ajoutés aux volumes par défaut spécifiés par l’exécuteur.
• Les éléments sont fusionnés en fonction des noms qui leur sont attribués.
  • Si le nom du conteneur est  :
    • Les champs « et » sont ignorés.
    • Les champs , et sont ajoutés à la spécification de conteneur par défaut créée par le hook.
    • Les autres champs sont appliqués tels qu’ils ont été fournis.
  • Si le nom du conteneur n’est pas renseigné, les champs seront ajoutés tels quels à la définition du pod.

Activation des métriques

ARC peut émettre des métriques sur vos agents, vos tâches, et le temps consacré à l'exécution de vos flux de travail. Les métriques peuvent être utilisées pour identifier la congestion, surveiller l’intégrité de votre déploiement ARC, visualiser les tendances d’utilisation, optimiser la consommation des ressources, parmi de nombreux autres cas d’utilisation. Les métriques sont émises par les pods controller-manager et listener au format Prometheus. Pour plus d’informations, consultez les formats d'exposition dans la documentation Prometheus.

Pour activer les métriques pour ARC, configurez la propriété dans le fichier du graphique.

Voici un exemple de configuration.

metrics:
  controllerManagerAddr: ":8080"
  listenerAddr: ":8080"
  listenerEndpoint: "/metrics"

Une fois que ces propriétés sont configurées, vos pods de gestion de contrôleurs et de panneaux d'écouteurs émettent des métriques via le point de terminaison du listener lié aux ports que vous spécifiez dans votre fichier. Dans l’exemple ci-dessus, le point de terminaison est et le port est . Vous pouvez utiliser ce point de terminaison pour extraire des métriques à partir de vos pods contrôleur-manager et écouteur.

Pour désactiver les métriques, mettez à jour votre fichier en supprimant ou en commentant l’objet et ses propriétés.

Métriques disponibles pour ARC

Le tableau suivant présente les métriques générées par les pods du controller-manager et de l'écouteur.

1

Mise à niveau d’ARC

Étant donné que Helm ne prend pas en charge la mise à niveau ou la suppression des CRD, il n’est pas possible d’utiliser Helm pour mettre à niveau ARC. Pour plus d’informations, consultez Définitions de ressources personnalisées dans la documentation Helm. Pour mettre à niveau ARC vers une version plus récente, vous devez effectuer les étapes suivantes.

1. Désinstallez toutes les installations de .
2. Attendez que les ressources soient nettoyées.
3. Désinstallez ARC.
4. S’il existe une modification des CRD entre la version actuellement installée et la version mise à jour, supprimez tous les CRD associés au groupe d’API .
5. Réinstallez ARC.

Pour plus d'informations, voir Déploiement d'un jeu d'échelle pour les coureurs.

Si vous souhaitez mettre à niveau ARC mais que vous craignez l'indisponibilité, vous pouvez déployer ARC dans une configuration de haute disponibilité afin de garantir que les agents sont toujours disponibles. Pour plus d'informations, voir Haute disponibilité et basculement automatique.

Déploiement d’une image canari

Vous pouvez tester les fonctionnalités avant qu’elles ne soient publiées en utilisant des versions canary de l’image du conteneur controller-manager. Les images canary sont publiées avec un format de tag. Pour plus d’informations, reportez-vous au Container registry.

1. Mettez à jour le contenu dans le fichier gha-runner-scale-set-controller :
2. Mettez à jour le champ dans le fichier pour en :
3. Réinstallez ARC en utilisant le graphique Helm et les fichiers mis à jour.

Haute disponibilité et basculement automatique

ARC peut être déployé dans une configuration à haute disponibilité (active/active). Si vous avez deux clusters Kubernetes distincts déployés dans des régions distinctes, vous pouvez déployer ARC dans les deux clusters et configurer des groupes identiques d’exécuteurs pour qu’ils utilisent le même . Pour ce faire, chaque ensemble de mise à l'échelle de runner doit être affecté à un groupe de runners distinct. Par exemple, vous pouvez avoir deux groupes identiques d’exécuteurs nommés chacun, à condition qu’un groupe identique de l’exécuteur appartient à et que l’autre groupe identique de l’exécuteur appartient à . Pour en savoir plus sur l'attribution des ensembles de mise à l'échelle aux groupes de runners, voir AUTOTITLE.

Si les deux jeux d'échelle de runner sont en ligne, les tâches qui leur sont attribuées sont distribuées arbitrairement (concurrence d'attribution). Vous ne pouvez pas configurer l’algorithme d’attribution de projet. Si l’un des clusters tombe en panne, le groupe d'échelle des exécuteurs dans l’autre cluster continuera d’acquérir des tâches normalement sans aucune intervention ni modification de configuration.

Utilisation d’ARC dans les organisations

Une seule installation d’Actions Runner Controller vous permet de configurer un ou plusieurs groupes identiques d’exécuteurs. Ces ensembles de scale des exécutants peuvent être enregistrés dans un dépôt, une organisation ou une entreprise. Vous pouvez également utiliser des groupes d’exécuteurs pour contrôler les limites des autorisations de ces groupes identiques d’exécuteurs.

Il est recommandé de créer un espace de noms unique pour chaque organisation. Vous pouvez également créer un espace de noms pour chaque groupe d’exécuteurs ou chaque ensemble à l'échelle d’exécuteurs. Vous pouvez installer autant d'ensembles d'échelle d’exécuteurs que nécessaire dans chaque espace de noms. Vous bénéficierez ainsi des niveaux d’isolation les plus élevés et améliorerez votre sécurité. Vous pouvez utiliser GitHub Apps pour vous authentifier et définir des autorisations granulaires pour chaque ensemble d'exécution.

Mentions légales

Certaines parties ont été adaptées à partir de https://github.com/actions/actions-runner-controller/ sous la licence Apache-2.0 :

Copyright 2019 Moto Ishizawa

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.