Application Gateway-komponenter

En programgateway fungerar som en enda kontaktpunkt för klienter. Den distribuerar inkommande programtrafik över flera serverdelspooler, bland annat virtuella Azure-datorer, vm-skalningsuppsättningar, Azure App Service och lokala/externa servrar. För att distribuera trafik använder en programgateway flera komponenter som beskrivs i den här artikeln.

IP-adresser för klientdelen

En frontend-IP-adress är den IP-adress som är associerad med en applikationsgateway. Du kan konfigurera en programgateway så att den har en offentlig IP-adress, en privat IP-adress eller både och. En programgateway stöder en offentlig eller en privat IP-adress. Det virtuella nätverket och den offentliga IP-adressen måste finnas på samma plats som din programgateway. När den har skapats associeras en IP-adress för klientdelen med en lyssnare.

Statisk kontra dynamisk offentlig IP-adress

Azure Application Gateway V2 SKU kan konfigureras för att stödja både en statisk intern IP-adress och en statisk publik IP-adress, eller endast en statisk publik IP-adress. Du kan också konfigurera den med endast en statisk intern (privat) IP-adress när du distribuerar en privat Application Gateway med networkIsolationEnabled inställt på True. För de stödda frontend-IP-adresskombinationerna, se Frontend IP-adresskonfiguration. För DNS-beteende i privat-IP-endast distributioner, se Application Gateway DNS resolution.

V1-SKU:n kan konfigureras för att stödja statisk eller dynamisk intern IP-adress och dynamisk offentlig IP-adress. Den dynamiska IP-adressen för Application Gateway ändras inte på en gateway som körs. Den kan bara ändras när du stoppar eller startar gatewayen. Det ändras inte vid systemfel, uppdateringar, Azure-värduppdateringar osv.

DNS-namnet som är associerat med en programgateway ändras inte under gatewayens livscykel. Därför bör du använda ett CNAME-alias och peka det på DNS-adressen för programgatewayen.

Lyssnare

En lyssnare är en logisk entitet som söker efter inkommande anslutningsbegäranden. En lyssnare accepterar en begäran om protokollet, porten, värdnamnet och IP-adressen som är associerad med begäran matchar samma element som är associerade med lyssnarkonfigurationen.

Innan du använder en programgateway måste du lägga till minst en lyssnare. Det kan finnas flera lyssnare kopplade till en programgateway och de kan användas för samma protokoll.

När en lyssnare har upptäckt inkommande begäranden från klienter dirigerar programgatewayen dessa begäranden till medlemmar i serverdelspoolen som konfigurerats i regeln.

Lyssnare stöder följande portar och protokoll.

Hamnar

En port är där en lyssnare tar emot klientförfrågningar. Du kan konfigurera portar för v1- och v2-SKU:er enligt nedan.

Protokoll

Application Gateway har stöd för webbprotokollen HTTP, HTTPS, HTTP/2 och WebSocket via dess Layer 7-proxy. Dessutom stöder den TLS- och TCP-protokoll via sin Layer 4-proxy, som kan konfigureras på samma resurs.

• Välj mellan HTTP-, HTTPS-, TLS- eller TCP-protokollen i lyssnarkonfigurationen.
• Du kan använda en HTTPS- eller TLS-lyssnare för TLS-avslutning. En HTTPS/TLS-lyssnare avlastar krypterings- och dekrypteringsarbetet till din programgateway, så att dina servrar inte belastas av TLS-beräkningskostnader.
• Stöd för WebSockets- och HTTP/2-protokoll tillhandahålls internt och WebSocket-stöd är aktiverat som standard. Det finns inga inställningar som kan konfigureras av användaren för att selektivt aktivera eller inaktivera WebSocket-stöd. Använd WebSockets med både HTTP- och HTTPS-lyssnare.

Följande tabell sammanfattar hur Application Gateway stödjer varje protokoll.

Anpassade felsidor

Med Application Gateway kan du skapa anpassade felsidor i stället för att visa standardfelsidor. Du kan använda din egen varumärkesprofil och layout med hjälp av en skräddarsydd felsida. Application Gateway visar en anpassad felsida när en begäran inte kan nå serverdelen.

Mer information finns i Anpassade felsidor för din programgateway.

Typer av lyssnare

Det finns två typer av lyssnare:

• Grundläggande. Den här typen av lyssnare lyssnar på en enda domänwebbplats, där den har en enda DNS-mappning till IP-adressen för programgatewayen. Den här lyssnarkonfigurationen krävs när du driver en enda webbplats bakom en applikationsgateway.

• Flera platser. Den här lyssnarkonfigurationen krävs när du vill konfigurera routning baserat på värdnamn eller domännamn för mer än ett webbprogram på samma programgateway. Den här funktionen gör att du kan konfigurera en mer effektiv topologi för dina distributioner genom att lägga till fler än 100 webbplatser i samma appgateway. Varje webbplats kan dirigeras till en egen serverdelspool. Tänk dig till exempel att de tre domänerna contoso.com, fabrikam.com och adatum.com pekar på appgatewayens IP-adress. Du skulle skapa tre lyssnare för flera platser och konfigurera varje lyssnare för respektive port- och protokollinställning.

  Du kan också definiera värdnamn med jokertecken i en lyssnare för flera webbplatser och upp till 5 värdnamn per lyssnare. För att lära dig mer, se värdnamn med jokertecken i lyssnaren.

  Mer information om hur du konfigurerar en lyssnare för flera platser finns i Värd för flera platser i Application Gateway med hjälp av Azure Portal.

När du har skapat en lyssnare associerar du den med en routningsregel för begäranden. Den här regeln avgör hur begäran som tas emot på lyssnaren ska dirigeras till serverdelen. Routningsregeln för begäran innehåller också den serverdelspool som ska dirigeras till och HTTP-inställningen där serverdelsporten, protokollet osv. nämns.

Begär routningsregler

En routningsregel för begäran är en nyckelkomponent i en programgateway eftersom den avgör hur trafik dirigeras på lyssnaren. Regeln binder lyssnaren, poolen för backendservrar och backend HTTP-inställningarna.

När en lyssnare accepterar en begäran vidarebefordrar routningsregeln för begäran begäran till serverdelen eller omdirigerar den någon annanstans. Om begäran vidarebefordras till backend definierar routingregeln vilken serverpool den ska vidarebefordras till. Routningsregeln för begäran avgör också om rubrikerna i begäran ska skrivas om. En lyssnare kan kopplas till en regel.

Det finns två typer av routningsregler för begäranden:

• Grundläggande. Alla begäranden på den associerade lyssnaren (till exempel blog.contoso.com/*) vidarebefordras till den associerade serverdelspoolen med hjälp av den associerade HTTP-inställningen.

• Sökvägsbaserad. Med den här routningsregeln kan du dirigera begäranden på den associerade lyssnaren till en specifik serverdelspool baserat på URL:en i begäran. Om url-sökvägen i en begäran matchar sökvägsmönstret i en sökvägsbaserad regel dirigerar regeln den begäran. Sökvägsmönstret tillämpas endast på URL-sökvägen, inte på dess frågeparametrar. Om URL-sökvägen för en lyssnarbegäran inte matchar någon av de sökvägsbaserade reglerna dirigeras begäran till standardserverdelspoolen och HTTP-inställningarna.

Följande tabell jämför de två regeltyperna.

Mer information finns i URL-baserad routning.

Stöd för omdirigering

Med routningsregeln för begäran kan du också omdirigera trafik på programgatewayen. Det här är en allmän omdirigeringsmekanism, så du kan omdirigera till och från valfri port som du definierar med hjälp av regler.

Du kan välja omdirigeringsmålet som en annan lyssnare (som kan hjälpa till att aktivera automatisk HTTP till HTTPS-omdirigering) eller en extern webbplats. Du kan också välja att omdirigeringen ska vara tillfällig eller permanent, eller att lägga till URI-sökvägen och frågesträngen i den omdirigerade URL:en.

Mer information finns i Omdirigera trafik på din programgateway.

Skriva om HTTP-huvuden och URL

Application Gateway kan lägga till, ta bort eller uppdatera HTTP(S)-förfrågnings- och svarshuvuden, tillsammans med URL-väg och frågesträngsparametrar, när trafiken rör sig mellan klienter och backend-pooler. För en fullständig förklaring och konfigurationssteg, se Omskriv HTTP-headers och URL på din applikationsgateway.

HTTP-inställningar

En HTTP-inställning, även kallad backend-inställning, är den konfiguration som avgör hur trafiken når backend-servrarna. Den definierar porten och protokollet som applikationsgatewayen använder för att ansluta till dessa servrar, hur anslutningar beter sig och hur gatewayen övervakar backend-hälsan. En begäran om routingregel specificerar vilken HTTP-inställning som ska tillämpas när den vidarebefordrar en begäran till en backend-pool.

Porten och protokollet som används i HTTP-inställningarna avgör om trafiken mellan programgatewayen och serverdelsservrarna är krypterad (tillhandahåller TLS från slutpunkt till slutpunkt) eller okrypterad.

Den här komponenten används också för att:

• Avgör om en användarsession ska behållas på samma server med hjälp av den cookiebaserade sessionstillhörigheten.

• Ta bort medlemmar i serverdelspoolen på ett kontrollerat sätt genom att använda anslutningsdränering.

• Associera en anpassad probe för att övervaka hälsa hos backend, ange tidsgränsintervallet för begäran, åsidosätta värdnamnet och sökvägen i begäran och med ett enkelt klick ange inställningar för App Service-backend.

Serverdelspooler

En serverdelspool dirigerar begäran till serverdelsservrar som hanterar begäran. Backend-pooler kan innehålla:

• Nätverkskort
• Skalningsuppsättningar för virtuella maskiner
• Offentliga IP-adresser
• Interna IP-adresser
• FQDN (fullständigt kvalificerade domännamn) eller korta namn (domännamn med en etikett), förutsatt att DNS-servern kan lösa dem
• Backend-tjänster för flera klienter, såsom Azure App Service och Azure Container Apps. Se Skydda containerappar med Application Gateway och WAF för implementeringsvägledning.

Medlemmar i Application Gateway-backendpoolen är inte knutna till en tillgänglighetsuppsättning. En programgateway kan kommunicera med instanser utanför det virtuella nätverk som den finns i. Därför kan medlemmarna i serverdelspoolerna vara över kluster, mellan datacenter eller utanför Azure, så länge det finns IP-anslutning.

Om du använder interna IP-adresser som medlemmar i serverdelspoolen måste du använda peering för virtuella nätverk eller en VPN-gateway. Peering för virtuella nätverk stöds och är fördelaktigt för belastningsutjämning av trafik i andra virtuella nätverk.

En programgateway kan också kommunicera med lokala servrar när de är anslutna via Azure ExpressRoute eller VPN-tunnlar om trafik tillåts.

Du kan skapa olika back-endpooler för olika typer av förfrågningar. Skapa till exempel en serverdelspool för allmänna begäranden och sedan en annan serverdelspool för begäranden till mikrotjänsterna för ditt program.

När du har lagt till virtuella maskinskaleenheter som medlem i back-end poolen måste du uppgradera instanser av dessa. Tills dess att du uppgraderar skalningsuppsättningens instanser, kommer backend att vara ohälsosam.

Hälsokontroller

Som standard övervakar en programgateway hälsotillståndet för alla resurser i serverdelspoolen och tar automatiskt bort felaktiga resurser. Den övervakar sedan osunda instanser och lägger till dem i den friska serverdelspoolen när de blir tillgängliga och svarar på hälsokontroller.

Förutom att använda standardhälsokontroller kan du även anpassa hälsoavsökningen så att den passar programmets krav. Anpassade sonder ger mer detaljerad kontroll över hälsoövervakningen. När du använder anpassade avsökningar kan du konfigurera ett anpassat värdnamn, URL-sökväg, avsökningsintervall och hur många misslyckade svar som ska accepteras innan du markerar serverdelspoolinstansen som felaktig, anpassade statuskoder och svarstextmatchning osv. Vi rekommenderar att du konfigurerar anpassade avsökningar för att övervaka hälsotillståndet för varje serverdelspool.

Mer information finns i Övervaka hälsotillståndet för din programgateway.

Nästa steg

Skapa en programgateway:

• I Azure-portalen
• Genom att använda Azure PowerShell
• Genom att använda Azure CLI