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

Что такое рабочие области в Azure Управление API?

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: Premium

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

Рабочие области, такие как "папки" в службе Управление API:

  • Каждая рабочая область содержит API, продукты, подписки, именованные значения и связанные ресурсы.
  • Доступ к ресурсам в рабочей области управляется с помощью управления доступом на основе ролей Azure (RBAC) со встроенными или настраиваемыми ролями, которые можно назначать учетным записям Microsoft Entra.
  • Каждая рабочая область связана с шлюзом рабочей области для маршрутизации трафика API в внутренние службы API в рабочей области.

Концептуальная схема службы Управление API с рабочими областями.

Примечание.

  • Последние функции рабочей области поддерживаются в Управление API REST API версии 2023-09-01-preview или более поздней версии.
  • Сведения о ценах см. в Управление API ценах.

Управление федеративными API с рабочими областями

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

Модель Description
Централизованный

Схема централизованной модели Azure Управление API. 		Преимущества
• Централизованное управление API и наблюдаемость
• Единый портал разработчика для эффективного обнаружения и подключения API
• Экономичность инфраструктуры

Недостатки
• Отсутствие разделения административных разрешений между командами
• Шлюз API — это одна точка сбоя
• Неспособность к проблемам среды выполнения атрибутов для определенных команд
• Бремя на команде платформы для упрощения совместной работы может снизить рост API
Siloed

Схема сложенной модели Azure Управление API. 		Преимущества
• Разделение административных разрешений между командами повышает производительность и безопасность.
• Разделение среды выполнения API между командами повышает надежность, устойчивость и безопасность API.
• Проблемы среды выполнения содержатся и связаны с определенными командами

Недостатки
• Отсутствие централизованного управления API и наблюдаемости
• Отсутствие единого портала разработчика
• Повышение затрат и более сложное управление платформами
Федеративные

Схема федеративной модели Azure Управление API. 		Преимущества
• Централизованное управление API и наблюдаемость
• Единый портал разработчика для эффективного обнаружения и подключения API
• Разделение административных разрешений между командами повышает производительность и безопасность.
• Разделение среды выполнения API между командами повышает надежность, устойчивость и безопасность API.
• Проблемы среды выполнения содержатся и связаны с определенными командами

Недостатки
• Трудности с затратами и управлением платформы больше, чем в централизованной модели, но ниже, чем в разложенной модели.

Обзор сценария-примера

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

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

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

  2. Центральная группа платформы API использует средства DevOps для создания конвейера DevOps для API в этой рабочей области.

  3. Участники рабочей области разрабатывают, публикуют, продуктизуют и поддерживают API в рабочей области.

  4. Центральная группа платформы API управляет инфраструктурой службы, например мониторингом, устойчивостью и применением политик всех API.

Управление API в рабочей области

Teams управляют собственными API, продуктами, подписками, внутренними серверами, политиками, средствами ведения журнала и другими ресурсами в рабочих областях. Полный список ресурсов и операций, поддерживаемых в рабочих областях, см. в справочнике по REST API Управление API.

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

Шлюз рабочей области

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

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

  • Сведения о стоимости шлюзов рабочих областей см. в Управление API ценах.
  • Подробное сравнение шлюзов Управление API см. в Управление API обзоре шлюзов.

Имя узла шлюза

Каждая связь рабочей области с шлюзом рабочей области создает уникальное имя узла для API, управляемых в этой рабочей области. Имена узлов по умолчанию соответствуют шаблону <workspace-name>-<hash>.gateway.<region>.azure-api.net. В настоящее время пользовательские имена узлов не поддерживаются для шлюзов рабочих областей.

Примечание.

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

Сетевая изоляция

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

Подробные требования см. в разделе "Требования к сетевым ресурсам" для шлюзов рабочих областей.

Примечание.

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

Изменение масштаба емкости

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

Доступность в регионах

Шлюзы рабочих областей в настоящее время доступны в следующих регионах:

Примечание.

Эти регионы представляют собой подмножество тех, где доступны Управление API.

  • западная часть США
  • Центрально-северная часть США
  • Восточная часть США 2
  • южная часть Соединенного Королевства
  • Центральная Франция
  • Центрально-Западная Германия
  • Северная Европа
  • Восточная Азия
  • Юго-Восточная Азия
  • Восточная Австралия
  • Восточная Япония

Ограничения шлюза

Следующие ограничения в настоящее время применяются к шлюзам рабочих областей:

  • Шлюз рабочей области должен находиться в том же регионе, что и основной регион Azure экземпляра Управление API и в той же подписке.
  • Шлюз может быть связан только с одной рабочей областью
  • Рабочая область не может быть связана с локальным шлюзом
  • Шлюзы рабочих областей не поддерживают входящие частные конечные точки
  • API-интерфейсы в шлюзах рабочих областей не могут быть назначены пользовательскими именами узлов
  • API в рабочих областях не охватываются Api Defender для API
  • Шлюзы рабочих областей не поддерживают диспетчер учетных данных службы Управление API
  • Шлюзы рабочих областей поддерживают только внутренний кэш; внешний кэш не поддерживается
  • Шлюзы рабочих областей не поддерживают искусственные API GraphQL и API WebSocket
  • Шлюзы рабочих областей не поддерживают создание API непосредственно из ресурсов Azure, таких как Служба Azure OpenAI, Служба приложений, приложения-функции и т. д.
  • Метрики запросов не могут быть разделены по рабочей области в Azure Monitor; Все метрики рабочей области агрегируются на уровне обслуживания
  • Журналы Azure Monitor агрегируются на уровне обслуживания; Журналы уровня рабочей области недоступны
  • Шлюзы рабочих областей не поддерживают сертификаты ЦС
  • Шлюзы рабочих областей не поддерживают автомасштабирование
  • Шлюзы рабочих областей не поддерживают управляемые удостоверения, включая связанные функции, такие как хранение секретов в Azure Key Vault и использование authentication-managed-identity политики

Роли RBAC для рабочих областей

Azure RBAC используется для настройки разрешений участников совместной работы рабочей области для чтения и редактирования сущностей в рабочей области. Список ролей см. в разделе "Использование управления доступом на основе ролей" в Управление API.

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

Примечание.

Чтобы упростить управление, настройте группы Microsoft Entra для назначения разрешений рабочей области нескольким пользователям.

Рабочие области и другие функции Управление API

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

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

    По соображениям безопасности невозможно ссылаться на ресурсы уровня обслуживания из политик уровня рабочей области (например, именованных значений) или по именам ресурсов, например backend-id в политике set-backend-service .

    Внимание

    Все ресурсы в службе Управление API (например, API, продукты, теги или подписки) должны иметь уникальные имена, даже если они находятся в разных рабочих областях. Не может быть ресурсов одного типа и с тем же именем ресурса Azure в той же рабочей области, в других рабочих областях или на уровне обслуживания.

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

    Примечание.

    Управление API поддерживает назначение серверов авторизации, определенных на уровне обслуживания API в рабочих областях.

Миграция из рабочих областей предварительной версии

Если вы создали рабочие области предварительной версии в Azure Управление API и хотите продолжить их использование, перенесите рабочие области в общедоступную версию, связав шлюз рабочей области с каждой рабочей областью.

Дополнительные сведения и сведения о других изменениях, которые могут повлиять на рабочие области предварительной версии, см. в статьях о критических изменениях рабочих областей (март 2025 г.).

Удаление рабочей области

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

Связанный контент