Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложения контейнеров Azure позволяют вам предоставлять приложение-контейнер к общедоступному интернету, виртуальной сети (VNET) и другим приложениям-контейнерам в вашей среде, включив функцию входа. Настройки входа применяются с помощью набора правил, которые контролируют маршрутизацию внешнего и внутреннего трафика в ваше контейнерное приложение. При включении входящего трафика вам не нужно создавать Azure Load Balancer, общедоступный IP-адрес или другие ресурсы Azure, чтобы включить входящие HTTP-запросы или TCP-трафик.
Ingress поддерживает:
- Внешний и внутренний входящий трафик
- Типы входящего трафика 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, относящиеся к входящему трафику в контейнерных приложениях.
Верхний колонтитул | Описание | Ценности |
---|---|---|
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.