Развертывание высокодоступных GitHub Actions на службе Azure Kubernetes (AKS) с использованием Azure Files.

В этом руководстве вы развернете контроллер GitHub Actions с высоким уровнем доступности и локальные агенты, работающие в службе Azure Kubernetes (AKS). Локальные средства выполнения используют общие папки Azure SMB для постоянного хранения.

Это важно

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

Корпорация Майкрософт несет ответственность за создание пакетов с открытым кодом, которые мы развертываем в AKS. Эта ответственность включает полное управление процессами сборки, сканирования, подписывания, проверки и исправления ошибок, а также контроль над двоичными файлами в образах контейнеров. Для получения дополнительной информации см. Управление уязвимостями в AKS и Покрытие поддержки AKS.

Что такое Actions Runner Controller (ARC)?

Actions Runner Controller (ARC) — это оператор Kubernetes, который управляет и масштабирует самостоятельно размещаемые агенты выполнения для GitHub Actions. Arc использует постоянные тома (PV) для совместного использования сведений о задании между модулем runner и модулем задания контейнера. Дополнительные сведения см. в разделе "О контроллере запуска действий".

Почему в AKS используется локальная служба GitHub Actions?

Самостоятельное размещение GitHub Actions в AKS обеспечивает организациям больший контроль, масштабируемость и безопасность в инфраструктуре CI/CD. Вместо того чтобы полагаться на размещенные в GitHub исполнители, которые являются общими и временными, собственные исполнители предлагают:

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

Распространенные варианты использования

  • Конвейеры CI/CD для предприятий: для команд, которым необходимы согласованные, безопасные и масштабируемые среды сборки.
  • Крупные монорепозитории или ML-конвейеры: где кэширование или сохранение артефактов критично.
  • Оптимизация производительности: Использование премиальных SMB-ресурсов Azure Files для снижения задержки метаданных и увеличения количества операций ввода-вывода в секунду (IOPS).

Предпосылки

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

Процесс развертывания

В этом руководстве вы узнаете, как:

  • Используйте Azure CLI для создания кластера AKS с несколькими зонами.
  • Разверните файловое хранилище Azure для использования в постоянных томах AKS.
  • Установите контроллер GitHub Actions Runner (ARC) на AKS.
  • Установите набор масштабируемых экземпляров ARC Runners и подключите общий доступ к файлам в AKS.
  • Запустите пример рабочего процесса с помощью GitHub Actions.

Архитектура развертывания

Эта эталонная архитектура иллюстрирует реализацию решения локального запуска GitHub Actions с помощью AKS и общей папки Azure (SMB). Это решение позволяет организациям безопасно выполнять задания рабочих процессов GitHub в собственной инфраструктуре Azure, обеспечивая эффективное управление хранилищем и масштабируемость.

Снимок экрана: схема архитектуры для GitHub Actions с файлами Azure в AKS.

Архитектура состоит из трех основных компонентов:

  1. Уровень интеграции GitHub: подключает рабочие процессы из репозиториев GitHub к инфраструктуре Azure.
  2. Уровень оркестрации AKS: управляет контейнерными экземплярами runner и их жизненным циклом.
  3. Уровень хранилища: Предоставляет постоянные и эфемерные возможности хранения для исполнителей.

Уровень интеграции GitHub

Уровень интеграции GitHub подключает рабочие процессы из репозиториев GitHub к инфраструктуре Azure. Задания рабочего процесса отправляются из GitHub через api.github.com и githubusercontent.com в локальные runners.

Уровень оркестрации кластера AKS

Уровень оркестрации кластера AKS управляет контейнеризированными экземплярами runner и их жизненным циклом. Кластер разделен на два пространства имен: arc-controller и arc-runners.

arc-controller управляет инфраструктурой runner и прослушивателями заданий. arc-runners обрабатывает секреты, управление доступом и модули pod runner. Исполнители контейнеризированы, используют временное хранилище и подключаются к общим и выделенным томам.

Уровень хранилища

Уровень хранилища общих папок Azure предоставляет общий файловый ресурс NuGet с ReadWriteMany доступом к общим зависимостям и эфемерному хранилищу для агентов, которые поддерживаются заявками на постоянный объём.

Следующий шаг

Создание инфраструктуры для развертывания высокодоступных действий GitHub в AKS

Соавторы

Корпорация Майкрософт поддерживает эту статью. Первоначальная версия была написана следующими участниками:

  • Хорхе Артерио | Старший адвокат по облачным технологиям
  • Джефф Паттерсон | Главный диспетчер продуктов
  • Рена Шах | Старший менеджер по продуктам
  • Шехар Сингх Сорот | Product Manager 2
  • Эрин Шаффер | Разработчик содержимого 2
  • Последнее обновление: