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

Создание конвейера CI/CD для приложений AKS с помощью Azure Pipelines

Это важно

В этой статье описывается версия базовой архитектуры непрерывной интеграции и непрерывного развертывания (CI/CD). В нем основное внимание уделяется развертыванию приложений Службы Azure Kubernetes (AKS) с помощью Azure Pipelines.

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

Architecture

Схема архитектуры конвейера CI/CD AKS, использующего Azure Pipelines.

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

Поток данных

Следующий поток данных соответствует предыдущей схеме:

  1. Запрос на вытягивание (PR) в репозиторий Azure Repos Git или репозиторий GitHub активирует конвейер PR.

    Этот конвейер выполняет проверки качества, включая следующие операции:

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

    Если какие-либо проверки не пройдены, запуск конвейера завершается, и разработчик должен внести необходимые изменения. Если все проверки проходят, конвейеру требуется проверка pr. Если проверка PR завершается ошибкой, процесс завершается, и разработчик должен внести необходимые изменения. Успешный запуск конвейера приводит к успешному слиянию PR.

  2. Слияние с Azure Repos Git активирует конвейер CI. Этот конвейер выполняет те же задачи, что и конвейер PR и добавляет тесты интеграции.

    Если для тестов интеграции требуются секреты, конвейер получает их из Azure Key Vault, ресурс, выделенный для конвейера CI этой среды.

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

  3. Успешный запуск конвейера непрерывной интеграции (CI) создает и публикует образ контейнера в непродуктивном реестре контейнеров Azure. Defender для контейнеров сканирует контейнерные образы при их отправке в реестр контейнеров Azure и сообщает о уязвимостях образов в Microsoft Defender для облака. При необходимости образы контейнеров могут быть подписаны , чтобы обеспечить целостность образа контейнера.

  4. Завершение конвейера CI активирует конвейер CD.

  5. Конвейер CD развертывает шаблон YAML в промежуточной среде AKS, которая включает агент Defender. Это развертывание использует модель push и выполняется через kubectl или Helm. Шаблон ссылается на образ контейнера из тестового реестра.

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

  6. При возобновлении ручного вмешательства конвейер CD переносит контейнерный образ из непродукционного реестра Azure в рабочий реестр. Defender для контейнеров проверяет образы контейнеров при их загрузке в Container Registry и сообщает об обнаруженных уязвимостях образов в Microsoft Defender for Cloud.

  7. Конвейер CD развертывает шаблон YAML в рабочей среде AKS, которая включает агент Defender. Шаблон задает образ контейнера из рабочего реестра.

  8. Управляемая служба Azure Monitor для Prometheus периодически пересылает метрики производительности, данные инвентаризации и сведения о состоянии работоспособности с узлов контейнеров и контейнеров в Azure Monitor.

  9. Рабочая область Log Analytics хранит все данные. Azure Monitor предоставляет несколько средств для анализа данных, собранных другими функциями. Различные панели мониторинга Grafana объединяют различные наборы телеметрии Kubernetes. Application Insights собирает мониторинговые данные приложений, например трассировки.

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

Components

  • Azure Pipelines — это компонент Azure DevOps, который автоматически создает, тестирует и развертывает код в целевом объекте вычислений. В этой архитектуре он создает и проверяет образы контейнеров, отправляет их в реестр контейнеров и развертывает их в AKS.

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

  • Key Vault — это облачная служба для хранения и доступа к секретам, таким как ключи API, пароли, сертификаты или криптографические ключи. В этой архитектуре конвейер получает секреты, необходимые для тестирования кода из Key Vault.

  • Azure Monitor — это решение для мониторинга, которое собирает, анализирует и реагирует на данные телеметрии из облачных и локальных сред. В этой архитектуре она служит центральной платформой наблюдения, которая обеспечивает мониторинг и оповещение для кластеров AKS и операций конвейера CI/CD.

  • Реестр контейнеров — это управляемая служба реестра контейнеров в Azure. Реестр контейнеров хранит частные образы контейнеров. В этой архитектуре вычислительная платформа извлекает образ контейнера приложения из Container Registry.

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

  • Расширение Microsoft Security DevOps Azure DevOps позволяет внедрять проверку безопасности непосредственно в рабочие процессы CI/CD. В этой архитектуре Microsoft Security DevOps выполняет статический анализ и обеспечивает видимость состояния безопасности в нескольких конвейерах в разработке и развертывании AKS. Microsoft Security DevOps является частью Microsoft Defender для защиты DevOps для облаков, который обеспечивает комплексную видимость, управление положением и защиту от угроз в многооблачных средах.

Alternatives

Рассмотрите следующие альтернативы для вашей реализации.

Модель на основе потягивания (GitOps)

В этом сценарии показана модель на основе push-уведомлений для развертывания ресурсов в AKS. Развертывания на основе push-уведомлений лучше всего работают, если требуется детерминированное обновление кластеров. Конвейеры активно инициируют развертывания, отслеживают их успешность и выполняют прямые действия, если развертывания завершаются сбоем. Этот подход часто является важной характеристикой методов безопасного развертывания в рабочих нагрузках. Развертывания на основе push-уведомлений также подходят для нескольких целевых объектов развертывания, таких как голубые зеленые среды, где требуется строго контролируемый шаблон развертывания в одном кластере или между кластерами.

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

Pull-модель GitOps также устраняет необходимость в прямом доступе к кластерам или использовании связанных учетных данных для развертывания, что исключает вектор атаки. Кластеры нуждаются только в доступе только для чтения к исходному репозиторию. Дополнительные сведения см. в разделе GitOps для AKS.

Конвейер CI/CD, созданный с помощью GitHub Actions

Вы можете заменить Azure Pipelines на GitHub Actions для AKS. GitHub Actions — это платформа CI/CD, которую можно использовать для автоматизации конвейера сборки, тестирования и развертывания. Рекомендуется использовать начальный рабочий процесс для AKS и настроить его в соответствии с требованиями CI/CD.

Дальнейшие шаги

  • Last updated on