Развертывание масштабируемых наборов runner с помощью контроллера runner Actions

Развертывание масштабируемого набора runner

Чтобы развернуть масштабируемый набор runner, необходимо иметь ARC и запустить его. Дополнительные сведения см. в разделеКраткое руководство по контроллеру запуска действий.

Масштабируемые наборы runner можно развернуть с диаграммами Helm arc или развернуть необходимые манифесты. Использование диаграмм Helm ARC является предпочтительным методом, особенно если у вас нет предыдущего опыта использования ARC.

1. Чтобы настроить масштабируемый набор runner, выполните следующую команду в терминале, используя значения из конфигурации ARC.

   При выполнении команды помните следующее.

   • INSTALLATION_NAME Тщательно обновите значение. Имя установки будет использоваться в качестве значенияruns-on в рабочих процессах.

   • NAMESPACE Обновите значение до расположения, в которое нужно создать модули pod runner.

   • GITHUB_CONFIG_URL Задайте значение URL-адрес репозитория, организации или предприятия. Это сущность, к которой будут принадлежать средства выполнения.

   • В этом примере команда устанавливает последнюю версию диаграммы Helm. Чтобы установить определенную версию, можно передать--version аргумент с версией диаграммы, которую вы хотите установить. Список выпусков можно найти в репозиторииactions-runner-controller .

     Bash

     INSTALLATION_NAME="arc-runner-set"
     NAMESPACE="arc-runners"
     GITHUB_CONFIG_URL="http(s)://<HOSTNAME>/<'enterprises/your_enterprise'/'org'/'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
     

     Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

2. Чтобы проверить установку, выполните следующую команду в терминале.

   Bash

   helm list -A
   

   Должен отобразиться похожий результат:

   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. Чтобы проверить модуль pod диспетчера, выполните следующую команду в терминале.

   Bash

   kubectl get pods -n arc-systems
   

   Если установка выполнена успешно, модули pod будут отображатьRunning состояние.

   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
   

Если установка не прошла успешно, см. сведения об устранении неполадок в AUTOTITLE .

Использование дополнительных параметров конфигурации

Arc предлагает несколько дополнительных параметров конфигурации.

Настройка имени масштабируемого набора runner

Чтобы настроить имя масштабируемого набора runner, можно определитьINSTALLATION_NAME или задать значениеrunnerScaleSetName в копииvalues.yaml файла.

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

Обязательно передайтеvalues.yaml файл в командеhelm install . Дополнительные сведения см. вдокументации по установке Helm.

Выбор назначений runner

Масштабируемые наборы runner можно развертывать на уровне репозитория, организации или предприятия.

Чтобы развернуть масштабируемые наборы runner на определенном уровне, задайте значениеgithubConfigUrl в копииvalues.yaml url-адреса репозитория, организации или предприятия.

В следующем примере показано, как настроить ARC для добавления модулей runner вocto-org/octo-repo.

githubConfigUrl: "http(s)://<HOSTNAME>/<'enterprises/your_enterprise'/'org'/'org/repo'>"

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Использование GitHub App для проверки подлинности

Если вы не используете средства выполнения корпоративного уровня, можно использовать GitHub Apps для проверки подлинности с помощью API GitHub. Дополнительные сведения см. в разделеПроверка подлинности ARC в API GitHub.

Вы можете создать секрет Kubernetes или указать значения вvalues.yaml файле.

Вариант 1. Создание секрета Kubernetes (рекомендуется)

После создания GitHub Appсоздайте секрет Kubernetes и передайте ссылку на этот секрет в копииvalues.yaml файла.

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

В копии передаваемого имени секретаvalues.yaml в качестве ссылки.

githubConfigSecret: pre-defined-secret

Вариант 2. Указание значений вvalues.yaml файле

Кроме того, можно указать значенияapp_idиinstallation_id``private_key в копииvalues.yaml файла.

## 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-----

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Управление доступом с помощью групп runner

Группы runner можно использовать для управления доступом организаций или репозиториев к масштабируемым наборам runner. Дополнительные сведения о группах runner см. в разделеУправление доступом к самостоятельно размещенным средствам выполнения с помощью групп.

Чтобы добавить масштабируемый набор runner в группу runner, необходимо создать группу runner. Затем задайтеrunnerGroup свойство в копииvalues.yaml файла. В следующем примере добавляется масштабируемый набор runner в группу runner Octo-Group.

runnerGroup: "Octo-Group"

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Настройка исходящего прокси-сервера

Чтобы принудительно использовать HTTP-трафик для контроллера и runners, чтобы пройти через исходящий прокси-сервер, задайте следующие свойства в диаграмме Helm.

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

ARC поддерживает использование анонимных или прошедших проверку подлинности прокси-серверов. Если вы используете прокси-серверы, прошедшие проверку подлинности, необходимо задатьcredentialSecretRef значение для ссылки на секрет Kubernetes. Вы можете создать секрет с учетными данными прокси-сервера с помощью следующей команды.

  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 \

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Установка максимального и минимального количества бегуных средств

maxRunners СвойстваminRunners предоставляют широкий спектр параметров для настройки настройки ARC.

Пример: несвязанное количество бегущего

Если вы закомментируете обаmaxRunners свойства,minRunners ARC будет масштабироваться до количества заданий, назначенных масштабируемому набору runner, и будет масштабироваться до 0, если нет активных заданий.

## 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

Пример: минимальное количество бегунух

Свойство можно задатьminRunners для любого числа, и ARC всегда будет указано указанное число активных и доступных для выполнения заданий, назначенных масштабируемому набору runner.

## 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

Пример. Установка максимального и минимального количества средств выполнения

В этой конфигурации Actions Runner Controller будет масштабироваться до максимального количества30 средств выполнения и будет уменьшаться до20 запуска при завершении заданий.

## 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

Пример: очистка очередей заданий

В некоторых сценариях может потребоваться очистить очередь заданий, чтобы устранить проблему или выполнить обслуживание в кластере. Если для обоих свойств задано значение0,Actions Runner Controller не создаст новые модули pod runner при наличии и назначении новых заданий.

## 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

Пользовательские сертификаты TLS

Для некоторых сред требуются сертификаты TLS, подписанные пользовательским центром сертификации (ЦС). Так как пользовательские сертификаты центра сертификации не упаковываются с контейнерами контроллера или runner, их необходимо внедрить в соответствующие хранилища доверия.

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

При этом убедитесь, что вы используете формат расширенной почты конфиденциальности (PEM) и расширение сертификата.crt. Все остальное будет игнорироваться.

Контроллер выполняет следующие действия.

• Создает том, содержащий сертификат, указанныйgithub-server-tls-cert вcertificateFrom.
• Подключает этот том по путиrunnerMountPath/<certificate name>.
• NODE_EXTRA_CA_CERTS Задает переменную среды таким же путем.
• Задает для переменнойRUNNER_UPDATE_CA_CERTS среды значение1 (по состоянию на версию2.303.0), что поручает средству выполнения перезагрузить сертификаты на узле.

Arc наблюдает значения, заданные в шаблоне pod runner, и не перезаписывает их.

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Использование частного реестра контейнеров

Чтобы использовать частный реестр контейнеров, можно скопировать образ контроллера и образ runner в частный реестр контейнеров. Затем настройте ссылки на эти изображения и задайтеimagePullPolicy``imagePullSecrets значения.

Настройка образа контроллера

Вы можете обновить копиюvalues.yaml файла и задатьimage свойства следующим образом.

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>

Контейнер прослушивателя наследует определенныйimagePullPolicy для контроллера.

Настройка образа runner

Вы можете обновить копиюvalues.yaml файла и задатьtemplate.spec свойства, чтобы настроить модуль pod runner для конкретного варианта использования.

Ниже приведен пример конфигурации:

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

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Обновление спецификации pod для модуля runner

Вы можете полностью настроить PodSpec модуля pod runner, и контроллер будет применять указанную конфигурацию. Ниже приведен пример спецификации 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

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Обновление спецификации pod для модуля прослушивателя

Вы можете настроить PodSpec модуля pod прослушивателя, и контроллер будет применять указанную конфигурацию. Ниже приведен пример спецификации 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

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Использование режима Docker in-Docker или Kubernetes для контейнеров

Если вы используете задания контейнеров и службы или действия контейнера, необходимо задатьcontainerMode значениеdind илиkubernetes. Чтобы использовать настраиваемый режим контейнера, закомментируйте или удалитеcontainerModeи добавьте нужную конфигурацию вtemplate раздел. См. раздел"Настройка режимов контейнера".

• Дополнительные сведения о заданиях и службах контейнеров см. в разделеВыполнение заданий в контейнере.
• Дополнительные сведения о действиях контейнера см. в разделеСоздание действия контейнера Docker.

Использование режима Docker в Docker

Режим Docker в Docker — это конфигурация, которая позволяет запускать Docker в контейнере Docker. В этой конфигурации для каждого созданного модуля pod runner ARC создает следующие контейнеры.

• Контейнерinit
• Контейнерrunner
• Контейнерdind

Чтобы включить режим Docker в Docker, задайтеcontainerMode.type для этого значениеdind следующим образом.

containerMode:
  type: "dind"

Онtemplate.spec будет обновлен до следующей конфигурации по умолчанию.

Для версий Kubernetes>= v1.29контейнер боковика будет использоваться для запуска управляющей программы 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: {}

Для версий Kubernetes< v1.29будет применена следующая конфигурация:

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: {}

Значения, введенныеtemplate.spec автоматически, не могут быть переопределены. Если вы хотите настроить эту настройку, необходимо отменить настройкуcontainerMode.type, а затем скопировать эту конфигурацию и применить ее непосредственно в копииvalues.yaml файла.

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Использование режима Kubernetes

В режиме Kubernetes ARC использует перехватчики контейнеров runner для создания модуля pod в том же пространстве имен для запуска службы, задания контейнера или действия.

Необходимые компоненты

Режим Kubernetes поддерживает два подхода к совместному использованию данных задания между модулем pod средства выполнения тестов и модулем pod задания контейнера. Вы можете использовать постоянные тома, которые остаются рекомендуемым вариантом для сценариев, требующих параллельного доступа на запись, или вы можете использовать обработчики жизненного цикла контейнера для восстановления и экспорта файловых систем заданий между модулями pod, не полагаясь на тома RWX. Подход «перехватчика» жизненного цикла повышает переносимость и производительность за счет использования локального хранилища и идеально подходит для кластеров без общего хранилища.

Настройка режима Kubernetes с постоянными томами

Чтобы использовать режим Kubernetes, необходимо создать постоянные тома, которые могут претендовать модули pod средства выполнения, и использовать решение, которое автоматически подготавливает эти тома по запросу. Для тестирования можно использовать такое решение, какOpenEBS.

Чтобы включить режим Kubernetes, задайтеcontainerMode.type значениеkubernetes вvalues.yaml файле.

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

Дополнительные параметры конфигурации Helm см values.yaml . в репозитории ARC.

Настройка режима Kubernetes с помощью хуков жизненного цикла контейнера

Чтобы включить режим Kubernetes с помощью хуков жизненного цикла контейнера, установите в файлеcontainerMode.type``values.yaml значениеkubernetes-novolume:

containerMode:
  type: "kubernetes-novolume"

Устранение неполадок в режиме Kubernetes

Если режим Kubernetes включен, рабочие процессы, не настроенные с заданием контейнера, завершаются ошибкой, аналогичной следующей:

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

Чтобы разрешить выполнение заданий без контейнера заданий, установите значениеACTIONS_RUNNER_REQUIRE_JOB_CONTAINER``false в контейнере runner. Это указывает средству выполнения отключить эту проверку.

  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"

Настройка режимов контейнера

При настройкеcontainerMode``values.yaml файла дляgha-runner-scale-setдиаграммы helm можно использовать одно из следующих значений:

• dind или
• kubernetes

В зависимости от того, какое значение задано дляcontainerModeдиаграммы helm, конфигурация автоматически будет внедрена вtemplate разделvalues.yaml файлаgha-runner-scale-set .

• См. конфигурациюdind.
• См. конфигурациюkubernetes.

Чтобы настроить спецификацию, закомментируйте или удалитеcontainerModeее и добавьте нужную конфигурацию вtemplate разделе.

Пример: выполнениеdind-rootless

Перед принятием решения о запускеdind-rootlessубедитесь, что вы знаете известныеограничения.

Для версий Kubernetes>= v1.29контейнер боковика будет использоваться для запуска управляющей программы Docker.

## githubConfigUrl is the GitHub url for where you want to configure runners
## ex: http://<HOSTNAME>/enterprises/my_enterprise or http://<HOSTNAME>/myorg
githubConfigUrl: "http://<HOSTNAME>/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: http://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
      env:
        - name: DOCKER_HOST
          value: 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: {}

Для версий Kubernetes< v1.29можно применить следующую конфигурацию:

## githubConfigUrl is the GitHub url for where you want to configure runners
## ex: http://<HOSTNAME>/enterprises/my_enterprise or http://<HOSTNAME>/myorg
githubConfigUrl: "http://<HOSTNAME>/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: http://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: {}

Общие сведения о runner-container-hooks

Когда средство выполнения обнаруживает выполнение рабочего процесса, использующего задание контейнера, контейнер службы или действие Docker, он вызовет runner-container-hooks для создания нового модуля pod. Средство выполнения использует средство runner-container-hooks для вызова API Kubernetes и создания модуля pod в том же пространстве имен, что и модуль pod runner. Этот созданный модуль pod будет использоваться для запуска задания контейнера, контейнера службы или действия Docker. Дополнительные сведения см. в репозиторииrunner-container-hooks.

Настройка расширений перехватчика

По состоянию на ARC версии 0.4.0 runner-container-hooks поддерживает расширения перехватчиков. Их можно использовать для настройки модуля pod, созданного с помощью runner-container-hooks. Например, можно использовать расширение перехватчика для задания контекста безопасности в модуле pod. Расширения перехватчика позволяют указать YAML-файл, который используется для обновленияPodSpec модуля pod, созданного runner-container-hooks.

Существует два варианта настройки расширений перехватчика.

• Храните впользовательском образе бегуна. Вы можете хранить PodSpec в файле YAML в любом месте пользовательского образа runner. Дополнительные сведения см. в разделеКонтроллер runner действий.
• Храните вConfigMap. Вы можете создать карту конфигурации с помощью PodSpec и подключить эту карту конфигурации в контейнере runner. Дополнительные сведения см. в разделе ConfigMaps в документации по Kubernetes.

Пример. Использование карты конфигурации для задания securityContext

Создайте карту конфигурации в том же пространстве имен, что и модули pod runner. Например:

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

• .metadata.labels Поляmetadata.annotations будут добавлены как есть, если их ключи не зарезервированы. Невозможно переопределить.metadata.name поля иmetadata.namespace поля.
• Большинство полей PodSpec применяются из указанного шаблона и переопределяют значения, передаваемые из файла диаграммыvalues.yaml Helm.
• Если указать дополнительные тома, они будут добавлены к томам по умолчанию, указанным в средстве выполнения.
• Ониspec.containers объединяются на основе имен, назначенных им.
  • Если имя контейнера :$job
    • spec.containers.name Поляspec.containers.image игнорируются.
    • spec.containers.envПоляspec.containers.volumeMountsиspec.containers.ports поля добавляются к спецификации контейнера по умолчанию, созданной перехватчиком.
    • Остальные поля применяются, как указано.
  • Если имя контейнера не$jobзадано, поля будут добавлены в определение pod по мере их использования.

Включение метрик

Arc может выдавать метрики о бегунах, заданиях и времени, потраченных на выполнение рабочих процессов. Метрики можно использовать для выявления перегрузки, мониторинга работоспособности развертывания ARC, визуализации тенденций использования, оптимизации потребления ресурсов, среди многих других вариантов использования. Метрики создаются диспетчером контроллеров и модулями прослушивателя в формате Prometheus. Дополнительные сведения см. в форматах экспозиций в документации Prometheus.

Чтобы включить метрики для ARC, настройтеmetrics свойство вvalues.yamlфайлеgha-runner-scale-set-controller диаграммы.

Ниже приведен пример конфигурации.

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

После настройки этих свойств диспетчер контроллера и модули pod прослушивателя выдают метрики через прослушивательEndpoint, привязанные к портам, указанным вvalues.yaml файле. В приведенном выше примере конечная точка находится/metrics и порт:8080. Эту конечную точку можно использовать для очистки метрик из модулей pod диспетчера контроллера и прослушивателя.

Чтобы отключить метрики, обновитеvalues.yamlфайл, удалив или закомментируяmetrics: объект и его свойства.

Доступные метрики для ARC

В следующей таблице показаны метрики, создаваемые модулями pod диспетчера контроллера и прослушивателя.

[1]: Listener metrics that have the counter type are reset when the listener pod restarts.

Использование ARC с Dependabot и code scanning

Вы можете использовать Actions Runner Controller для создания выделенных модулей выполнения для экземпляра GitHub Enterprise Server, который Dependabot может использовать для защиты и поддержания зависимостей, используемых в репозиториях на предприятии. Дополнительные сведения см. в разделеУправление локальными средствами выполнения для обновлений Dependabot в вашем предприятии.

Вы также можете использовать ARC с CodeQL для выявления уязвимостей и ошибок в коде. Дополнительные сведения см. в разделеО проверке кода с помощью CodeQL. Если вы уже используете code scanning и хотите настроить масштабируемый набор runner для использования настройки по умолчанию, задайте.INSTALLATION_NAME=code-scanning Дополнительные сведения о настройке code scanning по умолчанию см. в разделеНастройка настройки по умолчанию для сканирования кода.

Actions Runner Controller не использует несколько меток для маршрутизации заданий в определенные масштабируемые наборы runner. Вместо этого, чтобы назначить масштабируемый набор runner для Dependabot или code scanning с CodeQL, используйте описательное имя установки в диаграмме Helm, напримерdependabot илиcode-scanning. Затем можно задатьruns-on значение в рабочих процессах в качестве одной метки и использовать назначенный масштабируемый набор runner для обновлений Dependabot или заданий code scanning .

Если вы используете настройку по умолчанию для code scanning, анализ будет автоматически искать масштабируемый набор runner с именемcode-scanning установки .

Обновление ARC

Так как нет поддержки обновления или удаления CRD с Helm, невозможно использовать Helm для обновления ARC. Дополнительные сведения см. в разделе "Пользовательские определения ресурсов" в документации Helm. Чтобы обновить ARC до более новой версии, необходимо выполнить следующие действия.

1. Удалите все установкиgha-runner-scale-set.
2. Дождитесь очистки ресурсов.
3. Удалите ARC.
4. При изменении crDs из установленной версии до обновленной версии удалите все crD, связанные сactions.github.com группой API.
5. Переустановите ARC еще раз.

Дополнительные сведения см. в разделе"Развертывание масштабируемого набора runner".

Если вы хотите обновить ARC, но обеспокоены временем простоя, вы можете развернуть ARC в конфигурации высокой доступности, чтобы убедиться, что средства выполнения всегда доступны. Дополнительные сведения см. в разделе"Высокий уровень доступности" и "Автоматическая отработка отказа".

Развертывание канарского образа

Перед выпуском функций можно протестировать с помощью канарной версии образа контейнера диспетчера контроллера. Канареарные изображения публикуются с форматомcanary-SHORT_SHAтега. Дополнительные сведения смgha-runner-scale-set-controller . в разделе Container registry.

1. tag Обновите файл контроллера-контроллераgha-runner-scale-set-controllervalues.yaml следующим образом:canary-SHORT_SHA
2. Обновите полеappVersion вChart.yaml файле следующимgha-runner-scale-set образом:canary-SHORT_SHA
3. Повторно установите ARC с помощью обновленной диаграммы Helm иvalues.yaml файлов.

Высокий уровень доступности и автоматическая отработка отказа

Arc можно развернуть в конфигурации высокого уровня доступности (active-active). Если у вас есть два разных кластера Kubernetes, развернутые в отдельных регионах, можно развернуть ARC в обоих кластерах и настроить масштабируемые наборы runner для использования одного и того жеrunnerScaleSetName. Для этого каждый масштабируемый набор runner должен быть назначен отдельной группе runner. Например, можно иметь два масштабируемых набора runner, каждый из которых называетсяarc-runner-set, если один масштабируемый набор runner принадлежитrunner-group-A , а другой масштабируемый набор runner принадлежитrunner-group-B. Сведения о назначении масштабируемых наборов runner группам runner см. в разделеУправление доступом к самостоятельно размещенным средствам выполнения с помощью групп.

Если оба масштабируемых набора runner находятся в сети, задания, назначенные им, будут распределяться произвольно (раса назначения). Невозможно настроить алгоритм назначения заданий. Если один из кластеров выходит из строя, масштабируемый набор runner в другом кластере будет продолжать получать задания обычно без каких-либо изменений в настройке или вмешательства.

Использование ARC в разных организациях

Одна установка Actions Runner Controller позволяет настроить один или несколько масштабируемых наборов runner. Эти масштабируемые наборы запуска можно зарегистрировать в репозитории, организации или организации. Группы runner также можно использовать для управления границами разрешений этих масштабируемых наборов runner.

Рекомендуется создать уникальное пространство имен для каждой организации. Можно также создать пространство имен для каждой группы runner или каждого масштабируемого набора runner. Вы можете установить столько масштабируемых наборов runner, сколько необходимо в каждом пространстве имен. Это обеспечит максимально высокий уровень изоляции и улучшит безопасность. Для проверки подлинности можно использовать GitHub Apps и определять детализированные разрешения для каждого масштабируемого набора runner.

Юридическая информация

Части были адаптированы в соответствии с http://github.com/actions/actions-runner-controller/ лицензией 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.