Как использование собственных GitHub Runners может сэкономить вам состояние

GitHub позволяет запускать GitHub Actions с помощью собственных собственных средств выполнения. Благодаря Контроллеру выполнения действий выполнять действия в кластерах Kubernetes на удивление легко.

В этом посте мы покажем, как установить контроллер Actions Runner Controller в существующий кластер Kubernetes, чтобы запускать настроенные средства выполнения с минимальными затратами.

:::информация Отказ от ответственности: я являюсь частью команды Symbiosis.

:::

Зачем использовать автономные бегуны?

В Symbiosis мы проводим множество тестов для каждого коммита, поэтому мы потратили много времени на то, чтобы убедиться, что они работают быстро и могут выполнять сложные интеграционные тесты.

Таким образом, использование собственных средств выполнения GitHub не идеально, так как средний коммит обойдется нам почти в доллар каждый, и, к сожалению, мы вносим множество мелких изменений.

Таким образом, мы могли либо заплатить 40 долларов за 5000 минут двухпроцессорного github runner. Или мы могли бы заплатить 2 доллара США за аренду узла Kubernetes с 2 ЦП и 8 ГБ на 5000 минут и вместо этого выполнять на нем наши действия.

И, как мы видим ниже, мы также можем настроить наши бегуны, чтобы добавить еще больше гибкости по сравнению со стандартными бегунами GitHub, сильно изменив среду выполнения.

Предпосылки

Чтобы следовать этому руководству, вам необходимо:

* Кластер Kubernetes * Вход NGINX (или любой другой контроллер входа) * Certmanager (необязательно)

Установка контроллера запуска Actions

Actions Runner Controller (ARC) — это служба, отвечающая за мониторинг выбранных вами репозиториев и запуск новых исполнителей.

Мы покажем вам, как установить его с помощью kubectl, но использовать helm так же просто.

kubectl create -f https://github.com/actions-runner-controller/actions-runner-controller/releases/download/v0.25.2/actions-runner-controller.yaml

Подключение контроллера Actions Runner к GitHub

Итак, у нас работает контроллер, и это здорово. Теперь нам нужно аутентифицироваться, чтобы коммиты, PR, комментарии или любые другие события могли быть получены контроллером и вызвать запуск бегуна.

У нас есть два варианта: либо мы можем создать токен личного доступа (PAT) с правами администратора на наши репозитории, либо мы можем создайте приложение github и вместо этого установите его в репозиторий.

Для простоты мы будем аутентифицироваться с помощью PAT.

Токен личного доступа (PAT)

Создайте токен в разделе "Настройки" > Настройки разработчика > Токен личного доступа. Убедитесь, что у вас есть доступ с правами администратора к репозиториям, на которых будут работать ваши бегуны.

Выберите разрешение repo (полный доступ), и если ваши бегуны будут работать в организации, вам также необходимо выбрать следующие разрешения:

* admin:org (Полный доступ) * admin:public_key (читай:public_key) * администратор:repo_hook (читай:repo_hook) * admin:org_hook (Полный доступ) * уведомления (Полный контроль) * рабочий процесс (полный доступ)

Далее давайте сохраним только что созданный токен в секрете, который наш контроллер может использовать для аутентификации.

kubectl create secret generic controller-manager 
    --namespace=actions-runner-system 
    --from-literal=github_token=<YOUR PERSONAL ACCESS TOKEN>

Создание рабочего процесса

Прежде чем мы двинемся дальше, возможно, самое время создать настоящий рабочий процесс, который в конечном итоге запустит наш автономный бегун.

name: Run test on PRs
on:
  pull_request: {}
jobs:
  test:
    name: "Run tests"
    runs-on: [self-hosted]
    steps:
    - name: Checkout repo
      uses: actions/checkout@master
    - name: Run tests
      run: yarn test

Этот рабочий процесс инициирует выполнение запросов на вытягивание и запускает yarn test. Давайте поместим его в .github/workflow/test-workflow.yaml и отправим изменения в наш репозиторий.

Обратите внимание на параметр runs-on: [self-hosted], который указывает GitHub выбрать любой из ваших собственных автономных исполнителей. Не волнуйтесь, вы можете уточнить, какой тип бегунка использовать. Подробнее об этом позже.

Веб-перехватчик & Вход

Бегуны могут срабатывать на основе механики толкания или вытягивания. Например, путем опроса или настройки веб-перехватчиков. Большинство триггеров имеют определенные недостатки: некоторые порождают слишком много бегунов, а некоторые — слишком мало, что может поставить ваши действия в очередь с медленным движением.

Однако есть триггер workflowJob, который не имеет ни одного из этих недостатков, но требует от нас создания Ingress и настройки веб-перехватчика GitHub. Так что этот шаг не является строго обязательным, но мы можем заверить вас, что это стоит затраченных усилий.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: actions-runner-controller-github-webhook-server
  namespace: actions-runner-system
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
spec:
  tls:
  - hosts:
    - your.domain.com
    secretName: your-tls-secret-name
  rules:
  - http:
      paths:
      - path: /actions-runner-controller-github-webhook-server
        pathType: Prefix
        backend:
          service:
            name: actions-runner-controller-github-webhook-server
            port:
              number: 80

Этот вход настроен для входа NGINX, поэтому обязательно отредактируйте его в зависимости от вашего контроллера входа. Также предполагается, что диспетчер сертификатов настроен на автоматическую подготовку сертификата TLS.

Следующим шагом является определение веб-перехватчика в GitHub. Перейдите в Настройки > Веб-перехватчики > Добавьте веб-перехватчик в целевой репозиторий.

Сначала давайте установим URL-адрес полезной нагрузки, указывающий на вход, например, используя данные выше: https:/ /your.domain.com/actions-runner-controller-github-webhook-server. Установите тип содержимого json и включите разрешение Задания рабочего процесса.

Когда это будет сделано, вы можете создать веб-перехватчик и перейти к Последние доставки, чтобы убедиться, что входящий трафик может быть успешно достигнут.

Прослушивание событий

У нас работает контроллер, он аутентифицирован, и у нас есть рабочий процесс. Осталось только создать настоящие бегуны.

Теперь мы могли бы просто создать ресурс Runner и покончить с ним, но, как и в случае с модулем, у него не было бы ни реплик, ни автоматического масштабирования.

Вместо этого мы создаем RunnerDeployment и HorizontalRunnerAutoscaler. И для любого пользователя Kubernetes вы заметите много общего с обычными развертываниями и HPA.

apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: actions-runners
spec:
  template:
    spec:
      repository: myorg/myrepo
---
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
  name: actions-runners
spec:
  minReplicas: 0
  maxReplicas: 5
  scaleTargetRef:
    kind: RunnerDeployment
    name: actions-runners
  scaleUpTriggers:
  - githubEvent:
      workflowJob: {}
    duration: "30m"

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

Вуаля! Теперь мы можем создать запрос на вытягивание, чтобы убедиться, что бегун запускается автоматически.

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

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

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

apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: actions-runners
spec:
  template:
    spec:
      repository: myorg/myrepo
      labels:
      - my-label

С помощью этого ярлыка мы можем выбрать этот бегун, установив как self-hosted, так и my-label в нашем рабочем процессе:

name: Run test on PRs
on:
  pull_request: {}
jobs:
  test:
    name: "Run tests"
    runs-on: [self-hosted, my-label]
    steps:
    - name: Checkout repo
      uses: actions/checkout@master
    - name: Run tests
      run: yarn test

Настройка бегунов с пользовательскими объемами

Средства выполнения можно настроить для передачи томов из хост-системы или для присоединения PVC к средствам выполнения.

В Symbiosis мы используем PVC для демонстрации KVM нашим исполнителям, чтобы запускать интеграционные тесты с включенной виртуализацией. Мы также используем PVC для прикрепления больших образов, которые используются для настройки многопользовательской облачной среды для интеграционного тестирования.

Пользовательские тома также можно использовать для кэширования слоев, чтобы повысить скорость создания образов OCI.

Приведенный ниже бегун предоставит общий PVC 10Gi. Обратите внимание, что мы используем RunnerSet вместо RunnerDeployment. Этот ресурс работает так же, как StatefulSet, поскольку он размещает исполнителя на узле, где том может быть правильно смонтирован.

apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: actions-runners
spec:
  template:
    spec:
      repository: myorg/myrepo
      volumeMounts:
      - mountPath: /runner/work
        name: pvc
      volumes:
      - name: pvc
        ephemeral:
          volumeClaimTemplate:
            spec:
              accessModes: [ "ReadWriteOnce" ]
              resources:
                requests:
                  storage: 10Gi

Этот PVC можно использовать для хранения любых данных, которые нам нужны между запусками, без необходимости хранить излишне большой объем данных в кеше действий GitHub! На момент написания этой статьи 100 ГБ хранилища с использованием бегунов GitHub стоили 24 доллара в месяц. С поставщиками облачных услуг, такими как Linode, Symbiosis или Scaleway, эта стоимость будет ближе к 8 долларам США в месяц.

Подводя итоги

Запуск собственных бегунов действий требует некоторой предварительной настройки, но имеет ряд преимуществ, таких как:

* Снижение затрат * Прикрепление пользовательских томов (таких как путь к хосту или PVC) к вашим бегунам * Настройка изображений или добавление коляски * Интеграция рабочего процесса с существующим стеком наблюдения Kubernetes

Поэтому мы настоятельно рекомендуем запускать собственные средства выполнения, чтобы сократить расходы, упростить управление и повысить гибкость за счет включения средств выполнения в экосистему Kubernetes.

Ознакомьтесь с Symbiosis [здесь]

Ведущий образ создан со стабильной диффузией.

Также опубликовано здесь