Обмен данными между приложениями-контейнерами в Azure Container Apps

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

Если входящий трафик включен, каждое приложение-контейнер получает доменное имя. Эту конечную точку можно сделать общедоступной или ограничить ее другими приложениями-контейнерами в той же среде.

Приложения-контейнеры могут связаться друг с другом с помощью любого из следующих методов:

  • Полное доменное имя (FQDN) — созданный по умолчанию домен
  • Имя приложения: короткий адрес формы http://<APP_NAME> для внутренних вызовов
  • Вызов службы Dapr: подход, основывающийся на сайдкаре, со встроенными повторными попытками и мониторингом
  • Личный домен: собственное доменное имя с управляемым сертификатом

Примечание.

При вызове другого приложения-контейнера в той же среде с помощью полного доменного имени или имени приложения сетевой трафик никогда не покидает среду.

Почему это важно

В архитектуре микрослужб службы должны надежно вызывать друг друга. Azure Container Apps удаляет рабочее бремя настройки обнаружения служб, управления записями DNS и настройки обратных прокси-серверов.

Вот что платформа обрабатывает для вас:

  • Автоматическая регистрация DNS: каждое приложение контейнера получает разрешаемое имя узла сразу после его развертывания.
  • Маршрутизация, управляемая прокси-сервером: весь трафик между приложениями проходит через встроенный прокси-слой Envoy, который обрабатывает завершение TLS, разделение трафика и балансировку нагрузки.
  • Изоляция в области среды: внутренние конечные точки доступны только из той же среды, создавая естественную границу безопасности.
  • Гибкость протокола: обмен данными по протоколу HTTP/1.1, HTTP/2 (для gRPC) или необработанный TCP в зависимости от потребностей рабочей нагрузки.

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

Расположение приложения-контейнера (полное доменное имя)

Полное доменное имя каждого приложения контейнера состоит из имени приложения, уникального идентификатора среды и региона. Эти фрагменты домена все попадают под azurecontainerapps.io домен верхнего уровня.

Полное доменное имя контейнерного приложения Azure Container Apps.

Внешние и внутренние полностью квалифицированные доменные имена

Параметр видимости входящего трафика определяет, доступно ли ваше приложение извне среды:

Видимость Шаблон FQDN Доступно из
Внешний <APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Где угодно (общедоступный Интернет)
Внутренний <APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io Только та же среда

При установке ингересса на внутренний, FQDN включает .internal. сегмент. Другие приложения-контейнеры в той же среде по-прежнему могут получить доступ к приложению с помощью этого адреса, но запросы извне среды получают 404 ответ от прокси-сервера среды. DNS-имя разрешает общий IP-адрес среды, но прокси-сервер отклоняет запрос, так как приложение является внутренним.

Получение полного доменного имени

Команда az containerapp show возвращает полное доменное имя приложения-контейнера.

az containerapp show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <CONTAINER_APP_NAME> \
  --query properties.configuration.ingress.fqdn

В этом примере замените плейсхолдеры, окружённые символами <>, на ваши значения.

Значение, возвращаемое этой командой, напоминает доменное имя, как показано в следующем примере:

myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io

Редактирование меток ФКДИ (Fully Qualified Domain Names)

При назначении меток определенным ревизиям, каждая метка получает собственное уникальное полное доменное имя (FQDN) с помощью разделителя из трех дефисов.

<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

Для внутренних приложений шаблон включает .internal. сегмент:

<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

Полные доменные имена (FQDN) позволяют направлять трафик непосредственно в определённую версию. Эта практика полезна для тестирования новых версий, выполнения экспериментов A/B или предоставления стабильных конечных точек для конкретных развертываний редакций.

Вызов приложения контейнера по имени

Самый простой способ вызова другого приложения-контейнера из той же среды — это его имя. Отправьте запрос в http://<CONTAINER_APP_NAME>, и встроенная в среду DNS-служба автоматически разрешит имя.

http://my-backend-api

Как работает разрешение DNS

За кулисами Azure Container Apps использует настраиваемую конфигурацию DNS, которая преобразует имена приложений-контейнеров в маршрутизируемые адреса. Когда приложение отправляет запрос на имя другого приложения или полное доменное имя:

  1. DNS-сервер среды разрешает имя хоста в адрес прокси-сервиса Envoy.
  2. Прокси-сервер Envoy определяет целевое приложение из исходного имени узла.
  3. Прокси-сервер направляет запрос на правильные редакции на основе конфигурации трафика.

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

Подсказка

Используйте короткое имя приложения (http://<APP_NAME>) для вызовов между приложениями-контейнерами в одной среде. Это проще полного доменного имени и работает одинаково, так как DNS разрешает оба имени через один и тот же прокси-сервер.

Транспортные протоколы

Приложения-контейнеры поддерживают три режима передачи для входящего трафика, которые настраиваются с помощью свойства transport.

Транспорт Сценарий использования Сведения
Авто (по умолчанию) Стандартные веб-API и службы Автоматическое согласование HTTP/1.1 и HTTP/2
HTTP/2 Службы gRPC Обеспечивает поддержку HTTP/2 от начала до конца, что необходимо для gRPC.
TCP Протоколы, отличные от HTTP (базы данных, пользовательские протоколы) Необработанные TCP-подключения с сопоставлением портов

Примечание.

Для внешних подключений TCP требуется настраиваемая виртуальная сеть. Если вы пытаетесь создать внешнее tcp-приложение без пользовательской виртуальной сети, вы получите сообщение об ошибке ContainerAppTcpRequiresVnet . Внутренний TCP ингресс функционирует без пользовательской VNet.

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

Распределение трафика и маршрутизация версий

Azure Container Apps поддерживает три режима редакции, влияющие на распределение трафика между приложениями-контейнерами:

Режим Поведение
Single Весь трафик переходит к последней активной редакции.
Несколько Трафик распределяется по ревизиям в процентах на основе ваших правил распределения трафика.
Метки Каждая помеченная редакция получает уникальное полное доменное имя для прямого доступа.

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

Дополнительные сведения см. в разделе Revisions в Azure Container Apps.

Вызов службы Dapr

Dapr (распределенная среда выполнения приложений) обеспечивает подход с использованием сайдкаров для взаимодействия между приложениями. Включив Dapr, ваши контейнерные приложения получают встроенный вызов служб с взаимным TLS, автоматические повторные попытки и распределенную трассировку с использованием Azure Application Insights.

Диаграмма с указанием местоположения приложения контейнера Azure Container Apps с Dapr.

Как работает вызов Dapr

Каждое контейнеризированное приложение с поддержкой Dapr запускает вспомогательный процесс (sidecar) вместе с вашим приложением. Чтобы вызвать другое приложение с поддержкой Dapr, сделайте локальный HTTP-запрос на сайдкар Dapr, который отвечает за обнаружение и маршрутизацию служб.

http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>

Например, чтобы вызвать метод catalog в приложении с идентификатором приложения Dapr order-processor:

http://localhost:3500/v1.0/invoke/order-processor/method/catalog

Сайдкар определяет цель приложения через выделенный домен DNS и направляет запрос через прокси-сервис Envoy. Это та же инфраструктура, которая обрабатывает маршрутизацию на основе полного доменного имени.

Примечание.

Dapr использует собственный путь разрешения DNS (.dapr домен) отдельно от стандартного полного доменного имени. Оба пути направляются через прокси-инфраструктуру среды.

Идентификатор приложения Dapr

Идентификатор приложения Dapr — это то, что используют другие приложения для вызова вашей службы. Если вы не задаете явный идентификатор приложения, среда выполнения Dapr по умолчанию использует имя приложения контейнера. API ARM показывает appId: null , когда не настраиваете пользовательский идентификатор, но среда выполнения автоматически применяет имя приложения. Задайте пользовательский идентификатор приложения в конфигурации Dapr, если вам нужен другой идентификатор.

Идентификаторы приложений Dapr должны быть уникальными в среде. Если вы пытаетесь развернуть приложение-контейнер с Dapr App ID, который уже используется другим приложением, ресурс приложения-контейнера будет создан, но ревизия не сможет осуществить подготовку (provisioningState: Failed). Сообщение об ошибке определяет конфликтующий идентификатор приложения и приложение, принадлежащее ему.

Приложения «dapr-only» (без входящего HTTP-трафика)

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

Подсказка

При создании приложения no-ingress с Azure CLI опустите флаги --ingress и --target-port. Использование --target-port без --ingress вызовет ошибку использования.

Конфигурация бокового автомобиля Dapr

Вы настраиваете контейнер-сайдкар Dapr с помощью настроек контейнерного приложения. К ключевым параметрам относятся:

Setting Описание
appId Идентификатор приложения Dapr (по умолчанию — имя приложения контейнера)
appPort Порт, на котором ваше приложение слушает (в зависимости от целевого порта входящего трафика)
appProtocol Протокол обмена данными dapr-to-app (например, http, grpc)
logLevel Подробность журнала сайдкара Dapr
enableApiLogging Регистрировать ли вызовы API Dapr
httpMaxRequestSize Максимальный размер текста запроса в МБ для HTTP-сервера Dapr
httpReadBufferSize Максимальный размер буфера чтения HTTP в КБ

Дополнительные сведения о настройке Dapr с помощью Azure Container Apps см. в статье Dapr integration with Azure Container Apps.

Безопасность взаимодействия между приложениями

Azure Container Apps включает несколько функций безопасности, влияющих на взаимодействие приложений контейнеров:

  • TLS по умолчанию: весь трафик между приложениями-контейнерами направляется через прокси-сервер Envoy, который обрабатывает завершение TLS. allowInsecure Установите значение false (по умолчанию) для принудительного применения перенаправлений HTTPS.
  • Режим сертификата клиента (mTLS): настройте взаимный TLS, задав для режима сертификата клиента значение require, acceptили ignore.
  • Ограничения IP- адресов. Определите правила разрешения или запрета, чтобы ограничить, какие IP-адреса могут получить доступ к приложению.
  • Политики CORS: настройте правила общего доступа к ресурсам для веб-браузеров, обращающихся к вашим контейнерным приложениям.

Примечание.

При вызове службы через Dapr, сайдкары Dapr автоматически обеспечивают безопасность данных между службами с помощью взаимной TLS-аутентификации. Вам не нужно настраивать MTLS отдельно для вызовов Dapr to Dapr.

Дополнительные сведения см. в разделе Ingress в Azure Container Apps.

Личные домены

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

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

Дополнительные сведения см. в разделе Custom domains in Azure Container Apps.

Пример решения

Пример вызова между контейнерами с помощью полного доменного имени и Dapr доступен в Azure Samples.

Понимание взаимодействия приложений в Azure Container Apps связано с несколькими связанными темами.

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

Настройка входящего трафика для приложения-контейнера

  • Last updated on