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


Входящий трафик в приложениях контейнеров Azure

Приложения контейнеров Azure позволяют вам предоставлять приложение-контейнер к общедоступному интернету, виртуальной сети (VNET) и другим приложениям-контейнерам в вашей среде, включив функцию входа. Настройки входа применяются с помощью набора правил, которые контролируют маршрутизацию внешнего и внутреннего трафика в ваше контейнерное приложение. При включении входящего трафика вам не нужно создавать Azure Load Balancer, общедоступный IP-адрес или другие ресурсы Azure, чтобы включить входящие HTTP-запросы или TCP-трафик.

Ingress поддерживает:

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

Схема, показывающая конфигурацию входящего трафика, разделяющую трафик между двумя редакциями.

Сведения о конфигурации см. в разделе Настройка входа.

Внешний и внутренний входящий трафик

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

  • Внешний: принимает трафик как из общедоступного Интернета, так и внутренней среды приложения контейнера.
  • Внутренний: позволяет доступ только из внутренней среды вашего приложения контейнера.

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

Типы протоколов

Контейнерные приложения поддерживают два протокола для входящего трафика: HTTP и TCP.

HTTP

При включении входящих запросов по HTTP ваше контейнерное приложение имеет:

  • Поддержка завершения TLS
  • Поддержка HTTP/1.1 и HTTP/2
  • Поддержка WebSocket и gRPC
  • Конечные точки HTTPS, которые всегда используют TLS 1.2 или 1.3, завершаются в точке входящего трафика.
  • Конечные точки, предоставляющие порты 80 (для HTTP) и 443 (для HTTPS)
    • По умолчанию HTTP-запросы к порту 80 автоматически перенаправляются на HTTPS 443.
  • Полное доменное имя (FQDN)
  • Время ожидания запроса — 240 секунд

Заголовки HTTP

Http ingress добавляет заголовки для передачи метаданных о запросе клиента в приложение контейнера. Например, X-Forwarded-Proto заголовок используется для идентификации протокола, используемого клиентом для подключения к службе приложений контейнеров. В следующей таблице перечислены заголовки HTTP, относящиеся к входящему трафику в контейнерных приложениях.

Верхний колонтитул Описание Ценности
X-Forwarded-Proto Протокол, используемый клиентом для подключения к службе приложений контейнеров. http или https
X-Forwarded-For IP-адрес клиента, отправляющего запрос. IP-адрес отправителя. Если это указано в начальном запросе, он будет перезаписан.
X-Forwarded-Host Имя узла, которое клиент использовал для подключения к сервису "Контейнерные приложения".
X-Forwarded-Client-Cert Сертификат клиента, если clientCertificateMode задан. Разделенный запятой список хэша, сертификата и цепочки. Например: Hash=....;Cert="...";Chain="...";

TCP

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

Примечание.

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

С включением входящего трафика TCP ваше контейнерное приложение:

  • Доступен другим приложениям-контейнерам в той же среде с помощью его имени (определяется name свойством в ресурсе "Приложения контейнеров") и предоставленным номером порта.
  • Доступ извне возможен через полное доменное имя (FQDN) и открытый номер порта, если для входящего трафика задано значение external.

Дополнительные TCP-порты

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

Примечание.

Чтобы использовать эту функцию, необходимо иметь расширение CLI для приложений контейнеров. Выполните команду az extension add -n containerapp , чтобы установить последнюю версию расширения ИНТЕРФЕЙСА командной строки для приложений контейнеров.

Ниже приведены дополнительные TCP-порты:

  • Дополнительные TCP-порты могут быть внешними, если само приложение установлено как внешнее, а приложение-контейнер использует пользовательскую виртуальную сеть.
  • Любой внешний доступ к дополнительным TCP-портам должен быть уникальным во всей среде приложений контейнеров. Сюда входят все внешние дополнительные TCP-порты, внешние основные TCP-порты и порты 80/443, используемые встроенным механизмом входящего HTTP-трафика. Если дополнительные порты являются внутренними, один и тот же порт можно использовать несколькими приложениями.
  • Если открытый порт не указан, он по умолчанию будет совпадать с целевым портом.
  • Каждый целевой порт должен быть уникальным, и один и тот же целевой порт не может быть предоставлен на разных открытых портах.
  • Существует не более пяти дополнительных портов для каждого приложения. Если требуются дополнительные порты, откройте запрос на поддержку.
  • Только основной порт входящего трафика поддерживает встроенные функции HTTP, такие как CORS и сессийная привязка. При запуске HTTP на вершине дополнительных TCP-портов эти встроенные функции не поддерживаются.

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

Доменные имена

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

  • Полное доменное имя по умолчанию (FQDN): каждое приложение в среде контейнерных приложений автоматически назначается полное доменное имя на основе DNS-суффикса среды. Сведения о настройке DNS-суффикса среды см. в разделе "Суффикс пользовательской среды DNS".
  • Имя личного домена: можно настроить личный ДОМЕН DNS для среды "Приложения контейнеров". Дополнительные сведения см. в разделе "Пользовательские доменные имена и сертификаты".
  • Имя приложения: вы можете использовать имя приложения для обмена данными между приложениями в одной среде.

Чтобы получить полное доменное имя приложения, см. раздел "Расположение".

Ограничения IP-адресов

Контейнерные приложения поддерживают ограничения IP-адресов для входящего трафика. Вы можете создать правила для настройки IP-адресов, которые разрешены или запрещены для доступа к приложению контейнера. Дополнительные сведения см. в разделе "Настройка ограничений IP-адресов".

Проверка подлинности

Приложения контейнеров Azure предоставляют встроенные функции проверки подлинности и авторизации для защиты контейнерного приложения с поддержкой внешнего доступа. Дополнительные сведения см. в статье "Проверка подлинности и авторизация" в приложениях контейнеров Azure.

Вы можете настроить приложение для поддержки сертификатов клиента (mTLS) для проверки подлинности и шифрования трафика. Дополнительные сведения см. в разделе "Настройка сертификатов клиента".

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

Разделение трафика

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

Сходство сеансов

Привязка сеансов, также известная как постоянные сеансы, — это функция, которая позволяет направлять все HTTP-запросы от клиента к одному экземпляру контейнерного приложения. Эта функция полезна для систем с сохранением состояния, требующих постоянного подключения к одной и той же реплике. Дополнительные сведения см. в разделе "Сходство сеансов".

Общий доступ к ресурсам независимо от источника (CORS)

По умолчанию все запросы, сделанные через браузер, из страницы в домен, который не соответствует исходному домену страницы, блокируются. Чтобы избежать этого ограничения для служб, развернутых в контейнерных приложениях, можно включить общий доступ к ресурсам между источниками (CORS).

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

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