Azure Devops для непрерывной доставки в архитектуре микросервисов

Архитектура микросервисов изменила современную программную инженерию, разложив монолитные приложения на небольшие, независимо развертываемые службы. Этот подход позволяет командам работать параллельно, выборочно масштабировать компоненты и быстрее выпускать функции. Однако операционная сложность управления десятками или сотнями услуг требует надежной автоматизации для создания, тестирования и развертывания кода - именно здесь непрерывная доставка (CD) становится критической. Azure DevOps предоставляет облачную, сквозную платформу, которая упрощает реализацию конвейеров компакт-дисков, адаптированных для микросервисных сред. Это руководство будет проходить через ключевые концепции, инструменты и стратегии для создания системы непрерывной доставки производственного уровня с использованием Azure DevOps, от контроля версий до мониторинга, решая уникальные проблемы микросервисов.

Что такое непрерывная доставка в микросервисах?

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

Проблемы непрерывной доставки микросервисов

Перед тем, как погрузиться в специфику Azure DevOps, важно распознать уникальные препятствия, которые вводят микросервисы:

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

Azure DevOps: обзор

Azure DevOps - это платформа Microsoft, объединяющая инструменты разработки под одним зонтиком. Она включает в себя пять основных сервисов, каждый из которых играет роль в непрерывной доставке:

В контексте микросервисов Azure Pipelines является краеугольным камнем, но другие сервисы усиливают рабочий процесс CD. Например, Azure Repos обеспечивает соблюдение политики обзора кода, Azure Artifacts размещает общие библиотеки (например, внутренние пакеты NuGet) и Azure Boards связывает изменения с рабочими элементами для прослеживаемости. Платформа также изначально интегрируется с ресурсами Azure, такими как Container Registry, Kubernetes Service (AKS), Web Apps и Virtual Machines, что делает ее естественным выбором для стеков, ориентированных на Microsoft.

Настройка контроля версий с помощью Azure Repos

Успешный конвейер CD начинается с надежного контроля версий. Azure Repos поддерживает как Git, так и Team Foundation Version Control (TFVC). Для микросервисов Git является предпочтительным вариантом из-за его распределенной природы и гибкости ветвления.

Каждая микрослужба должна находиться в своем собственном хранилище — шаблоне, известном как «множественное репо» или полирепо. Это позволяет командам редактировать и развертывать независимо. Альтернативно, некоторые организации принимают монорепо (одно хранилище, содержащее все услуги), которое упрощает обмен кодом и атомные обязательства, но требует более сложных триггеров трубопровода, чтобы избежать восстановления каждой услуги на каждом обязательстве. Azure Pipelines может фильтровать изменения по пути папки, поэтому монорепо также осуществимы.

Основные методы контроля версий для CD включают:

Azure Repos интегрируется с Azure Pipelines через сервисные крючки, поэтому отложенный коммит может автоматически запустить сборку CI для пострадавшего сервиса.

Строительство трубопроводов CI/CD с использованием трубопроводов Azure

Трубопровод как код

Azure Pipelines поддерживает определения трубопроводов на основе YAML, хранящиеся вместе с кодом. Этот подход «трубопровод как код» обеспечивает редактирование, воспроизводимость и сотрудничество. Типичный трубопровод CI / CD для микросервиса включает этапы: сборка, запуск единичных тестов, публикация артефактов, развертывание для разработки, запуск интеграционных тестов, развертывание для постановки, запуск дымовых испытаний и, наконец, развертывание для производства.

Пример минимального ЯМЛ:

trigger:
 branches:
 include:
 - main
 - develop
 paths:
 include:
 - services/user-service/*

pool:
 vmImage: ubuntu-latest

variables:
 serviceName: user-service

stages:
- stage: Build
 jobs:
 - job: Build
 steps:
 - script: dotnet build
 - script: dotnet test
 - task: PublishBuildArtifacts@1

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

Многоступенчатые трубопроводы

Azure Pipelines позволяет определять несколько этапов (Build, Test, Deploy) в одном файле YAML. На каждом этапе могут быть добавлены одобрения и шлюзы для обеспечения ручного выключения перед развертыванием производства. Например, развертывание для постановки может потребовать успешного автоматизированного тестового запуска, в то время как производство может нуждаться в одобрении менеджера выпуска. Этапы могут выполняться последовательно или параллельно, если услуги независимы.

Например, среда «Производство» может охватывать все пространства имен AKS для микросервисов. Развертывание в одной и той же среде может быть ограничено проверками здоровья после каждого обновления службы.

Стратегии развертывания

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

Голубо-зеленые развертывания

Сине-зеленое развертывание предполагает поддержание двух одинаковых сред (синий и зеленый). В любое время только одна из них находится в режиме реального времени. Новая версия развертывается в неактивной среде, тестируется, а затем переключается трафик. Azure DevOps может реализовать это с помощью групп развертывания или пространств имён Kubernetes. Например, трубопровод развертывается в «зеленый» слот, запускает проверку работоспособности, а затем обновляет балансировщик нагрузки для маршрутизации трафика в новый слот. Откат так же прост, как и переключение обратно в синий.

Canary выпускает

Canary Releases постепенно переводит небольшой процент пользователей на новую версию, отслеживая такие показатели, как частота ошибок и задержка. Azure DevOps интегрируется с слотами развертывания Azure App Service или разделением трафика AKS. Канарская стадия может развернуться в подмножестве подсистем (например, 10% веса) и после периода наблюдения продвигаться до 100%. Задачи группы развертывания или задачи Kubernetes с регулировкой могут автоматизировать это.

Обновления Rolling

Обновления для развертывания последовательно заменяют экземпляры старой версии на новую, обеспечивая нулевое время простоя, если правильно настроены медицинские зонды. Azure DevOps может использовать стратегию обновления для развертывания Kubernetes (по умолчанию в задачах Azure DevOps Kubernetes) или слоты развертывания App Service с авто-свопом. Настройка и в вашем конвейере YAML для контроля скорости обновления.

Особенности флагов

Флаги функций отсоединяются от активации функций. Вы можете развернуть код, содержащий незавершенные функции за переключателем, и включить их, когда они будут готовы. Azure DevOps не предоставляет встроенную систему управления флагами, но она интегрируется со сторонними службами (LaunchDarkly, Split) или вы можете использовать управление функциями Azure App Configuration.

Инфраструктура как код

Микросервисы процветают, когда инфраструктура автоматизирована и контролируется версиями. Azure DevOps поддерживает инфраструктуру как код (IaC) с шаблонами ARM, Bicep, Terraform и PowerShell. Для микросервисов рассматривайте инфраструктуру каждой службы (например, план Azure App Service, базу данных SQL или пространство имен Kubernetes) как отдельный развертываемый блок.

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

Azure DevOps также предлагает правила защиты окружающей среды, такие как эксклюзивные блокировки, чтобы предотвратить одновременное развертывание в одной и той же среде, что имеет решающее значение, когда многие службы совместно используют производственную инфраструктуру.

Контейнеризация и оркестровка

Контейнеры естественным образом подходят для микросервисов, обеспечивая согласованное время выполнения в разных средах. Azure DevOps трубопроводы могут создавать изображения Docker, подталкивать их к реестру контейнеров Azure (ACR) и развертывать их в Azure Kubernetes Service (AKS) или других оркестраторах.

Пример Docker build and push-задачи в YAML:

- task: Docker@2
 displayName: Build and push Docker image
 inputs:
 containerRegistry: 'ACR Service Connection'
 repository: 'my-user-service'
 command: buildAndPush
 Dockerfile: '**/Dockerfile'
 tags: |
 $(Build.BuildId)
 latest

На последующем этапе, диаграмма Хелма или манифесты Кубернетеса применяются с использованием задачи Azure Kubernetes Service.Использовать Хелм для параметризированных развертываний, позволяющих различные конфигурации в каждой среде (например, количество реплик, ограничения ресурсов).

Azure Pipelines также может управлять секретами для контейнерных приложений, вводя переменные среды из Key Vault во время развертывания, избегая жестко закодированных учетных данных в изображениях Docker.

Управление безопасностью и секретами

Микросервисы CD-проводов должны обрабатывать конфиденциальную информацию, такую как ключи API, строки соединений и сертификаты. Azure DevOps интегрируется с Azure Key Vault для безопасного хранения и извлечения секретов. Используйте библиотечные группы переменных, связанные с Key Vault: конвейер извлекает секреты во время выполнения и впрыскивает их в качестве переменных среды или монтирует их в секреты Kubernetes.

Кроме того, Azure DevOps предлагает сервисные подключения для управления аутентификацией внешних служб (ACR, AKS, Azure Resource Manager). Эти соединения используют принципы обслуживания Azure AD или управляемые идентификаторы, устраняя необходимость в статических учетных данных в определениях трубопровода.

Управление доступом на основе ролей (RBAC) в Azure DevOps гарантирует, что только уполномоченные команды могут изменять трубопроводы или одобрять развертывание производства. Объедините это с политикой филиала, чтобы обеспечить, чтобы проверки кода происходили до запуска CI / CD.

Мониторинг и обратная связь Loops

Непрерывная доставка не заканчивается при развертывании; она требует обратной связи о здоровье и производительности услуг. Azure DevOps интегрируется с Azure Monitor и Application Insights для сбора метрик, журналов и следов. Вы можете настроить ворота после развертывания, которые проверяют здоровье приложения, прежде чем объявить релиз успешным.

Например, трубопровод может вызвать API Application Insights, чтобы проверить, что частота ошибок остается ниже порога в течение определенного периода. Если затвор выходит из строя, выпуск автоматически откатывается. В Azure Pipelines затворы определяются в работе развертывания этапа:

- stage: Deploy
 jobs:
 - deployment: Production
 environment: 'Production'
 strategy:
 runOnce:
 deploy:
 steps:
 - script: kubectl apply -f deploy.yaml
 on:
 failure:
 steps:
 - script: kubectl rollout undo deployment/my-service
 postDeploySteps:
 - task: QueryAzureMonitorAlerts@1
 inputs:
 connectedServiceNameARM: 'Azure subscription'
 ResourceGroupName: 'my-rg'
 SeverityFilter: 'Sev0,Sev1'
 TimeRange: 5

Кроме того, интегрируйтесь с Azure Boards: если мониторинг сигнализирует о пожаре, можно автоматически создать рабочий элемент, связывающий инцидент с выпуском, который его вызвал.

Преимущества и лучшие практики

Внедрение непрерывной доставки микросервисов с помощью Azure DevOps дает измеримые преимущества:

  • Быстрее выводимые на рынок: Автоматизированные трубопроводы сокращают ручное усилие и позволяют параллельно выпускать сервисы.
  • Сниженный риск: Меньшие, постепенные изменения с автоматизированным тестированием и возможностями отката минимизируют влияние отказа.
  • Масштабируемость: Azure DevOps может обрабатывать сотни трубопроводов через многие службы и среды.
  • Единая платформа: Интегрируется управление исходными кодами, CI/CD, тестирование и мониторинг, обеспечивая сквозную прослеживаемость.

Чтобы получить максимальную отдачу от Azure DevOps для микросервисов, следуйте этим рекомендациям:

  • Поддерживайте быстроту трубопроводов: Используйте кэширование, условное исполнение и параллельные задания, чтобы избежать длительного времени сборки.
  • Стандартизируйте шаблоны: Используйте шаблоны YAML для совместного использования общих шагов построения и развертывания в службах, уменьшая дублирование и непоследовательность.
  • Собрать инфраструктуру в код: Всегда обеспечивайте среды автоматически из кода, а не вручную.
  • Использовать слоты для развертывания или канарейки: Испытать новые версии перед полным развертыванием и сохранить возможность мгновенного переключения.
  • Мониторинг всего: Интеграция проверок здоровья, журналов и показателей производительности в ваши трубопроводы, чтобы своевременно улавливать проблемы.
  • Безопасные секреты: Никогда не храните секреты в исходном коде; используйте Ключевое хранилище и переменные группы.

Заключение

Azure DevOps предоставляет всеобъемлющую гибкую платформу для реализации непрерывной доставки в микросервисных архитектурах. Объединив управление версиями, автоматизированные трубопроводы, стратегии развертывания, автоматизацию инфраструктуры и мониторинг, команды могут достичь быстрых, надежных и безопасных релизов для каждой службы независимо. Ключ заключается в том, чтобы адаптировать службы Azure DevOps к вашим конкретным архитектурным шаблонам - независимо от того, используете ли вы контейнеры, функции без сервера или виртуальные машины. Начните с одного сервисного конвейера, затем реплицируйте и настраивайте его для других, повторяя на обратной связи для постоянного улучшения процесса доставки. Для дальнейшего чтения обратитесь к документации Microsoft по микросервисам с Azure DevOps и руководство по микросервисам Azure Architecture Center .