Справочник по локальным запускам

Требования для компьютеров локальных средств выполнения тестов

Вы можете использовать компьютер в качестве локального runner до тех пор, пока он соответствует следующим требованиям:

• На этом компьютере можно установить и запустить приложение локального средства выполнения тестов. См. сведения о поддерживаемых операционных системах и поддерживаемых архитектурах процессора.
• Машина может общаться с GitHub Actions.
• На компьютере достаточно аппаратных ресурсов для того типа рабочих процессов, которые вы планируете запускать. Само приложение локального средства выполнения тестов требует только минимальных ресурсов.
• Если вы хотите запускать рабочие процессы, использующие действия контейнеров Docker или контейнеры служб, необходимо использовать компьютер Linux и установить Docker.

Поддерживаемые операционные системы

Linux

• Red Hat Enterprise Linux 8 или более поздней версии
• CentOS 8 или более поздней версии
• Oracle Linux 8 или более поздней версии
• Fedora 29 или более поздней версии
• Debian 10 или более поздней версии
• Ubuntu 20.04 или более поздней версии
• Linux Mint 20 или более поздней версии
• openSUSE 15.2 или более поздней версии
• SUSE Enterprise Linux (SLES) 15 с пакетом обновления 2 (SP2) или более поздней версии

Windows

• Windows 10 64-разрядная версия
• Windows 11 64-разрядная версия
• Windows Server 2016, 64-разрядная версия
• Windows Server 2019 64-разрядная
• Windows Server 2022 64-разрядная версия

macOS

• macOS 11.0 (Big Sur) или более поздней версии

Поддерживаемые архитектуры процессора

• x64 — Linux, macOS, Windows.
• ARM64 - Linux, macOS, Windows (сейчас в Публичный предварительный просмотр).
• ARM32 -Линукс.

Приоритет маршрутизации для локальных средств выполнения

При маршрутизации задания к самостоятельно размещённому раннеру GitHub ищете раннера, который соответствует меткам и группам runs-on работы:

• Если GitHub найдётся онлайн-и бездействующий бегущий, соответствующий меткам и группам runs-on вакансии, задание назначается и отправляется раннеруну.
  • Если средство выполнения не принимает назначенное задание в течение 60 секунд, задание снова ставится в очередь для поиска нового средства выполнения.
• Если GitHub не найдётся онлайн-и бездействующий бегунок, соответствующий меткам и группам runs-on вакансии, работа останется в очереди до тех пор, пока не появится беглитель.
• После нахождения в очереди в течение 24 часов задание завершается сбоем.

Автомасштабирование

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

Actions Runner Controller

GitHub-Размещённые бегуны автоматически масштабируются в зависимости от ваших потребностей. GitHub-Размещённые раннеры могут быть низкозатратной и экономически эффективной альтернативой разработке или внедрению решений для автомасштабирования. Дополнительные сведения см. в разделе Средства выполнения тестов, размещенные в GitHub.

Actions Runner Controller (ARC) — это эталонная GitHubреализация API масштабных наборов и рекомендуемое решение на базе Kubernetes для автомасштабирования самостоятельных раннеров. ARC предоставляет полное, готовое к производству решение для автомасштабирования для команд, работающих GitHub Actions в средах Kubernetes.

GitHub рекомендует ARC для организаций с инфраструктурой Kubernetes и команд, обладающих экспертизой Kubernetes. ARC управляет полным жизненным циклом раннеров в вашем кластере — от провизии до выполнения заданий и очистки.

Дополнительные сведения см. в разделе [AUTOTITLE и Контроллер runner действий](/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-support-for-actions-runner-controller).

GitHub Actions Клиент набора Runner Scale

Клиент Runner Scale Set — это автономный модуль на базе Go, который даёт возможность командам платформ, интеграторам и поставщикам инфраструктуры создавать собственные решения для автомасштабирования для <c1 / > раннеров на виртуальных машинах, контейнерах, локальной инфраструктуре и облачных сервисах, с поддержкой платформ Windows, Linux и macOS.

Клиент организует GitHub взаимодействия API для масштабных наборов, оставляя инфраструктуру на ваше усмотрение. Вы определяете, как создаются, масштабируются и уничтожаются раннеры, а также настраиваете раннеров с несколькими метками для гибкой маршрутизации и таргетинга заданий. Это даёт организациям детальный контроль над управлением жизненным циклом бегуна и телеметрией в реальном времени для выполнения задач.

Клиент разработан так, чтобы работать сразу с базовыми конфигурациями, что позволяет командам быстро реализовать автомасштабирование. Однако её истинная сила заключается в гибкости — клиент создан для расширения и настройки с учётом специфических инфраструктурных требований каждой организации, ограничений по соответствию и операционным рабочим процессам. Независимо от того, нужна ли вам простая логика масштабирования или сложные стратегии мульти-окружного провидения, клиент адаптируется под ваши потребности.

Клиент Runner Scale Set GitHub Actions — это открытый код проект. Репозиторий действий/масштабирования содержит полный исходный код, исчерпывающую документацию и практические примеры, которые помогут вам начать. Вы найдёте руководства по внедрению, примеры конфигураций для различных инфраструктурных сценариев и эталонные архитектуры, показывающие, как интегрировать клиента с разными системами предоставления услуг. Репозиторий также включает рекомендации для команд, заинтересованных в расширении клиента или обмене своими паттернами автомасштабирования с сообществом.

Примечание: Клиент Runner Scale Set не заменяет Actions Runner Controller (ARC), который остаётся эталонной реализацией API масштабных наборов и рекомендуемым решением Kubernetes для автомасштабирования раннеров. Вместо этого клиент — это дополнительный инструмент для взаимодействия с одинаковыми масштабными API для создания собственных решений для автомасштабирования вне Kubernetes.

Временные бегуны для автомасштабирования

GitHub рекомендует реализовать автомасштабирование с помощью эфемерных самостоятельных раннеров; Автомасштабирование с постоянными саморазмещёнными раннерами не рекомендуется. В некоторых случаях GitHub нельзя гарантировать, что задачи не будут назначены постоянным курьерам во время их закрытия. С эфемерными бегунами это гарантировано, потому что GitHub для бегуна назначается только одна задача.

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

Чтобы добавить в вашу среду временное средство выполнения, включите параметр --ephemeral при регистрации средства выполнения с помощью config.sh. Например:

./config.sh --url https://github.com/octo-org --token example-token --ephemeral

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

Кроме того, вы можете создавать временные и JIT-бегуны с помощью REST API. Дополнительные сведения см. в разделе Конечные точки REST API для локальных runners.

Обновления программного обеспечения runner для локальных runners

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

Чтобы отключить автоматическое обновление программного обеспечения и устанавливать обновления программного обеспечения самостоятельно, укажите флаг --disableupdate при регистрации средства выполнения с помощью config.sh. Например:

./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate

Если автоматические обновления отключены, необходимо регулярно обновлять версию средства выполнения. Новая функциональность требует GitHub Actions изменений как GitHub Actions в сервисе, так и в программном обеспечении для запуска. Раннер может не иметь возможности корректно обрабатывать задания с новыми функциями GitHub Actions без обновления программного обеспечения.

Если вы отключаете автоматическое обновление, то должны будете обновлять версию средства выполнения в течение 30 дней после того, как станет доступной новая версия. Вы можете подписаться на уведомления о выпусках в репозиторииactions/runner. Дополнительные сведения см. в разделе Настройка уведомлений.

Инструкции по установке последней версии средства выполнения см. в инструкциях по установке последнего выпуска.

Веб-перехватчики для автомасштабирования

Вы можете создать собственную среду автомасштабирования с помощью полезных данных, полученных от веб-перехватчика workflow_job. Этот веб-перехватчик доступен на уровне репозитория, организации и предприятия, а полезные данные для этого события содержат ключ action, соответствующий этапам жизненного цикла задания рабочего процесса, например, когда задания queued, in_progress и completed. Затем вы должны создать собственную автоматизацию масштабирования в ответ на эти полезные данные веб-перехватчика.

• Дополнительные сведения о веб-перехватчике см. в workflow_job разделе События и полезные данные веб-перехватчика.
• Сведения о работе с веб-перехватчиками см. в разделе Документация по веб-перехватчикам.

Примечание: Этот подход основан на своевременности доставки webhook для принятия решений о масштабировании, что может привести к задержкам и проблемам с надёжностью. Рассмотрите возможность использования Actions Controller или Scale Set Client для сценариев автомасштабирования больших объемов.

Требования к проверке подлинности

Вы можете регистрировать и удалять репозиторий и локальные средства выполнения организации с помощью API. Для аутентификации в API ваша реализация автомасштабирования может использовать токен доступа или приложение GitHub .

Для маркера доступа потребуется следующая область.

• Для частных репозиториев используйте маркер доступа с областьюrepo.
• Для общедоступных репозиториев используйте маркер доступа с областьюpublic_repo.
• Для организаций используйте маркер доступа с областьюadmin:org.

Для аутентификации с помощью GitHub приложения ему должны быть назначены следующие права:

• Для репозиториев назначьте разрешение administration.
• Для организаций назначьте разрешение organization_self_hosted_runners.

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

Для маркера доступа потребуется область manage_runners:enterprise.

Коммуникации

Самостоятельные бегуны подключаются, экземпляр GitHub Enterprise ServerGitHub чтобы получать задания и скачивать новые версии приложения для бегуна.

Приложение средства запуска GitHub Actions предоставляется с открытым кодом. Сведения о проблемах можно внести в репозиторий средства выполнения. При выпуске новой версии приложение Runner автоматически обновляется при назначении задания на раннера или в течение недели после релиза, если раннеру не назначены задачи.

Требования к общению с GitHub

• Самостоятельное приложение runner должно работать на хост-машине, чтобы принимать и выполнять GitHub Actions задачи.
• Хост-компьютер должен иметь соответствующий сетевой доступ с по крайней мере 70 килобит в секунду отправкой и скоростью загрузки.
• Хост-компьютер должен иметь возможность выполнять исходящие HTTPS-подключения через порт 443.
• В зависимости от функций рабочих процессов, назначенных вашему самостоятельно размещённому раннеру, хост-машина должна иметь возможность взаимодействовать с GitHub перечисленными ниже доменами.

Доступные домены по функциям

Требуется для основных операций:

github.com
api.github.com
*.actions.githubusercontent.com

github.com
api.github.com
*.actions.githubusercontent.com

Требуется для загрузки действий:

codeload.github.com

codeload.github.com

Требуется для отправки и скачивания сводок заданий, журналов, артефактов рабочих процессов и кэшей:

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

Требуется для обновления версий средства выполнения тестов:

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

Требуется для получения маркеров OIDC:

*.actions.githubusercontent.com

*.actions.githubusercontent.com

Необходимо для скачивания или публикации пакетов или контейнеров в GitHub пакеты:

*.pkg.github.com
pkg-containers.githubusercontent.com
ghcr.io

*.pkg.github.com
pkg-containers.githubusercontent.com
ghcr.io

Нужен для Хранилище больших файлов Git

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

Требуется для работы Dependabot updates

dependabot-actions.githubapp.com

dependabot-actions.githubapp.com

Требуется для скачивания ресурсов выпуска:

release-assets.githubusercontent.com

release-assets.githubusercontent.com

Требуется для виртуальной сети:

api.snapcraft.io

api.snapcraft.io

Кроме того, рабочему процессу может потребоваться доступ к другим сетевым ресурсам.

Если вы используете список разрешённых IP-адресов для вашей GitHub организации или корпоративной учетной записи, вы должны добавить IP-адрес самостоятельного пользователя в список разрешений. См. разделы «Управление разрешёнными IP-адресами для вашей организации» или «Применение политик для настроек безопасности в вашем предприятии» в документации.