Переход от самостоятельных раннеров к бегунам на GitHub

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

Этот урок показывает, как оценить текущее использование раннеров, а затем эффективно перенести рабочие процессы с самостоятельных раннеров на GitHub-хостируемых раннеров.

1. Оцените текущую инфраструктуру CI

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

1. Создайте инвентарь каждой спецификации машины, используемых для выполнения рабочих процессов, включая ядра процессора, оперативную память, хранение, архитектуру чипа и операционную систему.
2. Обратите внимание, если кто-то из бегунов относится к группе бегунов или имеет ли это ярлык. Эту информацию можно использовать для упрощения миграции рабочих процессов на новых пользователей.
3. Документируйте любые пользовательские изображения и предустановленные зависимости, на которые опираются рабочие процессы, так как они повлияют на вашу стратегию миграции.
4. Определите, какие рабочие процессы сейчас ориентированы на самостоятельных пользователей и почему. Например, в метриках использования GitHub Actions используйте вкладку Jobs и фильтруйте по метке runner (например self-hosted , или по пользовательской метке), чтобы увидеть, какие репозитории и задания используют эту метку. Если нужно проверить конкретные файлы рабочих процессов, можно использовать поиск по коду для поиска файлов рабочих процессов, которые ссылаются runs-on: self-hosted на другие самостоятельные метки.
5. Определите рабочие процессы, которые получают доступ к частным сетевым ресурсам (например, внутренним реестрам пакетов, частным API, базам данных или локальным сервисам), поскольку они могут потребовать дополнительной сетевой конфигурации.

2. Сопоставьте ваши требования к обработке с типами раннеров GitHub

GitHub предлагает управляемые раннеры в нескольких операционных системах — Linux, Windows и macOS — с опциями для машин с поддержкой GPU. См . раздел AUTOTITLE.

1. Сопоставьте каждую отдельную спецификацию машины в вашем инвентаре с подходящей спецификацией запуска GitHub.
2. Запишите любые самостоятельные раннеры, где нет подходящих GitHub-hosted runner.
3. Исключите из ваших планов миграции все рабочие процессы, которые должны продолжать работать на самостоятельных раннерах.

3. Оценка требований к ёмкости

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

1. В правом верхнем углу GitHub, щелкните рисунок профиля, а затем выберите октикона "организация" aria-hidden="true" aria-label="organization" %} Ваши организации.

2. Щелкните название своей организации.

3. Под именем организации щелкните Insights.

   

4. В меню навигации «Инсайты» нажмите «Метрики использования действий».

5. Щелкните вкладку, содержащую метрики, которые вы хотите просмотреть. См . раздел AUTOTITLE.

6. Изучите следующие данные, чтобы оценить вместимость размещенных бегунов:

   •      **Общее количество затраченных минут**: помогает оценить базовый спрос на вычисления.
     

   •      **Количество запусков рабочих процессов**: Определяет периоды пиковой активности, которые могут потребовать большей параллелизации.
     

   •      **Распределение заданий между типами ОС**: обеспечивает правильное сочетание Linux, Windows и macOS для запуска.
     

   •      **Метки бегущих (вкладка Jobs):** фильтруйте по метке бегуна, чтобы понять, где используется эта метка.
     

7. Преобразуйте свои результаты в план пропускной способности:

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

8. Запишите любые пробелы:

   • Рабочие процессы с жёсткими зависимостями, которые ваши текущие размещённые изображения бегущих не поддерживают.
   • Работы с необычно долгим сроком выполнения или индивидуальными потребностями в условиях. (Возможно, для них понадобятся кастомные изображения.)

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

4. Настройте группы и политики раннеров

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

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

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

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

2. Добавьте новых GitHub в соответствующую группу и установите лимиты на параллельность на основе выявленных на шаге 3. Подробности об автоматическом масштабировании см. Управление большими бегунами.

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

5. Настройте GitHub-hosted runners

Далее подготовьте ваши GitHub-хостируемые раннеры на основе типов машин и пропускной способности, которые вы ранее определили.

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

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

3. Выберите тип изображения:

   • Используйте GitHubуправляемые изображениями для поддерживаемой, часто обновляемой среды.
   • Используйте пользовательские образы, когда нужны предустановленные зависимости, чтобы сократить время настройки. См . раздел AUTOTITLE.

4. Применяйте необходимые настройки, такие как переменные среды, установка программного обеспечения или скрипты запуска. Для дополнительных примеров см. АВТОЗАГОЛОВОК.

5. По желанию настройте частную сеть, если участникам необходим доступ к внутренним ресурсам. См . раздел AUTOTITLE.

Настройка опций приватного подключения

Если вашим рабочим процессам необходим доступ к частным ресурсам (например, внутренним реестрам пакетов, приватным API, базам данных или локальным сервисам), выберите подход, соответствующий требованиям вашей сети и безопасности.

Configure Azure Private Networking

Run GitHub-hosted runners внутри Azure Virtual Network (VNET) для безопасного доступа к внутренним ресурсам.

1. Создайте Azure Virtual Network (VNET) и настройте подсети и группы сетевой безопасности для ваших участников.
2. Включите Azure private networking для вашей группы бегущих. См. раздел AUTOTITLE
3. Применяйте сетевые конфигурации, такие как NSG и правила межсетевого экрана, для управления входом и выходом трафика.
4. Обновите таргетинг рабочих процессов, чтобы использовать группу раннеров, настроенную для частных сетей.

Подробные инструкции см. в следующих разделах:

•         [AUTOTITLE](/organizations/managing-organization-settings/configuring-private-networking-for-github-hosted-runners-in-your-organization)
  

•         [AUTOTITLE](/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/configuring-private-networking-for-github-hosted-runners-in-your-enterprise)
  

Подключайтесь через оверлейную сеть WireGuard

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

Для подробных инструкций и примеров см. АВТОТИТРЫ.

Используйте OIDC с API-шлюзом для доверенного доступа к частным ресурсам

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

Для подробных инструкций и примеров см. АВТОТИТРЫ.

6. Обновить рабочие процессы для использования новых раннеров

После того как ваши GitHub будут настроены раннеры, обновите ваши рабочие процессы, чтобы они их таргетировали.

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

2. Если вы создали новые группы или метки раннеров, обновите поле runs-on в YAML-файлах вашего рабочего процесса. Рассмотрим пример.

   jobs:
     build:
       runs-on: [github-larger-runner, linux-x64]
       steps:
         - name: Checkout code
           uses: actions/checkout@v5
         - name: Build project
           run: make build
   

3. Проверьте наличие жёстко закодированных ссылок на самостоятельные метки (например self-hosted, linux-x64, или пользовательские метки) и замените их соответствующими метками GitHub-hosted runner labels.

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

7. Убрать неиспользуемые самостоятельные бегунки

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

Прежде чем удалять самостоятельные раннеры, убедитесь, что вы полностью переместились:

• В метриках использования GitHub Actions используйте вкладку Jobs и фильтруйте по метке runner (например, или по вашим пользовательским меткам), чтобы убедиться, что self-hosted ни один репозитории или задания не используют самостоятельные раннеры.