Ingress в Контейнеры приложений Azure

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

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

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

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

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

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

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

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

  • Внутренний: Делает полностью квалифицированное доменное имя приложения (FQDN), доступным только из той же среды Container Apps, например, из других контейнерных приложений. FQDN приложения недоступен напрямую из публичного интернета. Однако приложение всё ещё может принимать внешний трафик, если оно указано как цель в конфигурации HTTP-маршрутов на уровне среды. Чтобы полностью изолировать приложение от внешнего трафика, убедитесь, что оно не включено как цель в конфигурации HTTP-маршрутов или разместите его в отдельной среде. Для получения дополнительной информации см. раздел «Использовать маршрутизацию на основе правил с Контейнеры приложений Azure».

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

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

Контейнерные приложения поддерживают два протокола для входящего трафика: 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-адреса отправителей. Если указан в первоначальном запросе, он добавляется в него. Только самый правый IP-адрес предоставляется Контейнеры приложений Azure. Любые другие значения должны быть проверены пользователем, чтобы предотвратить спуфинирование IP-адресов.
X-Forwarded-Client-Cert Сертификат клиента, если clientCertificateMode задан. Разделенный запятой список хэша, сертификата и цепочки. Например: Hash=....;Cert="...";Chain="...";. Это значение перезаписывается при отправке клиентом.

Протокол tcp

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

Примечание.

Поддержка внешнего 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-портов эти встроенные функции не поддерживаются.

  • Номер 36985 порта зарезервирован для внутренних проверок работоспособности и недоступен для TCP-приложений или дополнительных портов в HTTP-приложениях.

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

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

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

  • Полное доменное имя по умолчанию (FQDN): каждое приложение в среде "Приложения контейнеров" автоматически назначается полное доменное имя в зависимости от суффикса DNS среды (системы доменных имен). Этот суффикс определяется переменнойCONTAINER_APP_ENV_DNS_SUFFIX среды. Сведения о настройке DNS-суффикса среды см. в разделе "Суффикс пользовательской среды DNS".

  • Имя личного домена: можно настроить личный ДОМЕН DNS для среды "Приложения контейнеров". Дополнительные сведения см. в разделе "Пользовательские доменные имена и сертификаты".

  • Имя приложения: вы можете использовать имя приложения для обмена данными между приложениями в одной среде.

Чтобы получить полное доменное имя для вашего приложения, см. расположение контейнерного приложения (FQDN).

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные сведения см. в разделе Configure CORS в Контейнеры приложений Azure.

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

Настройка ингресса

  • Last updated on