Översikt över gateway med egen värd

2025-10-30

GÄLLER FÖR: Utvecklare | Premie

Lokalt installerad gateway är en valfri, containerbaserad version av den hanterade standardgatewayen som ingår i varje API Management-instans. Det är användbart för scenarier som att placera gatewayer i samma miljöer där du är värd för dina API:er. Använd den lokalt installerade gatewayen för att förbättra API-trafikflödet och hantera KRAV för API-säkerhet och efterlevnad.

Den här artikeln beskriver hur funktionen för lokalt installerad gateway i Azure API Management möjliggör hantering av hybrid- och multimolns-API:er. Den visar också funktionens arkitektur på hög nivå och beskriver dess funktioner.

En översikt över skillnaderna mellan hanterade och lokalt installerade gatewayer finns i API Gateway i API Management.

Hantering av hybrid- och multimoln-API:et

Funktionen för lokalt installerad gateway utökar API Management-stödet för hybridmiljöer och miljöer med flera moln och gör att du effektivt och säkert kan hantera API:er som finns lokalt och mellan moln från en enda API Management-instans i Azure.

Med en gateway med egen värd har du flexibiliteten att distribuera en containerbaserad version av API Management-gatewaykomponenten till samma miljöer där du är värd för dina API:er. Alla gatewayer med egen värd hanteras från den API Management-instans som de är federerade med, vilket ger dig synlighet och enhetlig hantering för alla interna och externa API:er.

Varje API Management-instans består av följande nyckelkomponenter:

Ett hanteringsplan som exponeras som ett API som används för att konfigurera tjänsten via Azure-portalen, PowerShell och andra tekniker som stöds
En gateway (eller ett dataplan) som ansvarar för proxykörning av API-begäranden, tillämpar principer och samlar in telemetri
En utvecklarportal som används av utvecklare för att upptäcka, lära sig och börja använda API:er.

Som standard distribueras alla dessa komponenter i Azure, vilket gör att all API-trafik (visas som svarta pilar i följande bild) flödar genom Azure oavsett var serverdelar som implementerar API:erna finns. Den här modellens drifts enkelhet sker på bekostnad av ökad svarstid, efterlevnadsproblem och i vissa fall extra avgifter för dataöverföring.

Genom att distribuera gatewayer med egen värd i samma miljöer där implementeringarna av serverdels-API:et finns kan API-trafik flöda direkt till serverdels-API:erna, vilket minskar svarstiden, optimerar kostnaderna för dataöverföring och möjliggör efterlevnad samtidigt som fördelarna med att ha en enda hanteringsplats, observerbarhet och identifiering för alla API:er i organisationen, oavsett var deras implementeringar finns.

Paketering

Den lokalt installerade gatewayen är tillgänglig som en Linux-baserad Docker-containeravbildning från Microsofts artefaktregister. Den kan distribueras till Docker, Kubernetes eller någon annan containerorkestreringslösning som körs på ett serverkluster lokalt, i molninfrastruktur eller, i utvärderings- och utvecklingssyfte, på en privat dator. Du kan också distribuera den lokalt installerade gatewayen som ett klustertillägg till ett Azure Arc-aktiverat Kubernetes-kluster.

Containeravbildningar

Det finns en mängd olika containeravbildningar för gatewayer med egen värd:

Taggkonvention	Rekommendation	Exempel	Rullande etikett	Rekommenderas för produktion
`{major}.{minor}.{patch}`	Använd den här taggen för att alltid köra samma version av gatewayen.	`2.0.0`	❌	✔️
`v{major}`	Använd den här taggen för att alltid köra en huvudversion av gatewayen med varje ny funktion och korrigering.	`v2`	✔️	❌
`v{major}-preview`	Använd den här taggen om du alltid vill köra den senaste förhandsgranskningscontaineravbildningen.	`v2-preview`	✔️	❌
`latest`	Använd den här taggen om du vill utvärdera den lokalt installerade gatewayen.	`latest`	✔️	❌
`beta` ¹	Använd den här taggen om du vill utvärdera förhandsversioner av den lokala gatewayen.	`beta`	✔️	❌

Du hittar en fullständig lista över tillgängliga taggar här.

¹Förhandsversioner stöds inte officiellt och är endast för experimentella ändamål. Se supportprinciperna för lokalt installerad gateway.

Användning av taggar i officiella distributionsalternativ

Distributionsalternativ i Azure-portalen använder taggen v2 som gör att du kan använda den senaste versionen av den lokala gatewayen v2-containeravbildningen med alla funktionsuppdateringar och korrigeringar.

Kommentar

Kommandot och YAML-kodfragmenten tillhandahålls som en referens. Du kan använda en mer specifik tagg om du vill.

När du installerar en gateway med ett Helm-diagram optimeras bildtaggning. Helm-diagrammets programversion fäster gatewayen till en viss version och förlitar sig inte på latest.

Mer information finns i Installera en lokalt installerad API Management-gateway på Kubernetes med Helm.

Risk för att använda rullande taggar

Rullande taggar är taggar som kan uppdateras när en ny version av containeravbildningen släpps. Med den här typen av taggar kan containeranvändare ta emot uppdateringar av containeravbildningen utan att behöva uppdatera sina distributioner.

När du använder den här typen av tagg kan du köra olika versioner parallellt utan att märka det, till exempel när du utför skalningsåtgärder när taggen v2 har uppdaterats.

Exempel: Taggen v2 släpps med containeravbildningen 2.0.0 . När 2.1.0 släpps länkas taggen v2 till avbildningen 2.1.0 .

Viktigt!

Överväg att använda en specifik versionstagg i produktion för att undvika oavsiktliga uppgraderingar till en nyare version.

Anslutning till Azure

Gatewayer med egen värd kräver utgående TCP/IP-anslutning till Azure på port 443. Varje lokalt installerad gateway måste associeras med en enda API Management-instans och konfigureras via dess hanteringsplan. En gateway med egen värd använder anslutning till Azure för att:

Rapportera dess status genom att skicka pulsslagsmeddelanden varje minut.
Regelbundet (var 10:e sekund) söker efter och tillämpar konfigurationsuppdateringar när de är tillgängliga.
Skicka mått till Azure Monitor om det är konfigurerat för att göra det.
Skicka händelser till Application Insights om det är konfigurerat för att göra det.

Beroenden av FQDN

För att fungera korrekt behöver varje lokalt installerad gateway utgående anslutning på port 443 till följande slutpunkter som är associerade med dess molnbaserade API Management-instans:

Slutpunkt	Krävs?	Anteckningar
Värdnamn för konfigurationsslutpunkten	`<api-management-service-name>.configuration.azure-api.net` ¹	Anpassade värdnamn stöds också och kan användas i stället för standardvärdnamnet.
Offentlig IP-adress för API Management-instansen	✔️	IP-adressen för den primära platsen räcker.
Offentliga IP-adresser för Azure Storage-tjänsttaggen	Valfritt²	IP-adresser måste motsvara den primära platsen för API Management-instansen.
Värdnamn för Azure Blob Storage-kontot	Valfritt²	Kontot som är associerat med instansen (`<blob-storage-account-name>.blob.core.windows.net`).
Värdnamn för Azure Table Storage-kontot	Valfritt²	Kontot som är associerat med instansen (`<table-storage-account-name>.table.core.windows.net`).
Ändpunkter för Azure Resource Manager	Valfritt³	Slutpunkten som krävs är `management.azure.com`.
Ändpunkter för Microsoft Entra-integration	Valfritt⁴	Nödvändiga slutpunkter är `<region>.login.microsoft.com` och `login.microsoftonline.com`.
Slutpunkter för Azure Application Insights-integrering	Valfritt⁵	Minimala nödvändiga slutpunkter är `rt.services.visualstudio.com:443`, `dc.services.visualstudio.com:443`och `{region}.livediagnostics.monitor.azure.com:443`. Mer information finns i Dokumentation om Azure Monitor.
Slutpunkter för Event Hubs-integrering	Valfritt⁵	Mer information finns i dokumentationen om Azure Event Hubs.
Slutpunkter för extern cacheintegrering	Valfritt⁵	Det här kravet beror på den externa cache som används.

¹Information om en API Management-instans i ett internt virtuellt nätverk finns i Anslutning i ett internt virtuellt nätverk.
²Krävs endast i v2 när API-kontroll eller kvoter används i principer.
³Krävs endast när du använder Microsoft Entra-autentisering för att verifiera RBAC-behörigheter.
⁴Krävs endast när du använder Microsoft Entra-autentisering eller principer som är relaterade till Microsoft Entra.
⁵Krävs endast när funktionen används och kräver offentlig IP-adress, port och värdnamnsinformation.

Viktigt!

DNS-värdnamn måste kunna matchas mot IP-adresser och motsvarande IP-adresser måste kunna nås.
De associerade lagringskontonamnen visas på tjänstens statussida för nätverksanslutning i Azure-portalen.
Offentliga IP-adresser som ligger till grund för de associerade lagringskontona är dynamiska och kan ändras utan föregående meddelande.

Anslutning i ett internt virtuellt nätverk

Privat anslutning. Om den lokalt installerade gatewayen distribueras i ett virtuellt nätverk aktiverar du privat anslutning till v2-konfigurationsslutpunkten från platsen för den lokalt installerade gatewayen, till exempel med hjälp av en privat DNS i ett peer-kopplat nätverk.
Internetanslutning. Om den lokalt installerade gatewayen behöver ansluta till v2-konfigurationsslutpunkten via Internet konfigurerar du ett anpassat värdnamn för konfigurationsslutpunkten och exponerar slutpunkten med hjälp av Azure Application Gateway.

Autentiseringsalternativ

Konfigurationsinställningarna för gatewaycontainern innehåller följande alternativ för att autentisera anslutningen mellan den lokala gatewayen och den molnbaserade API Management-instansens konfigurationsslutpunkt.

Alternativ	Att tänka på
Microsoft Entra-autentisering	Konfigurera en eller flera Microsoft Entra-appar för åtkomst till gatewayen. Hantera åtkomst separat per app. Konfigurera längre förfallotider för hemligheter i enlighet med organisationens principer. Använd Microsoft Entra-standardprocedurer för att tilldela eller återkalla användar- eller gruppbehörigheter till appar och rotera hemligheter.
Åtkomsttoken för gateway. (Kallas även för en autentiseringsnyckel.)	Tokenet löper ut åtminstone var 30:e dag och måste förnyas i containrarna. Backas upp av en gatewaynyckel som kan roteras oberoende (till exempel för att återkalla åtkomst). Om gatewaynyckeln återskapas ogiltigförklaras alla åtkomsttokener som skapas med den.

Tips/Råd

Se Azure API Management som en Event Grid-källa för information om Event Grid-händelser som genereras av en gateway med egen värd när en gatewayåtkomsttoken snart upphör att gälla eller har upphört att gälla. Använd dessa händelser för att säkerställa att distribuerade gatewayer alltid kan autentisera med sin associerade API Management-instans.

Anslutningsfel

När anslutningen till Azure går förlorad kan den lokalt installerade gatewayen inte ta emot konfigurationsuppdateringar, rapportera dess status eller ladda upp telemetri.

Den självhostade gatewayen är utformad för att "fail static" och kan överleva en tillfällig förlust av anslutning till Azure. Den kan distribueras med eller utan lokal konfigurationssäkerhetskopia. Med konfigurationssäkerhetskopiering sparar lokala gatewayer regelbundet en säkerhetskopia av den senaste nedladdade konfigurationen på en beständig volym som är kopplad till containern eller podden.

När konfigurationssäkerhetskopian är avstängd och anslutningen till Azure avbryts:

Att köra gatewayer med egen värd fortsätter att fungera med hjälp av en minnesintern kopia av konfigurationen.
Stoppade gatewayer med egen värd kan inte starta.

När konfigurationssäkerhetskopian är aktiverad och anslutningen till Azure avbryts:

Att köra gatewayer med egen värd fortsätter att fungera med hjälp av en minnesintern kopia av konfigurationen.
Stoppade gatewayer med egen värd kan starta med hjälp av en säkerhetskopia av konfigurationen.

När anslutningen återställs återansluter varje lokalt installerad gateway automatiskt till sin associerade API Management-instans och laddar ned alla konfigurationsuppdateringar som inträffade när gatewayen var offline.

Säkerhet

Begränsningar

Följande funktioner som är tillgängliga i hanterade gatewayer är inte tillgängliga i gatewayer med egen värd:

Återupptagande av TLS-session.
Omförhandling av klientcertifikat. Om du vill använda klientcertifikatautentisering måste API-konsumenter presentera sina certifikat som en del av den första TLS-handskakningen. För att säkerställa det här beteendet aktiverar du inställningen Förhandla klientcertifikat när du konfigurerar en egen värdbaserad gateway med anpassat värdnamn (domännamn).

Transportlagersäkerhet (TLS)

Protokoll som stöds

Gatewayer med egen värd stöder TLS v1.2 som standard.

Om du använder anpassade domäner kan du aktivera TLS v1.0 och/eller v1.1 i kontrollplanet.

Tillgängliga chiffersviter

Gatewayer med egen värd använder följande chiffersviter för både klient- och serveranslutningar:

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

Hantering av chiffersviter

Med v2.1.1 och senare kan du hantera chiffer som används via konfiguration:

net.server.tls.ciphers.allowed-suites gör att du kan definiera en kommaavgränsad lista över chiffer som ska användas för TLS-anslutningen mellan API-klienten och den lokalt installerade gatewayen.
net.client.tls.ciphers.allowed-suites gör att du kan definiera en kommaavgränsad lista över chiffer som ska användas för TLS-anslutningen mellan den lokala gatewayen och serverdelen.

Feedback

Var den här sidan till hjälp?