Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A KÖVETKEZŐKRE VONATKOZIK: Fejlesztő | Prémium
A saját üzemeltetésű átjáró az alapértelmezett felügyelt átjáró opcionális, tárolóalapú verziója, amely minden API Management-példányban megtalálható. Olyan helyzetekben hasznos, mint az átjárók ugyanabban a környezetben való elhelyezése, ahol az API-kat üzemelteti. A saját üzemeltetésű átjáróval javíthatja az API-forgalom folyamatát, és kezelheti az API biztonsági és megfelelőségi követelményeit.
Ez a cikk azt ismerteti, hogy az Azure API Management saját üzemeltetésű átjáró funkciója hogyan teszi lehetővé a hibrid és többfelhős API-kezelést. Emellett bemutatja a funkció magas szintű architektúráját, és ismerteti annak képességeit.
A felügyelt és a saját üzemeltetésű átjárók közötti különbségek áttekintéséhez tekintse meg az API-átjárót az API Managementben.
Hibrid és többfelhős API-felügyelet
A saját üzemeltetésű átjáró funkció kibővíti a hibrid és többfelhős környezetek API Management-támogatását, és lehetővé teszi a helyszínen és felhőkben üzemeltetett API-k hatékony és biztonságos kezelését egyetlen Azure-beli API Management-példányból.
A saját üzemeltetésű átjáróval rugalmasan helyezheti üzembe az API Management-átjáró összetevő tárolóalapú verzióját ugyanazon környezetekben, ahol az API-kat üzemelteti. Az összes saját üzemeltetésű átjárót az API Management-példányból felügyeljük, amellyel összevontuk őket, így minden belső és külső API-ban biztosítjuk a láthatóságot és az egységes felügyeleti élményt.
Minden API Management-példány a következő fő összetevőkből áll:
- Egy API-ként közzétett felügyeleti sík, amellyel konfigurálható a szolgáltatás az Azure Portalon, a PowerShellen és más támogatott technológiákon keresztül
- Átjáró (vagy adatsík), amely az API-kérések proxyzásával, szabályzatok alkalmazásával és telemetriai adatok gyűjtésével foglalkozik
- Fejlesztői portál, amelyet a fejlesztők az API-k felderítésére, megismerésére és előkészítésére használnak
Alapértelmezés szerint ezek az összetevők az Azure-ban vannak üzembe helyezve, így az API-forgalom (az alábbi képen egyszínű fekete nyilakkal) az Azure-on halad át, függetlenül attól, hogy hol találhatók az API-kat implementáló háttérrendszerek. Ennek a modellnek a működési egyszerűsége a megnövekedett késés, a megfelelőségi problémák és bizonyos esetekben a többlet adatátviteli díjak költségével jár.
A saját üzemeltetésű átjárók ugyanabban a környezetben való üzembe helyezése, ahol a háttér API-implementációk üzemelnek, lehetővé teszi az API-forgalom közvetlen átvitelét a háttér API-kba, ami csökkenti a késést, optimalizálja az adatátviteli költségeket, és lehetővé teszi a megfelelőséget, miközben megtartja a szervezet összes API-jának egyetlen felügyeleti, megfigyelhetőségi és felderítési pontjának előnyeit, függetlenül attól, hogy hol üzemeltetik az implementációkat.
Csomagolás
A saját üzemeltetésű átjáró Linux-alapú Docker-tárolórendszerképként érhető el a Microsoft Artifact Registryből. Üzembe helyezhető a Dockerben, a Kubernetesben vagy bármely más tárolóvezénylési megoldásban, amely egy kiszolgálófürtön fut a helyszínen, felhőinfrastruktúra vagy kiértékelési és fejlesztési célokra egy személyes számítógépen. A saját üzemeltetésű átjárót fürtbővítményként is üzembe helyezheti egy Azure Arc-kompatibilis Kubernetes-fürtön.
Konténerképek
A saját üzemeltetésű átjárókhoz különböző tárolórendszerképek érhetők el:
| Címkekonvenció | Ajánlás | példa | Gördülő címke | Ajánlott a termeléshez |
|---|---|---|---|---|
{major}.{minor}.{patch} |
Ezzel a címkével mindig ugyanazt az átjáróverziót futtathatja. | 2.0.0 |
❌ | ✔️ |
v{major} |
Ezzel a címkével mindig futtathatja az átjáró főverzióját minden új funkcióval és javítással. | v2 |
✔️ | ❌ |
v{major}-preview |
Ezt a címkét akkor használja, ha mindig a legújabb előzetes verziójú tárolórendszerképet szeretné futtatni. | v2-preview |
✔️ | ❌ |
latest |
Ezt a címkét akkor használja, ha ki szeretné értékelni a saját üzemeltetésű átjárót. | latest |
✔️ | ❌ |
beta
1 |
Ezt a címkét akkor használja, ha ki szeretné értékelni a saját üzemeltetésű átjáró előzetes verzióit. | beta |
✔️ | ❌ |
Az elérhető címkék teljes listáját itt találja.
1Az előzetes verziók hivatalosan nem támogatottak, és csak kísérleti célokra használhatók. Tekintse meg a saját üzemeltetésű átjáró támogatási szabályzatát.
Címkék használata a hivatalos üzembehelyezési lehetőségekben
Az Azure Portal üzembe helyezési beállításai a v2 címkét használják, amely lehetővé teszi, hogy az önálló üzemeltetésű átjáró v2 konténerképének legújabb verzióját használja, az összes funkciófrissítéssel és javítással együtt.
Megjegyzés:
A parancs és a YAML-kódrészletek hivatkozásként vannak megadva. Ha szeretné, egy konkrétabb címkét is használhat.
Ha Helm-diagrammal rendelkező átjárót telepít, a rendszer optimalizálja a képcímkézést. A Helm-diagram alkalmazásverziója fixálja az átjáró verzióját egy adott verzióra, és nem támaszkodik latest-ra.
További információ: Api Management saját üzemeltetésű átjáró telepítése a Kubernetesen a Helm használatával.
Görgethető címkék használatának kockázata
A gördülő címkék olyan címkék, amelyek a tárolólemezkép új verziójának megjelenésekor esetleg frissülnek. Az ilyen típusú címkék lehetővé teszik a tárolófelhasználók számára, hogy anélkül fogadják a tárolólemezkép frissítéseit, hogy frissíteniük kellene az üzemelő példányaikat.
Ha ilyen típusú címkét használ, előfordulhat, hogy különböző verziókat futtat párhuzamosan anélkül, hogy észrevenned, például ha skálázási műveleteket hajt végre a v2 címke frissítése után.
Példa: A v2 címke a tároló lemezképével 2.0.0 együtt jelenik meg. A 2.1.0 kiadásakor a v2 címke a 2.1.0 képhez lesz csatolva.
Fontos
Érdemes lehet egy adott verziócímkét használni az éles környezetben, hogy elkerülje az újabb verzió véletlen frissítését.
Csatlakozás az Azure-hoz
A saját üzemeltetésű átjárók kimenő TCP/IP-kapcsolatot igényelnek az Azure-hoz a 443-as porton. Minden saját üzemeltetésű átjárót egyetlen API Management-példányhoz kell társítani, és a felügyeleti síkon keresztül kell konfigurálni. A saját üzemeltetésű átjárók az Azure-hoz való kapcsolódást használják a következő célokra:
- Állapotának jelentése percenkénti szívverési üzenetek küldésével.
- Rendszeresen (10 másodpercenként) ellenőrizze és alkalmazza a konfigurációs frissítéseket, amikor elérhetők.
- Metrikák küldése az Azure Monitornak, ha erre van konfigurálva.
- Események küldése az Application Insightsba, ha erre van konfigurálva.
Teljes tartománynév-függőségek
A megfelelő működéshez minden saját üzemeltetésű átjárónak kimenő kapcsolatot kell létesítenie a 443-as porton a felhőalapú API Management-példányhoz társított következő végpontokkal:
| Végpont | Szükséges? | Jegyzetek |
|---|---|---|
| A konfigurációs végpont állomásneve |
<api-management-service-name>.configuration.azure-api.net
1 |
Az egyéni gazdagépnevek is támogatottak, és az alapértelmezett gazdagépnév helyett használhatók. |
| Az API Management-példány nyilvános IP-címe | ✔️ | Az elsődleges hely IP-címe elegendő. |
| Az Azure Storage szolgáltatás címkéjének nyilvános IP-címei | Nem kötelező2 | Az IP-címeknek meg kell felelnie az API Management-példány elsődleges helyének. |
| Az Azure Blob Storage-fiók állomásneve | Nem kötelező2 | A <blob-storage-account-name>.blob.core.windows.net példányhoz társított fiók. |
| Az Azure Table Storage-fiók állomásneve | Nem kötelező2 | A <table-storage-account-name>.table.core.windows.net példányhoz társított fiók. |
| Az Azure Resource Manager végpontjai | Nem kötelező3 | A szükséges végpont management.azure.com. |
| Végpontok a Microsoft Entra-integrációhoz | Opcionális4 | A szükséges végpontok a következők: <region>.login.microsoft.com és login.microsoftonline.com. |
| Végpontok az Azure Application Insights-integrációhoz | Opcionális5 | A minimálisan szükséges végpontok a következők rt.services.visualstudio.com:443: , dc.services.visualstudio.com:443és {region}.livediagnostics.monitor.azure.com:443. További információkért tekintse meg az Azure Monitor dokumentációját. |
| Az Event Hubs-integráció végpontjai | Opcionális5 | További információkért tekintse meg az Azure Event Hubs dokumentációját. |
| Külső gyorsítótár-integráció végpontjai | Opcionális5 | Ez a követelmény a használt külső gyorsítótártól függ. |
1A belső virtuális hálózaton található API Management-példányokkal kapcsolatos információkért lásd: Belső virtuális hálózaton belüli kapcsolat.
2Csak akkor szükséges a v2-ben, ha api-felügyelőt vagy kvótákat használnak a szabályzatokban.
3Csak akkor szükséges, ha Az RBAC-engedélyek ellenőrzéséhez Microsoft Entra-hitelesítést használ.
4Csak akkor szükséges, ha Microsoft Entra-hitelesítést vagy a Microsoft Entra-hoz kapcsolódó szabályzatokat használ.
5Csak akkor szükséges, ha a szolgáltatás használatban van, és nyilvános IP-címet, portot és állomásnévadatokat igényel.
Fontos
- A DNS-gazdagépneveknek feloldhatónak kell lenniük az IP-címekre, és a megfelelő IP-címeknek elérhetőnek kell lenniük.
- A társított tárfiókok nevei az Azure Portalon, a szolgáltatás hálózati kapcsolati állapotlapján jelennek meg.
- A társított tárfiókok alapjául szolgáló nyilvános IP-címek dinamikusak, és értesítés nélkül változhatnak.
Kapcsolat belső virtuális hálózaton
Privát kapcsolat. Ha a saját üzemeltetésű átjáró virtuális hálózaton van üzembe helyezve, engedélyezze a v2 konfigurációs végponthoz való privát kapcsolatot a saját üzemeltetésű átjáró helyéről, például privát DNS használatával egy társhálózatban.
Internetkapcsolat. Ha a saját üzemeltetésű átjárónak csatlakoznia kell a v2 konfigurációs végponthoz az interneten keresztül, konfiguráljon egy egyéni állomásnevet a konfigurációs végponthoz, és tegye elérhetővé a végpontot az Azure Application Gateway használatával.
Hitelesítési lehetőségek
Az átjárótároló konfigurációs beállításai a következő lehetőségeket biztosítják a saját üzemeltetésű átjáró és a felhőalapú API Management-példány konfigurációs végpontja közötti kapcsolat hitelesítéséhez.
| Lehetőség | Megfontolások |
|---|---|
| Microsoft Entra hitelesítés | Konfiguráljon egy vagy több Microsoft Entra-alkalmazást az átjáróhoz való hozzáféréshez. A hozzáférés kezelése alkalmazásonként külön-külön. A titkos kódok hosszabb lejárati idejét a szervezet szabályzatainak megfelelően konfigurálhatja. Szabványos Microsoft Entra-eljárásokkal rendelhet hozzá vagy vonhat vissza felhasználói vagy csoportengedélyeket az alkalmazásokhoz, és elforgathatja a titkos kulcsokat. |
| Átjáró hozzáférési jogkivonata. (Más néven hitelesítési kulcs.) | A hozzáférési token legalább minden 30 napban lejár, és meg kell újítani a konténerekben. Olyan átjárókulcs által támogatott, amely függetlenül forgatható (például a hozzáférés visszavonására). Az átjárókulcs újragenerálása érvényteleníti a vele létrehozott összes hozzáférési jogkivonatot. |
Jótanács
Az Azure API Managementet Event Grid-forrásként tekintheti meg azokról az Event Grid-eseményekről, amelyeket egy saját üzemeltetésű átjáró hoz létre, amikor egy átjáró hozzáférési jogkivonata hamarosan lejár vagy lejárt. Ezekkel az eseményekkel biztosíthatja, hogy az üzembe helyezett átjárók mindig hitelesíthetők legyenek a társított API Management-példányukkal.
Csatlakozási hibák
Ha az Azure-hoz való kapcsolat megszakad, a saját üzemeltetésű átjáró nem tud konfigurációs frissítéseket fogadni, állapotjelentést vagy telemetriai adatokat feltölteni.
Az önállóan működtetett átjáró úgy lett kialakítva, hogy "statikus állapotban maradjon" probléma esetén, és képes legyen túlélni az Azure-hoz való csatlakozás ideiglenes megszakadását. Helyi konfigurációs biztonsági mentéssel vagy anélkül is üzembe helyezhető. A konfigurációs biztonsági mentéssel a saját üzemeltetésű átjárók rendszeresen mentik a legújabb letöltött konfiguráció biztonsági másolatát a tárolójukhoz vagy podjukhoz csatlakoztatott állandó köteten.
Ha a konfigurációs biztonsági mentés ki van kapcsolva, és megszakad a kapcsolat az Azure-hoz:
- A saját üzemeltetésű átjárók futtatása továbbra is működik a konfiguráció memóriabeli másolatának használatával.
- A leállított saját üzemeltetésű átjárók nem fognak tudni elindulni.
Ha a konfigurációs biztonsági mentés be van kapcsolva, és megszakad a kapcsolat az Azure-sal:
- A saját üzemeltetésű átjárók futtatása továbbra is működik a konfiguráció memóriabeli másolatának használatával.
- Leállított saját üzemeltetésű átjárók újraindíthatók a konfiguráció biztonsági másolatának használatával.
A kapcsolat visszaállításakor a kimaradás által érintett összes saját üzemeltetésű átjáró automatikusan újracsatlakozik a társított API Management-példányhoz, és letölti az átjáró offline állapotában történt összes konfigurációs frissítést.
Biztonság
Korlátozások
A felügyelt átjárókban elérhető alábbi funkciók nem érhetők el a saját üzemeltetésű átjárókban:
- TLS-munkamenet újraindítása.
- Ügyféltanúsítvány újratárgyalása. Az ügyféltanúsítvány-hitelesítés használatához az API-felhasználóknak a kezdeti TLS-kézfogás részeként kell bemutatniuk a tanúsítványaikat. Ennek a viselkedésnek a biztosításához engedélyezze az Ügyféltanúsítvány egyeztetése beállítást egy saját üzemeltetésű átjáró egyéni gazdagépnevének (tartománynév) konfigurálásakor.
Szállítási réteg biztonság (TLS)
Támogatott protokollok
A saját üzemeltetésű átjárók alapértelmezés szerint támogatják a TLS 1.2-s verziót.
Egyéni tartományok használata esetén engedélyezheti a TLS 1.0-s és/vagy 1.1-s verziójának használatát a vezérlősíkon.
Elérhető titkosítási csomagok
A saját üzemeltetésű átjárók az alábbi titkosítási csomagokat használják az ügyfél- és kiszolgálókapcsolatokhoz:
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
Titkosítási csomagok kezelése
A 2.1.1-s és újabb verzióval kezelheti a konfigurációval használt titkosításokat:
-
net.server.tls.ciphers.allowed-suitesLehetővé teszi az API-ügyfél és a saját üzemeltetésű átjáró közötti TLS-kapcsolathoz használandó titkosítások vesszővel tagolt listájának definiálását. -
net.client.tls.ciphers.allowed-suiteslehetővé teszi a saját üzemeltetésű átjáró és a háttérrendszer közötti TLS-kapcsolathoz használandó titkosítások vesszővel tagolt listájának definiálását.
Kapcsolódó tartalom
- API-kapu áttekintése
- Támogatási szabályzat saját üzemeltetésű átjáróhoz
- API Management hibrid és többfelhős világban
- Útmutató saját üzemeltetésű átjáró futtatásához a Kubernetesen éles üzemmódban
- Saját üzemeltetésű átjáró üzembe helyezése a Dockerben
- Saját üzemeltetésű átjáró üzembe helyezése a Kubernetesben
- Saját üzemeltetésű átjáró üzembe helyezése Azure Arc-kompatibilis Kubernetes-fürtön
- Saját üzemeltetésű átjáró üzembe helyezése az Azure Container Appsben
- Saját üzemeltetésű átjáró konfigurációs beállításai
- Megfigyelhetőségi képességek az API Managementben
- Dapr-integráció saját üzemeltetésű átjáróval