Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
DOTYCZY: Developer | Premium
Brama hostowana samodzielnie jest opcjonalną, konteneryzowaną wersją domyślnej bramy zarządzanej, która jest uwzględniona w każdym wystąpieniu usługi API Management. Jest to przydatne w scenariuszach, takich jak umieszczanie bram w tych samych środowiskach, w których hostujesz interfejsy API. Użyj własnej bramy, aby poprawić przepływ ruchu interfejsu API i spełnić wymagania dotyczące zabezpieczeń i zgodności interfejsu API.
W tym artykule wyjaśniono, jak funkcja własnej bramy usługi Azure API Management umożliwia hybrydowe i wielochmurowe zarządzanie interfejsami API. Przedstawia również architekturę wysokiego poziomu funkcji i opisuje jej możliwości.
Aby zapoznać się z omówieniem różnic między bramami zarządzanymi a samodzielnie hostowanymi, zobacz sekcję Brama interfejsu API w usłudze API Management.
Zarządzanie hybrydowym i multicloud interfejsem API
Funkcja bramy hostowanej samodzielnie rozszerza obsługę usługi API Management dla środowisk hybrydowych i wielochmurowych oraz umożliwia wydajne i bezpieczne zarządzanie interfejsami API hostowanymi lokalnie i w chmurach z jednego wystąpienia usługi API Management na platformie Azure.
W przypadku własnej bramy masz elastyczność wdrażania konteneryzowanej wersji składnika bramy usługi API Management w tych samych środowiskach, w których hostujesz interfejsy API. Wszystkie bramy hostowane samodzielnie są zarządzane z wystąpienia usługi API Management, z którym są sfederowane, co zapewnia widoczność i ujednolicone środowisko zarządzania we wszystkich wewnętrznych i zewnętrznych interfejsach API.
Każde wystąpienie usługi API Management składa się z następujących kluczowych składników:
- Płaszczyzna zarządzania, udostępniona jako API, używana do konfigurowania usługi za pośrednictwem portalu Azure, narzędzia PowerShell i innych obsługiwanych technologii.
- Brama (lub płaszczyzna danych), odpowiedzialna za proxowanie żądań API, stosowanie zasad i zbieranie danych telemetrycznych
- Portal dewelopera, który jest używany przez deweloperów do odkrywania, uczenia się i rozpoczęcia korzystania z interfejsów API
Domyślnie wszystkie te składniki są wdrażane na platformie Azure, co powoduje, że cały ruch interfejsu API (pokazany jako solidne czarne strzałki na poniższej ilustracji) przepływa przez platformę Azure niezależnie od tego, gdzie są hostowane zaplecza implementowane interfejsy API. Prostota operacyjna tego modelu wiąże się z kosztem zwiększonego opóźnienia, problemów ze zgodnością i w niektórych przypadkach dodatkowych opłat za transfer danych.
Wdrażanie własnych bram w tych samych środowiskach, w których są hostowane implementacje interfejsu API zaplecza, umożliwia przepływ ruchu interfejsu API bezpośrednio do interfejsów API zaplecza, co zmniejsza opóźnienia, optymalizuje koszty transferu danych i zapewnia zgodność, zachowując jednocześnie korzyści wynikające z posiadania jednego punktu zarządzania, wglądu i odnajdywania dla wszystkich interfejsów API w organizacji, niezależnie od tego, gdzie są hostowane ich implementacje.
Opakowanie
Brama hostowana samodzielnie jest dostępna jako obraz kontenera platformy Docker oparty na systemie Linux pochodzący z usługi Rejestr Artefaktów Microsoft. Można go wdrożyć na platformie Docker, Kubernetes lub w innym rozwiązaniu orkiestracji kontenerów działającym w klastrze serwerowym lokalnie, infrastrukturze chmury lub w celach ewaluacyjnych i programistycznych na komputerze osobistym. Bramę hostowaną samodzielnie można również wdrożyć jako rozszerzenie klastra w klastrze platformy Kubernetes z obsługą usługi Azure Arc.
Obrazy kontenerów
Dostępne są różne obrazy kontenerów dla bram hostowanych samodzielnie.
| Konwencja tagów | Zalecenie | Przykład | Tag ruchomy | Zalecane do produkcji |
|---|---|---|---|---|
{major}.{minor}.{patch} |
Użyj tego tagu, aby zawsze uruchamiać tę samą wersję bramy. | 2.0.0 |
❌ | ✔️ |
v{major} |
Użyj tego tagu, aby zawsze uruchamiać główną wersję bramy z każdą nową funkcjonalnością i poprawką. | v2 |
✔️ | ❌ |
v{major}-preview |
Użyj tego tagu, jeśli zawsze chcesz uruchomić najnowszy obraz kontenera w wersji zapoznawczej. | v2-preview |
✔️ | ❌ |
latest |
Użyj tego tagu, jeśli chcesz ocenić bramę hostowaną samodzielnie. | latest |
✔️ | ❌ |
beta
1 |
Użyj tego tagu, jeśli chcesz ocenić wersje zapoznawcze bramy samodzielnie hostowanej. | beta |
✔️ | ❌ |
Pełną listę dostępnych tagów można znaleźć tutaj.
1Wersje zapoznawcza nie są oficjalnie obsługiwane i są przeznaczone tylko do celów eksperymentalnych.
Zobacz polityki wsparcia dla samodzielnie hostowanej bramy.
Używanie tagów w oficjalnych opcjach wdrażania
Opcje wdrażania w portalu Azure używają tagu v2, który pozwala korzystać z najnowszej wersji obrazu kontenera samodzielnie hostowanej bramy w wersji 2, zawierającej wszystkie aktualizacje funkcji i poprawki.
Uwaga
Fragmenty polecenia i kodu YAML są dostarczane jako odwołanie. Jeśli chcesz, możesz użyć bardziej szczegółowego tagu.
Podczas instalacji bramy za pomocą wykresu Helm zoptymalizowane zostaje tagowanie obrazów. Wersja aplikacji pakietu Helm przypisuje bramę do określonej wersji i nie polega na latest.
Aby uzyskać więcej informacji, zobacz Instalowanie własnej bramy usługi API Management na platformie Kubernetes przy użyciu programu Helm.
Ryzyko użycia przemieszczających się tagów
Tagi aktualizowane na bieżąco to tagi, które są potencjalnie aktualizowane po wydaniu nowej wersji obrazu kontenera. Użycie tego typu tagów umożliwia użytkownikom kontenerów otrzymywanie aktualizacji obrazu kontenera bez konieczności aktualizowania wdrożeń.
W przypadku używania tego typu tagu można potencjalnie uruchamiać różne wersje równolegle bez zauważenia go, na przykład podczas wykonywania akcji skalowania po zaktualizowaniu tagu v2 .
Przykład: Tag v2 jest zwalniany wraz z kontenerową wersją obrazu 2.0.0. Gdy 2.1.0 zostanie opublikowany, tag v2 zostanie powiązany z obrazem 2.1.0.
Ważne
Rozważ użycie określonego tagu wersji w środowisku produkcyjnym, aby uniknąć niezamierzonych uaktualnień do nowszej wersji.
Łączność z platformą Azure
Bramy hostowane samodzielnie wymagają wychodzącej łączności protokołów TCP/IP z platformą Azure na porcie 443. Każda brama hostowana samodzielnie musi być skojarzona z pojedynczym wystąpieniem usługi API Management i skonfigurowana za pośrednictwem jej płaszczyzny zarządzania. Brama hostowana samodzielnie używa łączności z platformą Azure w celu:
- Raportowanie swojego stanu przez wysyłanie komunikatów typu heartbeat co minutę.
- Regularnie (co 10 sekund) sprawdzanie i stosowanie aktualizacji konfiguracji za każdym razem, gdy są dostępne.
- Wysyłanie metryk do usługi Azure Monitor, jeśli zostało to skonfigurowane.
- Wysyłanie zdarzeń do usługi Application Insights, jeśli zostało to skonfigurowane.
Zależności nazwy FQDN
Aby działać prawidłowo, każda brama hostowana samodzielnie wymaga łączności wychodzącej na porcie 443 do następujących punktów końcowych skojarzonych z wystąpieniem usługi API Management opartym na chmurze:
| Punkt końcowy | Wymagane? | Uwagi |
|---|---|---|
| Nazwa hosta punktu końcowego konfiguracji |
<api-management-service-name>.configuration.azure-api.net
1 |
Niestandardowe nazwy hostów są również obsługiwane i mogą być używane zamiast domyślnej nazwy hosta. |
| Publiczny adres IP wystąpienia usługi API Management | ✔️ | Adres IP lokalizacji podstawowej jest wystarczający. |
| Publiczne adresy IP tagu usługi Azure Storage | Opcjonalne2 | Adresy IP muszą odpowiadać podstawowej lokalizacji wystąpienia usługi API Management. |
| Nazwa hosta konta usługi Azure Blob Storage | Opcjonalne2 | Konto skojarzone z wystąpieniem (<blob-storage-account-name>.blob.core.windows.net). |
| Nazwa hosta konta usługi Azure Table Storage | Opcjonalne2 | Konto skojarzone z wystąpieniem (<table-storage-account-name>.table.core.windows.net). |
| Punkty końcowe dla usługi Azure Resource Manager | Opcjonalne3 | Wymagany punkt końcowy to management.azure.com. |
| Punkty końcowe dla integracji z Microsoft Entra | Opcjonalnie4 | Wymagane punkty końcowe to <region>.login.microsoft.com i login.microsoftonline.com. |
| Punkty końcowe dla integracji z Azure Application Insights | Opcjonalnie5 | Minimalne wymagane punkty końcowe to rt.services.visualstudio.com:443, dc.services.visualstudio.com:443i {region}.livediagnostics.monitor.azure.com:443. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Monitor. |
| Punkty końcowe na potrzeby integracji z usługą Event Hubs | Opcjonalnie5 | Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Event Hubs. |
| Punkty końcowe na potrzeby integracji zewnętrznej pamięci podręcznej | Opcjonalnie5 | To wymaganie zależy od używanej zewnętrznej pamięci podręcznej. |
1Aby uzyskać informacje o instancji usługi API Management w wewnętrznej sieci wirtualnej, zobacz Łączność w wewnętrznej sieci wirtualnej.
2 Wymagane tylko w wersji 2, gdy w zasadach używany jest inspektor API lub przydziały.
3Wymagane tylko w przypadku korzystania z uwierzytelniania entra firmy Microsoft w celu zweryfikowania uprawnień RBAC.
4Wymagane tylko wtedy, gdy używasz uwierzytelniania Microsoft Entra lub zasad związanych z Microsoft Entra.
5Wymagane tylko wtedy, gdy funkcja jest używana i wymaga informacji o publicznym adresie IP, porcie i nazwie hosta.
Ważne
- Nazwy hostów DNS muszą być rozpoznawalne dla adresów IP, a odpowiednie adresy IP muszą być osiągalne.
- Skojarzone nazwy kont magazynu są wyświetlane na stronie Stan łączności sieciowej usługi w witrynie Azure Portal.
- Publiczne adresy IP bazowe skojarzonych kont magazynu są dynamiczne i mogą ulec zmianie bez powiadomienia.
Łączność w wewnętrznej sieci wirtualnej
Łączność prywatna. Jeśli brama hostowana samodzielnie jest wdrożona w sieci wirtualnej, włącz prywatną łączność z punktem końcowym konfiguracji v2 w lokalizacji bramy hostowanej samodzielnie, na przykład przy użyciu prywatnego systemu DNS w sieci partnerskiej.
Łączność z Internetem. Jeśli brama hostowana samodzielnie musi połączyć się z punktem końcowym konfiguracji w wersji 2 za pośrednictwem Internetu, skonfiguruj niestandardową nazwę hosta dla punktu końcowego konfiguracji i uwidocznij punkt końcowy przy użyciu usługi Azure Application Gateway.
Opcje uwierzytelniania
Ustawienia konfiguracji kontenera bramy udostępniają następujące opcje uwierzytelniania połączenia między bramą hostowaną samodzielnie a punktem końcowym konfiguracji wystąpienia usługi API Management opartego na chmurze.
| Opcja | Kwestie wymagające rozważenia |
|---|---|
| Uwierzytelnianie Microsoft Entra | Skonfiguruj co najmniej jedną aplikację firmy Microsoft Entra w celu uzyskania dostępu do bramy. Zarządzaj dostępem oddzielnie dla aplikacji. Skonfiguruj dłuższy czas wygaśnięcia dla wpisów tajnych zgodnie z zasadami organizacji. Standardowe procedury firmy Microsoft Entra umożliwiają przypisywanie i odwoływanie uprawnień użytkowników lub grup dla aplikacji oraz rotację tajemnic. |
| Token dostępu do bramy. (Nazywany również kluczem uwierzytelniania). | Token wygasa co najmniej co 30 dni i musi zostać odnowiony w kontenerach. Wspierane przez klucz bramy, który można obracać niezależnie (na przykład w celu odwołania dostępu). Ponowne generowanie klucza bramy powoduje unieważnienie wszystkich tokenów dostępu utworzonych za jego pomocą. |
Wskazówka
Zobacz Usługa Azure API Management jako źródło usługi Event Grid , aby uzyskać informacje o zdarzeniach usługi Event Grid generowanych przez bramę hostowaną samodzielnie, gdy token dostępu bramy zbliża się do wygaśnięcia lub wygasł. Użyj tych zdarzeń, aby upewnić się, że wdrożone bramy zawsze mogą się uwierzytelniać za pomocą skojarzonej instancji usługi zarządzania interfejsami API.
Błędy łączności
W przypadku utraty łączności z platformą Azure brama self-hosted nie może odbierać aktualizacji konfiguracji, zgłaszać jego stanu lub przekazywać dane telemetryczne.
Brama lokalna jest zaprojektowana tak, aby działać w trybie awarii statycznej i może przetrwać tymczasową utratę łączności z platformą Azure. Można go wdrożyć z lokalną kopią zapasową konfiguracji lub bez niej. Tworzenie kopii zapasowej konfiguracji pozwala, aby bramy samodzielnie hostowane regularnie zapisywały kopię najnowszej pobranej konfiguracji na trwałym woluminie dołączonym do ich kontenera lub podu.
Po wyłączeniu kopii zapasowej konfiguracji i przerwaniu łączności z platformą Azure:
- Działające lokalnie bramy kontynuują pracę, korzystając z kopii konfiguracji przechowywanej w pamięci.
- Bramy self-hosted, które zostały zatrzymane, nie będą mogły ponownie się uruchomić.
Po włączeniu kopii zapasowej konfiguracji i przerwaniu łączności z platformą Azure:
- Samodzielnie hostowane bramy nadal funkcjonują, używając kopii konfiguracji w pamięci.
- Zatrzymane bramy działające na własnym serwerze mogą zostać uruchomione przy użyciu kopii zapasowej konfiguracji.
Po przywróceniu łączności każda samodzielnie hostowana brama, której dotyczy awaria, automatycznie ponownie łączy się ze skojarzoną instancją Zarządzania API i pobiera wszystkie aktualizacje konfiguracji, które miały miejsce, gdy brama była offline.
Zabezpieczenia
Ograniczenia
Następujące funkcje dostępne w bramach zarządzanych nie są dostępne w bramach hostowanych samodzielnie:
- Wznowienie sesji TLS.
- Renegocjacja certyfikatu klienta. Aby korzystać z uwierzytelniania certyfikatem klienta, konsumenci API muszą przedstawić swoje certyfikaty w ramach początkowego uzgadniania protokołu TLS. Aby zapewnić to zachowanie, włącz ustawienie „Negocjuj certyfikat klienta” podczas konfigurowania niestandardowej nazwy domeny dla lokalnie hostowanej bramy.
Bezpieczeństwo warstwy transportowej (TLS)
Obsługiwane protokoły
Bramy self-hosted domyślnie obsługują protokół TLS w wersji 1.2.
Jeśli używasz domen niestandardowych, możesz włączyć protokół TLS w wersji 1.0 i/lub 1.1 na płaszczyźnie sterowania.
Dostępne zestawy szyfrowania
Bramy hostowane samodzielnie używają następujących zestawów szyfrowania dla połączeń klienta i serwera:
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_DHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_DHE_RSA_WITH_AES_256_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_DHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_CBC_SHA256TLS_RSA_WITH_AES_128_CBC_SHA256TLS_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHA
Zarządzanie zestawami szyfrowania
W wersji 2.1.1 lub nowszej można zarządzać szyframi używanymi za pośrednictwem konfiguracji:
-
net.server.tls.ciphers.allowed-suitesUmożliwia zdefiniowanie rozdzielanej przecinkami listy szyfrów używanych na potrzeby połączenia TLS między klientem interfejsu API a bramą hostowaną samodzielnie. -
net.client.tls.ciphers.allowed-suitesUmożliwia zdefiniowanie rozdzielanej przecinkami listy szyfrów używanych na potrzeby połączenia TLS między własną bramą a zapleczem.
Powiązana zawartość
- Omówienie bramy interfejsu API
- Zasady pomocy technicznej dla samodzielnie hostowanej bramy sieciowej
- Usługa API Management w świecie hybrydowym i wielochmurowym
- Wskazówki dotyczące uruchamiania własnej bramy na platformie Kubernetes w środowisku produkcyjnym
- Wdrażanie własnej bramy na platformie Docker
- Wdrażanie własnej bramy na platformie Kubernetes
- Wdróż własną bramę na klastrze Kubernetes zarządzanym przez Azure Arc
- Wdrażanie samozarządzalnej bramy do usługi Azure Container Apps
- Ustawienia konfiguracji samodzielnie hostowanej bramy
- Możliwości obserwacji w usłudze API Management
- Integracja Dapr z samodzielnie hostowaną bramą