Развертывание микрослужб с помощью приложений контейнеров Azure

Приложения-контейнеры Azure
Azure Cosmos DB
Служебная шина Azure

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

В примере используется рабочая нагрузка, используемая в архитектуре микрослужб, на Служба Azure Kubernetes и повторно размещена в приложениях контейнеров Azure в качестве платформы приложений.

Совет

Логотип GitHub Архитектура поддерживается примером реализации , которая иллюстрирует некоторые варианты проектирования, описанные в этой статье.

Архитектура

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

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

В этом сценарии образы контейнеров создаются из Реестр контейнеров Azure и развертываются в среде приложений контейнеров.

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

  • Внутреннее обнаружение входящего трафика и службы
  • Одна рабочая область Log Analytics для ведения журнала во время выполнения
  • Безопасное управление секретами и сертификатами

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

Рабочий процесс использует гибридный подход для управления секретами. Управляемые удостоверения используются в службах, где такая реализация не требует изменений кода. Службы планировщика дронов и доставки используют управляемые удостоверения, назначенные пользователем, для проверки подлинности в Azure Key Vault для доступа к секретам, хранящимся там. Остальные службы хранят секреты через службу "Приложения контейнеров" на уровне приложения.

Схема, показывающая архитектуру среды выполнения для решения.

На этой схеме показана архитектура среды выполнения для решения.

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

Поток данных

  1. Служба приема: получает клиентские запросы, буферизирует их и отправляет их через Служебная шина Azure в службу рабочего процесса.
  2. Служба рабочего процесса: использует сообщения из Служебная шина Azure и отправляет их в базовые службы.
  3. Служба пакетов: управляет пакетами.
  4. Служба планировщика дронов: планирует беспилотные летательные аппараты и отслеживает беспилотные летательные аппараты в полете.
  5. Служба доставки: управляет поставками, запланированными или передаваемыми.

Компоненты

Служба доставки дронов использует ряд служб Azure в концерте друг с другом.

Приложения-контейнеры Azure

Приложения контейнеров Azure — это основной компонент.

Эти функции заменяют многие сложности предыдущей архитектуры AKS:

  • Встроенное обнаружение служб
  • Полностью управляемые конечные точки HTTP и HTTP/2
  • Встроенная балансировка нагрузки
  • Ведение журналов и мониторинг
  • Автомасштабирование на основе http-трафика или событий, управляемых KEDA (автомасштабирование на основе Kubernetes)
  • Обновления приложений и управление версиями

Внешнее хранилище и другие компоненты

Служба Azure Key Vault для безопасного хранения и доступа к секретам, таким как ключи API, пароли и сертификаты.

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

Azure Cosmos DB хранит данные с открытым исходным кодом Azure Cosmos DB для MongoDB. Микрослужбы обычно без отслеживания состояния и записывают их состояние во внешние хранилища данных. Azure Cosmos DB — это база данных NoSQL с API с открытым исходным кодом для MongoDB и Cassandra.

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

Кэш Azure для Redis добавляет слой кэширования в архитектуру приложения, чтобы повысить скорость и производительность для тяжелых нагрузок трафика.

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

Application Insights обеспечивает расширяемое управление производительностью приложений (APM) и мониторинг для служб. Каждая служба инструментируется с помощью пакета SDK Application Insights для мониторинга приложения и перенаправления данных в Azure Monitor.

Шаблоны Bicep для настройки и развертывания приложений.

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

Альтернативным сценарием этого примера является приложение Fabrikam Drone Delivery с помощью Kubernetes, которое доступно на сайте GitHub в репозитории Служба Azure Kubernetes (AKS) Fabrikam Drone Delivery.

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

Бизнес может упростить развертывание и управление контейнерами микрослужб с помощью приложений контейнеров Azure. Контейнерные приложения предоставляют полностью управляемую бессерверную среду для создания и развертывания современных приложений.

Fabrikam, Inc. (вымышленная компания) реализует приложение доставки дронов, где пользователи запрашивают беспилотник для получения товаров для доставки. Когда клиент планирует отгрузку, серверная система назначает аппарат и сообщает пользователю предполагаемое время доставки.

Приложение микрослужб было развернуто в кластере Служба Azure Kubernetes (AKS). Но команда Fabrikam не воспользовались расширенными или платформенными функциями AKS. В конечном итоге они переносили приложение в приложения контейнеров Azure без большой нагрузки. Перенос решения в приложения контейнеров Azure Fabrikam смог:

  • Перенос приложения практически как есть: при перемещении приложения из AKS в приложения контейнеров Azure требуются очень минимальные изменения кода.
  • Развертывание инфраструктуры и рабочей нагрузки с помощью шаблонов Bicep: для развертывания контейнеров приложений необходимы манифесты YAML Kubernetes.
  • Предоставление приложению через управляемый входящий трафик: встроенная поддержка внешних https-ingress для предоставления службы приема данных удалена необходимость настройки собственных входящего трафика.
  • Извлечение образов контейнеров из ACR (Реестр контейнеров Azure): для приложений контейнеров Azure не требуется определенный базовый образ или реестр.
  • Управление жизненным циклом приложения. Функция редакции поддерживает выполнение нескольких версий конкретного приложения-контейнера и разделения трафика между ними для сценариев развертывания A/B или Blue/Green.
  • Используйте управляемое удостоверение: команда Fabrikam могла использовать управляемое удостоверение для проверки подлинности в Azure Key Vault и Реестр контейнеров Azure.

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

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

Другие распространенные способы использования контейнерных приложений:

  • Выполнение контейнерных рабочих нагрузок на бессерверной платформе на основе потребления.
  • Автоматическое масштабирование приложений на основе трафика HTTP/HTTPS и /или триггеров на основе событий, поддерживаемых KEDA
  • Минимизация затрат на обслуживание контейнерных приложений
  • развертывание конечных точек API;
  • размещение приложений фоновой обработки;
  • обработка на основе событий;

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

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

Availability

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

  • Исправления помогают развертывать обновления приложений с нулевым временем простоя. Вы можете использовать редакции для управления развертыванием обновлений приложений и разделения трафика между редакциями для поддержки синих и зеленых развертываний и тестирования A/B (в настоящее время не используется в этой рабочей нагрузке).
  • Благодаря комплексным функциям наблюдения для контейнерных приложений у вас есть целостное представление о запущенных приложениях. Контейнерные приложения интегрированы с Azure Monitor и Log Analytics, что позволяет отслеживать выполнение приложения контейнера и настраивать оповещения на основе метрик и событий.
  • Когда приложение неожиданно завершает работу, служба контейнерных приложений автоматически перезапускает ее.
  • Вы можете включить правила автомасштабирования для удовлетворения спроса по мере увеличения трафика и рабочих нагрузок.
  • Функции динамической балансировки нагрузки в контейнерных приложениях оптимизируют производительность (хотя они не используются в этой рабочей нагрузке).

Эффективность работы

Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".

Чтобы обеспечить эффективность работы, служба "Приложения контейнеров" предлагает следующие функции:

  • Интеграция GitHub Actions для настройки автоматизированных развертываний CI/CD.
  • Режим с несколькими версиями с разделением трафика для тестирования изменений в коде приложения и правилах масштабирования.
  • Интеграция с Azure Monitor и Log Analytics для предоставления аналитических сведений о контейнерном приложении.

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

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

Рекомендации по производительности в этом решении:

  • Рабочая нагрузка распределяется между несколькими приложениями микрослужб.
  • Каждая микрослужба является независимой, не совместно с другими микрослужбами, чтобы они могли независимо масштабироваться.
  • Автомасштабирование можно включить по мере увеличения рабочей нагрузки.
  • Запросы динамически балансируют нагрузку.
  • Метрики, включая использование ЦП и памяти, сведения о пропускной способности и использование хранилища, доступны через Azure Monitor.
  • Log Analytics предоставляет агрегирование журналов для сбора сведений в каждой среде приложений контейнеров.

Надежность

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

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

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

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

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

Секреты

  • Приложение-контейнер может хранить и получать конфиденциальные значения в виде секретов. После определения секрета для приложения-контейнера он доступен для использования приложением и любыми связанными правилами масштабирования. Если вы работаете в режиме с несколькими версиями, все редакции используют одни и те же секреты. Так как секреты считаются изменением области приложения, при изменении значения секрета новая редакция не создается. Однако для загрузки нового значения секрета необходимо перезапустить все выполняемые редакции. В этом сценарии используются значения переменных приложений и среды.
  • Переменные среды: конфиденциальные значения можно безопасно хранить на уровне приложения. При изменении переменных среды приложение-контейнер создает новую редакцию.

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

  • Входящий трафик. Чтобы ограничить внешний доступ, для внешнего входящего трафика настроена только служба приема. Серверные службы доступны только через внутреннюю виртуальную сеть в среде "Приложения контейнеров". Предоставляет только службы в Интернете, где это необходимо. Так как эта архитектура использует встроенную функцию входящего трафика, это решение не предлагает возможность полностью разместить точку входящего трафика за брандмауэром веб-приложения (WAF) или включить ее в планы защиты от атак DDoS. Все рабочие нагрузки с веб-интерфейсом должны быть перекрыты брандмауэром веб-приложения.
  • Виртуальная сеть: при создании среды можно предоставить пользовательскую виртуальную сеть; в противном случае виртуальная сеть автоматически создается и управляется корпорацией Майкрософт. Вы не можете управлять этой управляемой корпорацией Майкрософт виртуальной сетью, например путем добавления групп безопасности сети (NSG) или принудительного туннелирования трафика в брандмауэр исходящего трафика. В этом примере используется автоматически созданная виртуальная сеть.

Дополнительные параметры топологии сети см. в разделе "Сетевая архитектура" в приложениях контейнеров Azure.

Удостоверения рабочей нагрузки

  • Контейнерные приложения поддерживают управляемые удостоверения Microsoft Entra, позволяя приложению проходить проверку подлинности в других ресурсах, защищенных идентификатором Microsoft Entra, например Azure Key Vault, без управления учетными данными в приложении контейнера. Приложение-контейнер может использовать назначаемые системой, назначенные пользователем или оба типа управляемых удостоверений. Для служб, которые не поддерживают проверку подлинности AD, следует хранить секреты в Azure Key Vault и использовать управляемое удостоверение для доступа к секретам.
  • Используйте управляемые удостоверения для Реестр контейнеров Azure доступа. Приложения контейнеров Azure позволяют использовать другое управляемое удостоверение для рабочей нагрузки, отличное от доступа к реестру контейнеров. Этот подход рекомендуется для обеспечения детального управления доступом к управляемым удостоверениям.

Оптимизация затрат

  • Служба "Приложения контейнеров Azure" имеет модель ценообразования на основе потребления.
  • Приложения контейнеров Azure поддерживают масштабирование до нуля. Если приложение-контейнер масштабируется до нуля, плата не взимается.
  • В этом сценарии Azure Cosmos DB и Кэш Azure для Redis являются основными драйверами затрат.

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

Выполните действия, описанные в README.md в репозитории примеров сценариев приложений контейнеров Azure.

Соавторы

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

Автор субъекта:

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