Udostępnij za pośrednictwem

Co to są obszary robocze w usłudze Azure API Management?

  • Artykuł

DOTYCZY: Premium

W usłudze API Management obszary robocze mają nowy poziom autonomii dla zespołów interfejsów API organizacji, umożliwiając im szybsze tworzenie, zarządzanie i publikowanie interfejsów API, bardziej niezawodnie, bezpiecznie i wydajnie w usłudze API Management. Zapewniając izolowany dostęp administracyjny i środowisko uruchomieniowe interfejsu API, obszary robocze umożliwiają zespołom interfejsów API jednocześnie zachowanie nadzoru przez zespół platformy interfejsu API. Obejmuje to centralne monitorowanie, wymuszanie zasad interfejsu API i zgodności oraz publikowanie interfejsów API na potrzeby odnajdywania za pośrednictwem ujednoliconego portalu dla deweloperów.

Obszary robocze działają jak "foldery" w usłudze API Management:

  • Każdy obszar roboczy zawiera interfejsy API, produkty, subskrypcje, nazwane wartości i powiązane zasoby.
  • Dostęp do zasobów w obszarze roboczym jest zarządzany za pośrednictwem kontroli dostępu opartej na rolach (RBAC) platformy Azure z wbudowanymi lub niestandardowymi rolami przypisanymi do kont microsoft Entra.
  • Każdy obszar roboczy jest skojarzony z bramą obszaru roboczego na potrzeby routingu ruchu interfejsu API do usług zaplecza interfejsów API w obszarze roboczym.

Diagram koncepcyjny usługi API Management z obszarami roboczymi.

Uwaga

  • Najnowsze funkcje obszaru roboczego są obsługiwane w interfejsie API REST usługi API Management w wersji 2023-09-01-preview lub nowszej.
  • Aby zapoznać się z zagadnieniami dotyczącymi cen, zobacz Cennik usługi API Management.

Federacyjne zarządzanie interfejsami API z obszarami roboczymi

Obszary robocze dodają najwyższej klasy obsługę modelu federacyjnego zarządzania interfejsami API w usłudze API Management, oprócz już obsługiwanych modeli scentralizowanych i silosowych. Zapoznaj się z poniższą tabelą, aby zapoznać się z porównaniem tych modeli.

Model opis
Scentralizowane

Diagram scentralizowanego modelu usługi Azure API Management. 		Zalety
• Scentralizowany nadzór i możliwość obserwowania interfejsu API
• Ujednolicony portal dla deweloperów umożliwiający efektywne odnajdywanie i dołączanie interfejsów API
• Efektywność kosztowa infrastruktury

Wady
• Brak podziału uprawnień administracyjnych między zespołami
• Brama interfejsu API jest pojedynczym punktem awarii
• Brak możliwości przypisywanie problemów ze środowiskiem uruchomieniowym określonym zespołom
• Obciążenie zespołu platformy w celu ułatwienia współpracy może zmniejszyć wzrost interfejsu API
Silosowe

Diagram modelu silosowego usługi Azure API Management. 		Zalety
• Podział uprawnień administracyjnych między zespołami zwiększa produktywność i bezpieczeństwo
• Podział środowiska uruchomieniowego interfejsu API między zespołami zwiększa niezawodność interfejsu API, odporność i bezpieczeństwo
• Problemy ze środowiskiem uruchomieniowym są zawarte i powiązane z określonymi zespołami

Wady
• Brak scentralizowanego ładu i możliwości obserwowania interfejsu API
• Brak ujednoliconego portalu dla deweloperów
• Zwiększone koszty i trudniejsze zarządzanie platformą
Federacyjnych

Diagram modelu federacyjnego usługi Azure API Management. 		Zalety
• Scentralizowany nadzór i możliwość obserwowania interfejsu API
• Ujednolicony portal dla deweloperów umożliwiający efektywne odnajdywanie i dołączanie interfejsów API
• Podział uprawnień administracyjnych między zespołami zwiększa produktywność i bezpieczeństwo
• Podział środowiska uruchomieniowego interfejsu API między zespołami zwiększa niezawodność interfejsu API, odporność i bezpieczeństwo
• Problemy ze środowiskiem uruchomieniowym są zawarte i powiązane z określonymi zespołami

Wady
• Trudności z kosztami i zarządzaniem platformy większe niż w modelu scentralizowanym, ale niższym niż w modelu silosowym

Omówienie przykładowego scenariusza

Organizacja, która zarządza interfejsami API przy użyciu usługi Azure API Management, może mieć wiele zespołów programistycznych, które tworzą, definiują, konserwują i tworzą różne zestawy interfejsów API. Obszary robocze umożliwiają tym zespołom używanie usługi API Management do oddzielnego zarządzania interfejsami API, uzyskiwania do nich dostępu i zabezpieczania ich oraz niezależnie od zarządzania infrastrukturą usługi.

Poniżej przedstawiono przykładowy przepływ pracy do tworzenia i używania obszaru roboczego.

  1. Centralny zespół platformy interfejsu API, który zarządza wystąpieniem usługi API Management, tworzy obszar roboczy i przypisuje uprawnienia współpracownikom obszaru roboczego przy użyciu ról RBAC — na przykład uprawnienia do tworzenia lub odczytywania zasobów w obszarze roboczym. Dla obszaru roboczego jest również tworzona dedykowana brama interfejsu API.

  2. Centralny zespół ds. platformy interfejsu API używa narzędzi DevOps do tworzenia potoku DevOps dla interfejsów API w tym obszarze roboczym.

  3. Członkowie obszaru roboczego tworzą, publikują, productize i utrzymują interfejsy API w obszarze roboczym.

  4. Centralny zespół platformy interfejsu API zarządza infrastrukturą usługi, taką jak monitorowanie, odporność i wymuszanie zasad wszystkich interfejsów API.

Usługa API Management w obszarze roboczym

Zespoły zarządzają własnymi interfejsami API, produktami, subskrypcjami, zapleczami, zasadami, rejestratorami i innymi zasobami w obszarach roboczych. Zobacz dokumentację interfejsu API REST usługi API Management, aby uzyskać pełną listę zasobów i operacji obsługiwanych w obszarach roboczych.

Obszary robocze są zarządzane niezależnie od usługi API Management i innych obszarów roboczych, jednak zgodnie z projektem mogą odwoływać się do wybranych zasobów na poziomie usługi. Zobacz Obszary robocze i inne funkcje usługi API Management w dalszej części tego artykułu.

Brama obszaru roboczego

Każdy obszar roboczy może być skojarzony z bramami obszaru roboczego, aby umożliwić środowisko uruchomieniowe interfejsów API zarządzanych w obszarze roboczym. Brama obszaru roboczego to autonomiczny zasób platformy Azure z taką samą podstawową funkcjonalnością, jak brama wbudowana w usługę API Management.

Bramy obszarów roboczych są zarządzane niezależnie od usługi API Management i od siebie. Zapewniają one izolację środowiska uruchomieniowego między obszarami roboczymi, zwiększenie niezawodności interfejsu API, odporności i zabezpieczeń oraz umożliwienie przypisywania problemów ze środowiskiem uruchomieniowym do obszarów roboczych.

  • Aby uzyskać informacje na temat kosztów bram obszaru roboczego, zobacz Cennik usługi API Management.
  • Aby uzyskać szczegółowe porównanie bram usługi API Management, zobacz Omówienie bram usługi API Management.

Uwaga

Wprowadzamy możliwość skojarzenia wielu obszarów roboczych z bramą obszaru roboczego, pomagając organizacjom zarządzać interfejsami API za pomocą obszarów roboczych po niższych kosztach. Ta funkcja jest wdrażana od grudnia 2024 r. i może nie być dostępna dla wszystkich kwalifikujących się usług przed styczniem. Dowiedz się więcej

Nazwa hosta bramy

Każde skojarzenie obszaru roboczego z bramą obszaru roboczego tworzy unikatową nazwę hosta dla interfejsów API zarządzanych w tym obszarze roboczym. Domyślne nazwy hostów są zgodne ze wzorcem <workspace-name>-<hash>.gateway.<region>.azure-api.net. Obecnie niestandardowe nazwy hostów nie są obsługiwane w przypadku bram obszarów roboczych.

Izolacja sieciowa

Bramę obszaru roboczego można opcjonalnie skonfigurować w prywatnej sieci wirtualnej w celu odizolowania ruchu przychodzącego i/lub wychodzącego. W przypadku skonfigurowania brama obszaru roboczego musi używać dedykowanej podsieci w sieci wirtualnej.

Aby uzyskać szczegółowe wymagania, zobacz Wymagania dotyczące zasobów sieciowych dla bram obszarów roboczych.

Uwaga

  • Konfiguracja sieci bramy obszaru roboczego jest niezależna od konfiguracji sieci wystąpienia usługi API Management.
  • Obecnie brama obszaru roboczego można skonfigurować tylko w sieci wirtualnej po utworzeniu bramy. Nie można później zmienić konfiguracji sieci lub ustawień bramy.

Skalowanie pojemności

Zarządzanie pojemnością bramy przez ręczne dodawanie lub usuwanie jednostek skalowania, podobnie jak jednostki , które można dodać do wystąpienia usługi API Management w niektórych warstwach usług. Koszty bramy obszaru roboczego są oparte na wybranej liczbie jednostek.

Dostępność w regionach

Aby uzyskać bieżącą listę regionów, w których są dostępne bramy obszaru roboczego, zobacz Dostępność warstw w wersji 2 i bram obszarów roboczych.

Ograniczenia bramy

Następujące ograniczenia dotyczą obecnie bram obszarów roboczych:

  • Brama obszaru roboczego musi znajdować się w tym samym regionie co podstawowy region platformy Azure wystąpienia usługi API Management i w tej samej subskrypcji.
  • Nie można skojarzyć obszaru roboczego z bramą hostowaną samodzielnie
  • Bramy obszarów roboczych nie obsługują przychodzących prywatnych punktów końcowych
  • Interfejsy API w bramach obszarów roboczych nie mogą mieć przypisanych niestandardowych nazw hostów
  • Interfejsy API w obszarach roboczych nie są objęte usługą Defender dla interfejsów API
  • Bramy obszarów roboczych nie obsługują menedżera poświadczeń usługi API Management
  • Bramy obszarów roboczych obsługują tylko wewnętrzną pamięć podręczną; zewnętrzna pamięć podręczna nie jest obsługiwana
  • Bramy obszarów roboczych nie obsługują syntetycznych interfejsów API graphQL i interfejsów API protokołu WebSocket
  • Bramy obszarów roboczych nie obsługują tworzenia interfejsów API bezpośrednio z zasobów platformy Azure, takich jak Usługa Azure OpenAI Service, App Service, Aplikacje funkcji itd.
  • Nie można podzielić metryk żądań według obszaru roboczego w usłudze Azure Monitor; wszystkie metryki obszaru roboczego są agregowane na poziomie usługi
  • Dzienniki usługi Azure Monitor są agregowane na poziomie usługi; Dzienniki na poziomie obszaru roboczego nie są dostępne
  • Bramy obszarów roboczych nie obsługują certyfikatów urzędu certyfikacji
  • Bramy obszarów roboczych nie obsługują skalowania automatycznego
  • Bramy obszarów roboczych nie obsługują tożsamości zarządzanych, w tym powiązanych funkcji, takich jak przechowywanie wpisów tajnych w usłudze Azure Key Vault i używanie authentication-managed-identity zasad

Role RBAC dla obszarów roboczych

Kontrola dostępu oparta na rolach platformy Azure służy do konfigurowania uprawnień współpracowników obszaru roboczego do odczytywania i edytowania jednostek w obszarze roboczym. Aby uzyskać listę ról, zobacz How to use role-based access control in API Management (Jak używać kontroli dostępu opartej na rolach w usłudze API Management).

Aby zarządzać interfejsami API i innymi zasobami w obszarze roboczym, członkowie obszaru roboczego muszą mieć przypisane role (lub równoważne uprawnienia przy użyciu ról niestandardowych) w zakresie do usługi API Management, obszaru roboczego i bramy obszaru roboczego. Rola o zakresie usługi umożliwia odwoływanie się do niektórych zasobów na poziomie usługi z zasobów na poziomie obszaru roboczego. Na przykład organizuj użytkownika w grupie na poziomie obszaru roboczego, aby kontrolować interfejs API i widoczność produktu.

Uwaga

Aby ułatwić zarządzanie, skonfiguruj grupy entra firmy Microsoft w celu przypisania uprawnień obszaru roboczego do wielu użytkowników.

Obszary robocze i inne funkcje usługi API Management

Obszary robocze zostały zaprojektowane tak, aby zapewnić samodzielną segregację dostępu administracyjnego i środowiska uruchomieniowego interfejsu API. Istnieje kilka wyjątków zapewniających większą produktywność i włączenie ładu w całej platformie, możliwości obserwowania, możliwości ponownego obsługi i odnajdywania interfejsów API.

  • Odwołania do zasobów — zasoby w obszarze roboczym mogą odwoływać się do innych zasobów w obszarze roboczym i wybranych zasobów z poziomu usługi, takich jak użytkownicy, serwery autoryzacji lub wbudowane grupy użytkowników. Nie mogą odwoływać się do zasobów z innego obszaru roboczego.

    Ze względów bezpieczeństwa nie można odwoływać się do zasobów na poziomie usługi z zasad na poziomie obszaru roboczego (na przykład nazwanych wartości) lub według nazw zasobów, takich jak backend-id w zasadach set-backend-service .

    Ważne

    Wszystkie zasoby w usłudze API Management (na przykład interfejsy API, produkty, tagi lub subskrypcje) muszą mieć unikatowe nazwy, nawet jeśli znajdują się w różnych obszarach roboczych. Nie można mieć żadnych zasobów tego samego typu i o tej samej nazwie zasobu platformy Azure w tym samym obszarze roboczym, w innych obszarach roboczych lub na poziomie usługi.

  • Portal dla deweloperów — obszary robocze są koncepcją administracyjną i nie są udostępniane użytkownikom portalu deweloperów, w tym za pośrednictwem interfejsu użytkownika portalu deweloperów i podstawowego interfejsu API. Interfejsy API i produkty w obszarze roboczym można publikować w portalu deweloperów, podobnie jak interfejsy API i produkty na poziomie usługi.

    Uwaga

    Usługa API Management obsługuje przypisywanie serwerów autoryzacji zdefiniowanych na poziomie usługi do interfejsów API w obszarach roboczych.

Migrowanie z obszarów roboczych w wersji zapoznawczej

Jeśli utworzono obszary robocze w wersji zapoznawczej w usłudze Azure API Management i chcesz nadal z nich korzystać, przeprowadź migrację obszarów roboczych do ogólnie dostępnej wersji, kojarząc bramę obszaru roboczego z każdym obszarem roboczym.

Aby uzyskać szczegółowe informacje i dowiedzieć się więcej o innych zmianach, które mogą mieć wpływ na obszary robocze w wersji zapoznawczej, zobacz Zmiany powodujące niezgodność obszarów roboczych (marzec 2025 r.).

Usuwanie obszaru roboczego

Usunięcie obszaru roboczego spowoduje usunięcie wszystkich zasobów podrzędnych (interfejsów API, produktów itd.) i skojarzonej bramy, jeśli usuniesz obszar roboczy przy użyciu interfejsu witryny Azure Portal. Nie usuwa wystąpienia usługi API Management ani innych obszarów roboczych.

Powiązana zawartość