Publicera interna API:er till externa användare

Azure API Management
Azure Application Gateway
Azure DevOps
Azure Monitor
Azure Virtual Network

I det här scenariot konsoliderar en organisation flera API:er med hjälp av Azure API Management som distribueras i ett virtuellt nätverk.

Arkitektur

Arkitekturdiagram som visar hela livscykeln för interna API:er som används av externa användare.

Ladda ned en Visio-fil med den här arkitekturen.

Föregående diagram omfattar en fullständig livscykel för interna API:er som används av externa användare.

Dataflöde

Dataflödena enligt följande:

  1. Utvecklare checkar in kod på en GitHub-lagringsplats som är ansluten till en CI/CD-pipelineagent som är installerad på en virtuell Azure-dator.
  2. Agenten push-överför bygget till API-programmet som finns på ILB ASE.
  3. Azure API Management använder föregående API:er via HOST-huvuden som anges i API Management princip.
  4. API Management använder App Service-miljön DNS-namn för alla API:er.
  5. Application Gateway exponerar API Management utvecklar- och API-portalen.
  6. Azure Privat DNS används för att dirigera trafiken internt mellan ASE, API Management och Application Gateway.
  7. Externa användare använder den exponerade utvecklarportalen för att använda API:erna via Application Gateway offentliga IP-adress.

Komponenter

  • Med Azure Virtual Network kan Azure-resurser kommunicera säkert med varandra, Internet och lokala nätverk.
  • Med Azure Privat DNS kan domännamn matchas i ett virtuellt nätverk utan att du behöver lägga till en anpassad DNS-lösning.
  • Azure API Management hjälper organisationer att publicera API:er till externa utvecklare, partner och interna utvecklare för att använda sina data och tjänster.
  • Application Gateway är en lastbalanserare för webbtrafik som hjälper dig att hantera trafik till dina webbprogram.
  • Intern Load Balancer App Service-miljön är en Azure App Service funktion som ger en helt isolerad och dedikerad miljö för säker körning av App Service appar i hög skala.
  • Azure DevOps är en tjänst för att hantera utvecklingslivscykeln och innehåller funktioner för planering och projekthantering, kodhantering, kompilering och lansering.
  • Application Insights är en utökningsbar APM-tjänst (Application Performance Management) för webbutvecklare på flera plattformar.
  • Azure Cosmos DB är Microsofts globalt distribuerade databastjänst för flera modeller.

Alternativ

Scenarioinformation

I det här scenariot är en organisation värd för flera API:er med hjälp av Azure Application Service Environment (ILB ASE), och de vill konsolidera dessa API:er internt med hjälp av Azure API Management (APIM) som distribuerats i en Virtual Network. Den interna API Management-instansen kan också exponeras för externa användare för att möjliggöra användning av API:ernas fulla potential. Den här externa exponeringen kan uppnås med hjälp av Azure Application Gateway vidarebefordringsbegäranden till den interna API Management-tjänsten, som i sin tur förbrukar de API:er som distribueras i ASE.

  • Webb-API:erna finns över säkra HTTPS-protokoll och kommer att använda ett TLS-certifikat.
  • Den Application Gateway är också konfigurerad via port 443 för säkra och tillförlitliga utgående anrop.
  • Tjänsten API Management är konfigurerad för att använda anpassade domäner med hjälp av TLS-certifikat.
  • Granska den föreslagna nätverkskonfigurationen för App Service-miljöer
  • Det måste finnas ett uttryckligt omnämnande om port 3443 som gör det möjligt för API Management att hantera via Azure Portal eller PowerShell.
  • Använd principer i APIM för att lägga till ett HOST-huvud för DET API som finns i ASE. Detta säkerställer att ASE:s lastbalanserare vidarebefordrar begäran korrekt.
  • API Management accepterar ASE:s DNS-post för alla appar som finns under App Service-miljöer. Lägg till en APIM-princip för att uttryckligen ange HOST-huvudet så att ASE-lastbalanseraren kan skilja mellan appar under App Service-miljön.
  • Överväg att integrera med Azure Application Insights, som även visar mått via Azure Monitor för övervakning.
  • Om du använder CI/CD-pipelines för att distribuera interna API:er bör du överväga att skapa en egen värdbaserad agent på en virtuell dator i Virtual Network.

Potentiella användningsfall

  • Synkronisera kundadressinformation internt när kunden har gjort en ändring.
  • Locka utvecklare till din plattform genom att exponera unika datatillgångar.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över grundpelare för tillförlitlighet."

Tillgänglighet

Du kan distribuera Azure API Management-tjänsten som en distribution i flera regioner för högre tillgänglighet och för att minska svarstiderna. Den här funktionen är endast tillgänglig i Premium-läge. Den API Management tjänsten i det här specifika scenariot använder API:er från App Service-miljöer. Du kan också använda APIM för API:er som finns i den interna lokala infrastrukturen.

App Service Miljöer kan använda Traffic Manager-profiler för att distribuera trafiken i App Service miljöer för högre skala och tillgänglighet.

Återhämtning

Även om det här exempelscenariot handlar mer om konfiguration bör API:erna som finns på App Service Environments vara tillräckligt motståndskraftiga för att hantera fel i begäranden, som så småningom hanteras av API Management-tjänsten och Application Gateway. Överväg mönster för återförsök och kretsbrytare i API-designen. Allmän vägledning om hur du utformar motståndskraftiga lösningar finns i Designa elastiska program för Azure.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

Eftersom det föregående exempelscenariot finns helt i ett internt nätverk distribueras redan API Management och ASE i en skyddad infrastruktur (Azure VNet). Du kan integrera Application Gateways med Microsoft Defender för molnet för att tillhandahålla ett sömlöst sätt att förhindra, identifiera och reagera på hot mot miljön. Allmän vägledning om hur du utformar säkra lösningar finns i Dokumentation om Azure-säkerhet.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra driftseffektiviteten. Mer information finns i Översikt över grundpelare för kostnadsoptimering.

API Management finns på fyra nivåer: utvecklare, basic, standard och premium. Du hittar detaljerad vägledning om skillnaden på dessa nivåer i prisvägledningen för Azure API Management här.

Kunder kan skala API Management genom att lägga till och ta bort enheter. Varje enhet har kapacitet som är beroende av dess nivå.

Anteckning

Du kan använda developer-nivån för utvärdering av API Management funktioner. Du bör inte använda developer-nivån för produktion.

Om du vill visa beräknade kostnader och anpassa efter dina distributionsbehov kan du ändra antalet skalningsenheter och App Service instanser i Priskalkylatorn för Azure.

På samma sätt hittar du prisvägledningen för App Service Environments.

Du kan konfigurera Application Gateway prissättning beroende på vilken nivå och vilka resurser som krävs.

Prestandaeffektivitet

Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.

Skalbarhet

Du kan skala ut API Management instanser beroende på ett antal faktorer, till exempel antal och frekvens för samtidiga anslutningar, typ och antal konfigurerade principer, storlekar för förfrågningar och svar samt svarsfördröjningar för API:erna. Alternativen för utskalning av instanser är tillgängliga på nivåerna Basic, Standard och Premium, men är bundna av en övre skalningsgräns på nivåerna Basic och Standard. Instanserna kallas enheter och kan skalas upp till högst två enheter på Basic-nivån, fyra enheter på standardnivån och valfritt antal enheter på Premium-nivån. Alternativ för automatisk skalning är också tillgängliga för att aktivera utskalning baserat på regler.

App Service Miljöer är utformade för skalning med gränser baserat på prisnivån. Du kan konfigurera appar som finns under App Service-miljöer för att skala ut (antal instanser) eller skala upp (instansstorlek) beroende på programmets krav.

Azure Application Gateway automatisk skalning är tillgängligt som en del av zonredundant SKU:n i alla globala Azure-regioner. Se funktionen för offentlig förhandsversion om automatisk skalning av App Gateway.

Distribuera det här scenariot

Förhandskrav och antaganden

  1. Du måste köpa ett anpassat domännamn.
  2. Du behöver ett TLS-certifikat (vi använde ett jokerteckencertifikat från Azure Certificates Service) för att använda ett för alla våra anpassade domäner. Du kan också skaffa ett självsignerat certifikat för Dev Test-scenarier.
  3. Den här specifika distributionen använder domännamnet contoso.org och ett jokertecken-TLS-certifikat för domänen.
  4. Distributionen använder resursnamnen och adressutrymmena som nämns i avsnittet Distribution. Du kan konfigurera resursnamn och adressutrymmen.

Distribuera och sätta ihop delarna

Distribuera till Azure

Du måste ytterligare konfigurera de komponenter som distribueras med hjälp av föregående Resource Manager mall enligt följande:

  1. VNet med följande konfigurationer:

    • Namn: ase-internal-vnet
    • Adressutrymme för VNet: 10.0.0.0/16
    • Fyra undernät
      • backendSubnet för DNS-tjänsten: 10.0.0.0/24
      • apimsubnetför intern API Management service: 10.0.1.0/28
      • asesubnet för ILB ASE: 10.0.2.0/24
      • VMSubnet for Test VMs and Internal DevOps Hosted Agent VM: 10.0.3.0/24
  2. Privat DNS (offentlig förhandsversion) eftersom det virtuella nätverket måste vara tomt för att lägga till en DNS-tjänst.

  3. App Service-miljön med alternativet Intern Load Balancer (ILB): aseinternal (DNS: aseinternal.contoso.org). När distributionen är klar laddar du upp jokerteckencertifikatet för ILB

  4. App Service planera med ASE som plats

  5. En API-app (App Services för enkelhetens skull) – srasprest (URL: https://srasprest.contoso.org) – ASP.NET MVC-baserat webb-API. Efter distributionen konfigurerar du:

    • Webbapp för att använda TLS-certifikatet
    • Application Insights till föregående appar: api-insights
    • Skapa en Azure Cosmos DB-tjänst för webb-API:er som finns internt i VNet: noderestapidb
    • Skapa DNS-poster i Privat DNS zon som skapats
    • Du kan använda Azure Pipelines för att konfigurera agenterna på Virtual Machines för att distribuera koden för webbappen i det interna nätverket
    • Om du vill testa API-appen internt skapar du en virtuell testdator i VNet-undernätet
  6. Skapa API Management tjänst:apim-internal

  7. Konfigurera tjänsten för att ansluta till ett internt virtuellt nätverk i undernätet: apimsubnet. När distributionen är klar utför du följande ytterligare steg:

    • Konfigurera anpassade domäner för APIM-tjänster med hjälp av TLS
      • API-portalen (api.contoso.org)
      • Dev Portal (portal.contoso.org)
      • I avsnittet API:er konfigurerar du ASE-appar med HJÄLP av ASE:s DNS-namn som lagts till Princip för VÄRDhuvud för webbappen
      • Använd den tidigare skapade virtuella testdatorn för att testa den interna API Management-tjänsten på Virtual Network

    Anteckning

    Det går inte att testa APIM-API:erna från Azure Portal eftersom api.contoso.org inte kan lösas offentligt.*

  8. Konfigurera Application Gateway (WAF V1) för åtkomst till API-tjänsten: apim-gateway på port 80. Lägg till TLS-certifikat i Application Gateway och motsvarande hälsoavsökningar och http-inställningar. Konfigurera även regler och lyssnare för att använda TLS-certifikatet.

När föregående steg har slutförts konfigurerar du DNS-posterna i webbregistratorns CNAME-poster för api.contoso.org och portal.contoso.org med Application Gateway offentliga DNS-namn: ase-appgtwy.westus.cloudapp.azure.com. Kontrollera att du kan nå Dev-portalen från offentlig och att du kan testa APIM-tjänst-API:erna med hjälp av Azure Portal.

Anteckning

Det är inte bra att använda samma URL för interna och externa slutpunkter för APIM-tjänsterna (men i den här demonstrationen är båda URL:erna desamma). Om du väljer att ha olika URL:er för interna och externa slutpunkter kan du använda Application Gateway WAF v2, som stöder http-omdirigering och mycket mer.

Deltagare

Den här artikeln underhålls av Microsoft. Den skrevs ursprungligen av följande deltagare.

Huvudförfattare:

Andra deltagare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Migrera en webbapp med Azure API Management