Входящий трафик в приложениях контейнеров Azure
Приложения контейнеров Azure позволяют предоставлять приложения-контейнеры общедоступному интернету, виртуальной сети (виртуальной сети) и другим приложениям-контейнерам в вашей среде, включив входящий трафик. Параметры входящего трафика применяются с помощью набора правил, которые управляют маршрутизацией внешнего и внутреннего трафика в приложение контейнера. При включении входящего трафика вам не нужно создавать Azure Load Balancer, общедоступный IP-адрес или другие ресурсы Azure, чтобы включить входящие HTTP-запросы или TCP-трафик.
Входящего трафика поддерживается:
- Внешний и внутренний входящий трафик
- Типы входящего трафика HTTP и TCP
- Доменные имена
- Ограничения IP-адресов
- Аутентификация
- Разделение трафика между редакциями
- Сходство сеансов
Пример конфигурации входящего трафика, показывающий разделение входящего трафика между двумя версиями:
Сведения о конфигурации см. в разделе "Настройка входящего трафика".
Внешний и внутренний входящий трафик
При включении входящего трафика можно выбрать один из двух типов входящего трафика:
- Внешний: принимает трафик как из общедоступного Интернета, так и внутренней среды приложения контейнера.
- Внутренний: разрешает только внутренний доступ из среды приложения контейнера.
Каждое приложение контейнера в среде можно настроить с различными параметрами входящего трафика. Например, в сценарии с несколькими приложениями микрослужбы для повышения безопасности может быть одно приложение контейнера, которое получает общедоступные запросы и передает запросы в фоновую службу. В этом сценарии вы настроите общедоступное приложение контейнера с внешним входящего трафика и внутренним приложением контейнера с внутренним входящего трафика.
Типы протоколов
Контейнерные приложения поддерживают два протокола для входящего трафика: 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, относящиеся к входящего трафика в приложениях контейнеров:
Верхний колонтитул | Описание | Values |
---|---|---|
X-Forwarded-Proto |
Протокол, используемый клиентом для подключения к службе приложений контейнеров. | http или https |
X-Forwarded-For |
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.