Общие сведения о независимом шлюзе

Локальный шлюз — это необязательная контейнерная версия управляемого шлюза по умолчанию, включенного в каждую службу Управление API. Это полезно для таких сценариев, как размещение шлюзов в тех же средах, где размещаются API. Используйте локальный шлюз, чтобы улучшить поток трафика API и устранить требования к безопасности и соответствию API.

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

Общие сведения о функциях в различных предложениях шлюзов см. в разделе Шлюз API в Управлении API.

Гибридное и многооблачное управление API

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

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

Каждая служба управления API состоит из следующих ключевых компонентов:

  • Плоскость управления, представленная в виде API, используемая для настройки службы с помощью портала Azure, PowerShell и других поддерживаемых механизмов.
  • Шлюз (или плоскость данных) отвечает за использование прокси для запросов API, применение политик и сбор данных телеметрии
  • Портал разработчика, используемый разработчиками для обнаружения, изучения и подключения для использования API-интерфейсов

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

Поток трафика API без использования локальных шлюзов

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

Поток трафика API с использованием локальных шлюзов

Упаковка

Локальный шлюз доступен в виде образа контейнера Docker на основе Linux в Microsoft Artifact Registry. Его можно развернуть в Docker, Kubernetes или любом другом решении оркестрации контейнеров, работающем в локальном кластере серверов, в облачной инфраструктуре или на персональном компьютере при использовании в целях оценки и разработки. Также можно развернуть локальный шлюз в качестве расширения кластера в кластере Kubernetes с поддержкой Azure Arc.

Образы контейнеров

Мы предоставляем различные образы контейнеров для локальных шлюзов в соответствии с вашими потребностями.

Соглашение о тегах Рекомендация Пример Последовательный тег Рекомендуется для производства
{major}.{minor}.{patch} Используйте этот тег, чтобы всегда запускать одну и ту же версию шлюза 2.0.0 ✔️
v{major} Используйте этот тег, чтобы всегда запускать основную версию шлюза с каждой новой функцией и исправлением. v2 ✔️
v{major}-preview Используйте этот тег, если вы всегда хотите запустить образ контейнера Microsoft последней предварительной версии. v2-preview ✔️
latest Используйте этот тег, если вы хотите оценить локальный шлюз. latest ✔️

Полный список доступных тегов см. здесь.

Использование тегов в официальных вариантах развертывания Microsoft

Наши варианты развертывания на портале Azure используют тег v2, который позволяет клиентам использовать последнюю версию образа контейнера локального шлюза версии 2 со всеми обновлениями компонентов и исправлениями.

Примечание

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

При установке с помощью диаграммы Helm от Microsoft происходит автоматическая оптимизация тегов изображений. Версия приложения диаграммы Helm привязывает шлюз к заданной версии и не использует latest.

Узнайте подробнее о том, как установить локальный шлюз Управления API в Kubernetes с помощью Helm.

Риск использования последовательных тегов

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

Это означает, что вы можете параллельно запустить разные версии, не заметив этого, например при выполнении действий масштабирования после обновления тега v2.

Пример. тег v2 был выпущен с образом контейнера 2.0.0, но при выпуске 2.1.0 тег v2 будет связан уже с образом 2.1.0.

Важно!

Рекомендуется использовать тег определенной версии в рабочей среде во избежание непреднамеренного обновления до более новой версии.

Подключение к Azure

Для локальных шлюзов требуется исходящее подключение TCP/IP к Azure через порт 443. Каждый локальный шлюз должен быть связан с одной службой управления API и настроен с помощью своей плоскости управления. Локальный шлюз использует подключение к Azure в следующих целях.

  • Предоставление отчетов о состоянии путем отправки сообщений с пакетами пульса каждую минуту
  • Регулярная проверка (каждые 10 секунд) и применение обновлений конфигурации, когда они доступны
  • Отправка метрик в Azure Monitor, если она настроена
  • Отправка событий в Application Insights, если она настроена

Важно!

Поддержка образов контейнеров локального шлюза azure Управление API версии 0 и версии 1 прекращается 1 октября 2023 г. вместе с соответствующим API конфигурации версии 1. Используйте наше руководство по миграции , чтобы использовать локальный шлюз версии 2.0.0 или более поздней версии с API конфигурации версии 2. Дополнительные сведения см. в нашей документации по устареению.

Зависимости FQDN

Для правильной работы каждого локального шлюза требуется исходящее подключение через порт 443 к следующим конечным точкам, связанным с облачным экземпляром службы "Управление API".

Описание Требуется для версии 1 Требуется для версии 2 Примечания
Имя узла конечной точки конфигурации <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net
Общедоступный IP-адрес экземпляра Управление API ✔️ ✔️ Ip-адресов основного расположения достаточно.
Общедоступные IP-адреса тега службы хранилища Azure ✔️ Необязательно1 IP-адреса должны соответствовать основному расположению экземпляра Управление API.
Имя узла учетной записи Хранилище BLOB-объектов Azure ✔️ Необязательно1 Учетная запись, связанная с экземпляром (<blob-storage-account-name>.blob.core.windows.net)
Имя узла учетной записи хранения таблиц Azure ✔️ Необязательно1 Учетная запись, связанная с экземпляром (<table-storage-account-name>.table.core.windows.net)
Конечные точки для интеграции приложение Azure Insights Необязательно2 Необязательно2 Минимальные обязательные конечные точки:rt.services.visualstudio.com:443dc.services.visualstudio.com:443{region}.livediagnostics.monitor.azure.com:443Дополнительные сведения см. в документации по Azure Monitor.
Конечные точки для интеграции Центров событий Необязательно2 Необязательно2 Дополнительные сведения см. в документации по Центры событий Azure
Конечные точки для интеграции внешнего кэша Необязательно2 Необязательно2 Это требование зависит от используемого внешнего кэша.

1 Требуется только в версии 2, если в политиках используются инспектор API или квоты. 2 Требуется только в том случае, если используется компонент и требуется общедоступный IP-адрес, порт и имя узла.

Важно!

  • Имена узлов DNS должны быть разрешаемыми для IP-адресов, а соответствующие IP-адреса должны быть доступны.
  • Имена связанных учетных записей хранения перечислены на странице состояния подключения к сети службы на портале Azure.
  • Общедоступные IP-адреса, лежащие в основе связанных учетных записей хранения, являются динамическими и могут изменяться без уведомления.

Сбои подключений

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

Локальный шлюз спроектирован для "статичной работы при сбоях" и может выдерживать временный разрыв подключения к Azure. Его можно развернуть с локальной резервной копией конфигурации или без нее. В случае с резервной копией конфигурации локальные шлюзы регулярно сохраняют резервную копию последней загруженной конфигурации на постоянном томе, подключенном к контейнеру или модулю Pod.

Если резервное копирование конфигурации отключено и подключение к Azure было прервано:

  • Локальные шлюзы будут продолжать работать, используя копию конфигурации, хранящуюся в памяти
  • Остановленные локальные шлюзы не смогут запуститься

Если резервное копирование конфигурации включено и подключение к Azure было прервано:

  • Локальные шлюзы будут продолжать работать, используя копию конфигурации, хранящуюся в памяти
  • Остановленные локальные шлюзы могут начать использовать резервную копию конфигурации

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

Безопасность

Ограничения

Следующие функции, доступные в управляемых шлюзах, недоступны в локальных шлюзах:

  • Возобновление сеанса TLS.
  • Повторное согласование сертификата клиента Для использования проверки подлинности с помощью сертификата клиента пользователям API необходимо предоставить свои сертификаты в ходе первоначального подтверждения TLS. Чтобы обеспечить такое поведение, включите параметр "Согласование сертификата клиента" при настройке пользовательского имени узла локального шлюза (имени домена).

Протокол TLS

Важно!

Этот обзор применим только к локальному шлюзу версий 1 и 2.

Поддерживаемые протоколы

Локальный шлюз по умолчанию обеспечивает поддержку TLS версии 1.2.

Клиенты, использующие личные домены, могут включить TLS версии 1.0 и (или) 1.1 на уровне управления.

Доступные комплекты шифров

Важно!

Этот обзор применим только к локальному шлюзу версии 2.

Локальный шлюз использует следующие комплекты шифров для подключений клиентов и серверов:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Управляющие комплекты шифров

В версии 2.1.1 и более поздних можно управлять используемыми шифрами с помощью конфигурации:

  • net.server.tls.ciphers.allowed-suites позволяет определить разделенный запятыми список шифров, используемых для подключения TLS между клиентом API и локальным шлюзом.
  • net.client.tls.ciphers.allowed-suites позволяет определить разделенный запятыми список шифров, используемых для подключения TLS между локальным шлюзом и серверной частью.

Дальнейшие действия