Изменить

Поделиться через

CI/CD для приложений AKS с помощью GitHub Actions и GitFlow

Реестр контейнеров Azure
Служба Azure Kubernetes (AKS)
Azure Monitor
Azure Pipelines

GitOps — это операционная модель для облачных приложений, которые хранят код приложения и декларативной инфраструктуры в Git, которые будут использоваться в качестве источника истины для автоматической непрерывной доставки. С помощью GitOps вы описываете требуемое состояние всей системы в репозитории Git, а оператор GitOps развертывает его в вашей среде, который часто является кластером Kubernetes. Дополнительные сведения о GitOps для Kubernetes в Azure см. в GitOps для Служба Azure Kubernetes или CI/CD и GitOps с поддержкой Azure Arc Kubernetes.

Пример сценария в этой статье применим к предприятиям, которые хотят модернизировать сквозную разработку приложений с помощью контейнеров, непрерывной интеграции (CI) для сборки и GitOps для непрерывного развертывания (CD). В этом сценарии приложение Flask используется в качестве примера. Это веб-приложение состоит из интерфейсного интерфейса, написанного с помощью Python и платформы Flask.

Архитектура

В следующих вариантах рассматриваются подходы ci/CD на основе принудительной отправки и извлечения.

Вариант 1. Ci/CD на основе push-уведомлений

Схема архитектуры на основе push-уведомлений с помощью GitHub Actions.

Архитектура на основе push-уведомлений с помощью GitHub Actions для CI и CD.

Скачайте файл Visio для этой архитектуры.

Поток данных

Этот сценарий охватывает конвейер DevOps на основе push-уведомлений для двухуровневого веб-приложения с интерфейсным веб-компонентом и серверной частью, использующим Redis. Этот конвейер использует GitHub Actions для сборки и развертывания. Данные передаются в сценарии следующим образом:

  1. Код приложения разработан.
  2. Код приложения фиксируется в репозитории GitHub Git.
  3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в Реестр контейнеров Azure.
  4. Задание GitHub Actions развертывает или отправляет приложение, как описано в файлах манифеста, в кластер Служба Azure Kubernetes (AKS) с помощью kubectl или действия развертывания в Kubernetes.

Вариант 2. Ci/CD на основе по запросу (GitOps)

Схема архитектуры на основе вытягивания с помощью GitHub Actions и Argo CD.

Архитектура на основе извлечения с помощью GitHub Actions для CI и Argo CD для CD.

Скачайте файл Visio для этой архитектуры.

Поток данных

Этот сценарий охватывает конвейер DevOps на основе по запросу для двухуровневого веб-приложения с интерфейсным веб-компонентом и серверной частью, использующим Redis. Этот конвейер использует GitHub Actions для сборки. Для развертывания он использует Argo CD в качестве оператора GitOps для извлечения и синхронизации приложения. Данные передаются в сценарии следующим образом:

  1. Код приложения разработан.
  2. Код приложения фиксируется в репозитории GitHub.
  3. GitHub Actions создает образ контейнера из кода приложения и отправляет образ контейнера в Реестр контейнеров Azure.
  4. GitHub Actions обновляет файл развертывания манифеста Kubernetes с текущей версией образа на основе номера версии образа контейнера в Реестр контейнеров Azure.
  5. Argo CD синхронизируется с репозиторием Git или извлекает из нее.
  6. Argo CD развертывает приложение в кластере AKS.

Компоненты

  • GitHub Actions — это решение автоматизации, которое может интегрироваться со службами Azure для непрерывной интеграции (CI). В этом сценарии GitHub Actions оркеструет создание новых образов контейнеров на основе фиксаций в системе управления версиями, отправляет эти образы в Реестр контейнеров Azure, а затем обновляет файлы манифеста Kubernetes в репозитории GitHub.
  • Служба Azure Kubernetes (AKS) — это управляемая платформа Kubernetes, которая позволяет развертывать контейнерные приложения и управлять ими без опыта оркестрации контейнеров. Размещенная в Azure служба Kubernetes отвечает за критические задачи, в частности за мониторинг работоспособности и техническое обслуживание.
  • Реестр контейнеров Azure хранит образы контейнеров и управляет ими, используемыми кластером AKS. Изображения надежно сохранены и могут быть реплицированы платформой Azure в другие регионы для ускорения развертывания.
  • GitHub — это веб-система управления версиями, которая работает в Git и используется разработчиками для хранения и версии кода приложения. В этом сценарии GitHub используется для хранения исходного кода в репозитории Git, а GitHub Actions используется для выполнения сборки и отправки образа контейнера для Реестр контейнеров Azure в подходе на основе push-уведомлений.
  • Argo CD — это оператор GitOps с открытым исходным кодом, который интегрируется с GitHub и AKS. Argo CD поддерживает непрерывное развертывание (CD). Flux можно было бы использовать для этой цели, но Argo CD демонстрирует, как команда приложений может выбрать отдельное средство для конкретных проблем жизненного цикла приложений, по сравнению с использованием того же средства, что операторы кластера, используемые для управления кластерами.
  • Azure Monitor помогает отслеживать производительность, обеспечивать безопасность и определять тенденции. Метрики, полученные Azure Monitor, могут использоваться другими ресурсами и инструментами, такими как Grafana.

Альтернативные варианты

  • Azure Pipelines помогает реализовать конвейер CI/DC и тестовый конвейер для любого приложения.
  • Jenkins — это сервер автоматизации с открытым исходным кодом, который может интегрироваться со службами Azure для CI/CD.
  • Flux можно использовать в качестве оператора GitOps. Он может выполнять те же задачи, что и Argo CD, и работает так же, как и с AKS.

Подробности сценария

В этом сценарии автоматизированная сборка и развертывание приложения использует несколько технологий. Код разработан в VS Code и хранится в репозитории GitHub. GitHub Actions используется для создания приложения в качестве контейнера, а затем отправки образа контейнера в Реестр контейнеров Azure. GitHub Actions используется для обновления необходимого файла развертывания манифеста Kubernetes, который также хранится в репозитории Git, а оператор GitOps Argo CD выбирает файлы манифеста Kubernetes и развертывает приложение в кластере AKS.

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

Используя службы Azure и GitHub, такие как AKS, Реестр контейнеров, GitHub и GitHub Actions, компании могут использовать новейшие методы разработки приложений и средства для упрощения процесса реализации высокой доступности. Кроме того, с помощью технологий с открытым исходным кодом, таких как Flux или Argo CD для GitOps, компании упрощают развертывание и применяют требуемое состояние приложений.

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

Другие варианты использования:

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

Параметры CI/CD

В этом документе демонстрируется использование GitOps для современного подхода к обработке непрерывного развертывания в конвейере CI/CD. Однако каждая организация отличается. При развертывании приложений в кластерах Kubernetes с помощью автоматизированных конвейеров доставки важно понимать различные способы его выполнения.

Два наиболее распространенных варианта CI/CD для развертывания приложения в кластере AKS основаны на принудительной отправке и извлечении. Параметр push-отправки использует GitHub Actions для непрерывного развертывания, а параметр извлечения использует GitOps для непрерывного развертывания.

Вариант 1. Архитектура на основе push-уведомлений с помощью GitHub Actions для CI и CD

В этом подходе код начинается с части CI конвейера, работающей в процессе отправки изменений в качестве развертываний в кластер Kubernetes. Развертывания основаны на триггере. Существуют различные триггеры, которые могут запустить развертывание, например фиксации в репозитории или триггере из другого конвейера CI. Благодаря этому подходу система конвейера имеет доступ к кластеру Kubernetes. Модуль на основе push-уведомлений является наиболее распространенной моделью, используемой сегодня средствами CI/CD.

Причины использования подхода на основе push-уведомлений:

  • Гибкость. Большинство операторов GitOps в настоящее время выполняются только в Kubernetes. Если ваша организация хочет развернуть приложения в других приложениях, отличных от Kubernetes, необходимо отправить приложение в эту среду с помощью других средств CI/CD, таких как GitHub Actions.

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

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

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

Вариант 2. Архитектура на основе вытягивания с помощью GitHub Actions для ci и GitOps оператора Argo CD для CD

Этот подход сосредоточен на применении любых изменений из кластера Kubernetes. Кластер Kubernetes включает в себя оператор, который сканирует репозиторий Git для требуемого состояния кластера, сбора и применения любых изменений, которые необходимо выполнить. В этой модели внешний клиент не имеет учетных данных уровня администратора в кластере Kubernetes. Модель извлечения не является новой, но не была широко использована средствами CI/CD. Недавно, с введением GitOps, модель по запросу получила внедрение. Многие организации использовали GitOps для обеспечения непрерывного развертывания в конвейерах CD/CD.

Причины использования подхода на основе вытягивания:

  • Согласованность. С помощью GitOps оператор сравнивает состояние кластеров Kubernetes с требуемым состоянием конфигурации и приложений в репозитории Git. Если в конфигурации или приложениях есть смещение, оператор GitOps автоматически возвращает кластер Kubernetes к требуемому состоянию.

  • Безопасность: подход на основе вытягивания к CI/CD с помощью GitOps позволяет перемещать учетные данные безопасности в кластер Kubernetes, что снижает уровень безопасности и риска, удаляя учетные данные из внешнего инструмента CI. Кроме того, вы сможете уменьшить разрешенные входящие подключения и ограничить доступ на уровне администратора к кластерам Kubernetes.

  • Управление версиями. Так как GitOps использует репозиторий Git в качестве источника истины, непрерывное развертывание изначально имеет возможности управления версиями, отката и аудита.

  • Многотенантность: подход на основе извлечения с GitOps хорошо подходит для распределенных команд и многотенантности. С помощью GitOps можно использовать отдельные репозитории Git, отдельные права доступа и распространять развертывания в разных пространствах имен.

  • Облачная машинная среда: все больше приложений модернизируются или создаются для использования в облаке. Для любой организации, которая имеет большую часть своих приложений, работающих в Kubernetes, использование оператора GitOps для непрерывного развертывания проще и эффективнее, чем традиционный подход на основе push-уведомлений к CI/CD.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Надежность

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

Чтобы отслеживать производительность приложения и сообщать о проблемах, в этом сценарии используется Azure Monitor. Он позволяет отслеживать и устранять проблемы с производительностью, которые могут потребовать обновления кода, которые затем можно развернуть с помощью конвейера CI/CD.

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

Примечание.

В этой статье нет прямого обращения к конвейеру CI/CD с высоким уровнем доступности. Дополнительные сведения см. в разделе "Высокий уровень доступности" для GitHub Actions и Argo CD Декларативный cd GitOps для Kubernetes.

Компоненты устойчивости встроены в Kubernetes. Эти компоненты отслеживают и перезапускать контейнеры или модули pod, если возникла проблема. При объединении нескольких узлов Kubernetes приложение может терпеть недоступность модуля pod или узла.

Общее руководство по проектированию устойчивых решений см. в разделе Разработка надежных приложений Azure.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Для разделения учетных данных и разрешений этот сценарий использует выделенный субъект-службу Microsoft Entra. Учетные данные для этого субъекта-службы хранятся как безопасный объект учетных данных в GitHub, как секреты GitHub Actions, чтобы они не были напрямую предоставлены и видимы в скриптах или конвейере сборки.

Общие рекомендации по защите приложений в кластерах AKS см . в концепциях безопасности приложений и кластеров в AKS.

Для разделения проблем рекомендуется разделить вычислительные ресурсы, которые выполняют бизнес-приложение от агентов CD или оператора GitOps, запустив бизнес-приложение и оператор GitOps в отдельных пространствах имен в кластере Kubernetes. Для дальнейшего разделения проблем оператор GitOps можно запускать в кластере Kubernetes, выделенном для экземпляра GitOps, отдельно от рабочего кластера Kubernetes, который запускает бизнес-приложение.

Примечание.

В этой статье нет прямого обращения к защите конвейера CI/CD.

Оптимизация производительности

Уровень производительности — это способность вашей рабочей нагрузки эффективно масштабироваться в соответствии с требованиями, предъявляемыми к ней пользователями. Дополнительные сведения см. в разделе "Общие сведения о эффективности производительности".

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

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

Дополнительные сведения о масштабируемости см. в контрольном списке эффективности производительности.

Развертывание этого сценария

Выполните действия, описанные в реализации эталонной модели AKS-baseline-automation, чтобы развернуть сценарий. Репозиторий эталонной реализации содержит пошаговое руководство по сценариям CI/CD на основе push-уведомлений и сценария ci/CD на основе извлечения (GitOps).

Соавторы

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

Основные авторы:

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

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

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

Документация по продукту:

Модули Microsoft Learn.