Nätverk för App Service-miljö

App Service-miljön är en distribution med en enda klientorganisation av Azure App Service som är värd för Windows- och Linux-containrar, webbappar, API-appar, logikappar och funktionsappar. När du installerar en App Service-miljön väljer du det virtuella Azure-nätverk som du vill att det ska distribueras i. All inkommande och utgående programtrafik finns i det virtuella nätverk som du anger. Du distribuerar till ett enda undernät i ditt virtuella nätverk och inget annat kan distribueras till det undernätet.

Kommentar

Den här artikeln handlar om App Service-miljön v3, som används med Isolerade v2 App Service-planer.

Krav för undernät

Följande är den minsta uppsättningen krav för det undernät som din App Service-miljön finns i.

• Undernätet måste delegeras till Microsoft.Web/hostingEnvironments.
• Undernätet måste vara tomt.
• Undernätets egenskap måste formateras addressPrefix som en sträng, inte som en matris.

Storleken på undernätet kan påverka skalningsgränserna för App Service-planinstanserna inom App Service-miljön. För produktionsskala rekommenderar vi ett /24 adressutrymme (256 adresser) för ditt undernät. Om du planerar att skala nästan maximal kapacitet på 200 instanser i vår App Service-miljön och du planerar frekventa upp-/nedskalningsåtgärder rekommenderar vi ett /23 adressutrymme (512 adresser) för ditt undernät.

Om du använder ett mindre undernät bör du vara medveten om följande begränsningar:

• Ett visst undernät har fem adresser reserverade för hanteringsändamål. Förutom hanteringsadresserna skalar App Service-miljön dynamiskt den stödjande infrastrukturen och använder mellan 7 och 27 adresser, beroende på konfiguration och belastning. Du kan använda de återstående adresserna för instanser i App Service-planen. Den minsta storleken på ditt undernät är ett /27 adressutrymme (32 adresser).
• För alla kombinationer av App Service-planoperativsystem/SKU som används i din App Service-miljön som I1v2 Windows skapas en standby-instans för varje 20 aktiva instanser. Standby-instanserna kräver också IP-adresser.
• Vid skalning av App Service-planer i App Service-miljön upp/ned, fördubblas mängden IP-adresser som används av App Service-planen tillfälligt medan skalningsåtgärden slutförs. De nya instanserna måste vara i full drift innan de befintliga instanserna avetableras.
• Plattformsuppgraderingar behöver kostnadsfria IP-adresser för att säkerställa att uppgraderingar kan ske utan avbrott i utgående trafik.
• När du har skalat upp, ned eller slutfört åtgärder kan det ta en kort tid innan IP-adresser släpps. I sällsynta fall kan den här åtgärden vara upp till 12 timmar.
• Om adresserna i undernätet tar slut kan du begränsas från att skala ut dina App Service-planer i App Service-miljön. En annan möjlighet är att du kan uppleva ökad svarstid under intensiv trafikbelastning, om Microsoft inte kan skala den stödjande infrastrukturen.

Kommentar

Windows-containrar använder ytterligare en IP-adress per app för varje App Service-planinstans och du måste ändra storlek på undernätet i enlighet med detta. Om din App Service-miljön till exempel har 2 Windows Container App Service-planer var och en med 25 instanser och var och en med 5 appar som körs, behöver du 300 IP-adresser och ytterligare adresser för horisontell skalning (in/ut).

Exempelberäkning:

För varje App Service-planinstans behöver du: 5 Windows Container-appar = 5 IP-adresser 1 IP-adress per App Service-planinstans 5 + 1 = 6 IP-adresser

För 25 instanser: 6 x 25 = 150 IP-adresser per App Service-plan

Eftersom du har 2 App Service-planer, 2 x 150 = 300 IP-adresser.

Adresser

App Service-miljön har följande nätverksinformation när du skapar:

Adresstyp	beskrivning
App Service-miljön virtuellt nätverk	Det virtuella nätverket som distribueras till.
App Service-miljön undernät	Det undernät som distribueras till.
Domänsuffix	Standarddomänsuffixet som används av apparna.
Suffix för anpassad domän	(valfritt) Det anpassade domänsuffixet som används av apparna.
Virtuell IP-adress (VIP)	Den VIP-typ som används. De två möjliga värdena är interna och externa.
Inkommande adress	Den inkommande adressen är adressen där dina appar nås. Om du har en intern VIP är det en adress i ditt App Service-miljön undernät. Om adressen är extern är det en offentlig adress.
Utgående adresser för arbetare	Apparna använder den här eller de här adresserna när de gör utgående anrop till Internet.
Utgående adresser för plattform	Plattformen använder den här adressen när du gör utgående anrop till Internet. Ett exempel är att hämta certifikat för anpassat domänsuffix från Key Vault om en privat slutpunkt inte används.

Du hittar information i IP-adressdelen i portalen, enligt följande skärmbild:

När du skalar dina App Service-planer i din App Service-miljön använder du fler adresser från undernätet. Antalet adresser som du använder varierar beroende på hur många App Service-planinstanser du har och hur mycket trafik det finns. Appar i App Service-miljön har inte dedikerade adresser i undernätet. De specifika adresser som används av en app i undernätet ändras med tiden.

Ta med din egen inkommande adress

Du kan ta med din egen inkommande adress till din App Service-miljön. Om du skapar en App Service-miljön med en intern VIP kan du ange en statisk IP-adress i undernätet. Om du skapar en App Service-miljön med en extern VIP kan du använda din egen offentliga IP-adress i Azure genom att ange resurs-ID för den offentliga IP-adressen. Följande är begränsningar för att ta med din egen inkommande adress:

• För App Service-miljön med extern VIP måste azures offentliga IP-adressresurs finnas i samma prenumeration som App Service-miljön.
• Den inkommande adressen kan inte ändras när App Service-miljön har skapats.

Portar och nätverksbegränsningar

Se till att regler för inkommande nätverkssäkerhetsgrupp (NSG) tillåter att App Service-miljön undernät tar emot trafik från de portar som krävs för att appen ska kunna ta emot trafik. Förutom alla portar som du vill ta emot trafik på bör du se till att Azure Load Balancer kan ansluta till undernätet på port 80. Den här porten används för hälsokontroller av den interna virtuella datorn. Du kan fortfarande styra port 80-trafik från det virtuella nätverket till ditt undernät.

Kommentar

Det kan ta upp till 14 dagar innan ändringar i NSG-reglerna börjar gälla på grund av HTTP-anslutningsbeständighet. Om du gör en ändring som blockerar plattforms-/hanteringstrafik kan det ta upp till 14 dagar innan effekten visas.

Det är en bra idé att konfigurera följande inkommande NSG-regel:

Käll-/målportar	Riktning	Källa	Mål	Syfte
* / 80,443	Inkommande	VirtualNetwork	App Service-miljön undernätsintervall	Tillåt apptrafik och intern hälso-ping-trafik

Det minsta kravet på att App Service-miljön ska vara i drift är:

Käll-/målportar	Riktning	Källa	Mål	Syfte
* / 80	Inkommande	AzureLoadBalancer	App Service-miljön undernätsintervall	Tillåt intern hälso-ping-trafik

Om du använder den minsta regel som krävs kan du behöva en eller flera regler för din programtrafik. Om du använder något av distributions- eller felsökningsalternativen måste du även tillåta den här trafiken till App Service-miljön undernät. Källan till dessa regler kan vara det virtuella nätverket, eller en eller flera specifika klient-IP-adresser eller IP-intervall. Målet är alltid det App Service-miljön undernätsintervallet.

Den interna hälso-ping-trafiken på port 80 är isolerad mellan lastbalanseraren och de interna servrarna. Ingen extern trafik kan nå slutpunkten för hälsot ping.

De normala inkommande appåtkomstportarna är följande:

Använd	Hamnar
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Fjärrfelsökning i Visual Studio	4022, 4024, 4026
Webbdistributionstjänst	8172

Kommentar

För FTP-åtkomst, även om du vill tillåta standard-FTP på port 21, måste du fortfarande tillåta trafik från LoadBalancer till App Service-miljön undernätsintervall på port 21, eftersom detta används för intern hälso ping trafik för ftp-tjänsten specifikt.

Nätverksroutning

Du kan ange routningstabeller utan begränsning. Du kan skicka all utgående programtrafik från din App Service-miljön till en utgående brandväggsenhet, till exempel Azure Firewall. I det här scenariot är det enda du behöver oroa dig för dina programberoenden.

Programberoenden omfattar slutpunkter som din app behöver under körningen. Förutom API:er och tjänster som appen anropar kan beroenden också härledas till slutpunkter som crl-kontrollslutpunkter och identitets-/autentiseringsslutpunkter, till exempel Microsoft Entra-ID. Om du använder kontinuerlig distribution i App Service kan du också behöva tillåta slutpunkter beroende på typ och språk. Specifikt för kontinuerlig Linux-distribution måste du tillåta oryx-cdn.microsoft.io:443.

Du kan placera dina brandväggsenheter för webbprogram, till exempel Azure Application Gateway, framför inkommande trafik. På så sätt kan du exponera specifika appar på den App Service-miljön.

Ditt program använder en av standardadresserna för utgående trafik till offentliga slutpunkter. Om du vill anpassa utgående adress för dina program på en App Service-miljön kan du lägga till en NAT-gateway i undernätet.

Kommentar

Utgående SMTP-anslutning (port 25) stöds för App Service-miljön v3. Supporten bestäms av en inställning för prenumerationen där det virtuella nätverket distribueras. För virtuella nätverk/undernät som skapats före 1. Augusti 2022 måste du initiera en tillfällig konfigurationsändring av det virtuella nätverket/undernätet för att inställningen ska synkroniseras från prenumerationen. Ett exempel kan vara att lägga till ett tillfälligt undernät, associera/koppla bort en NSG tillfälligt eller tillfälligt konfigurera en tjänstslutpunkt. Mer information och felsökning finns i Felsöka utgående SMTP-anslutningsproblem i Azure.

Privat slutpunkt

För att aktivera privata slutpunkter för appar som finns i din App Service-miljön måste du först aktivera den här funktionen på App Service-miljön nivå.

Du kan aktivera den via Azure Portal. I konfigurationsfönstret App Service-miljön aktiverar du inställningen Allow new private endpoints. Alternativt kan följande CLI aktivera det:

az appservice ase update --name myasename --allow-new-private-endpoint-connections true

Mer information om privat slutpunkt och webbapp finns i Privat slutpunkt för Azure Web App

DNS

I följande avsnitt beskrivs DE DNS-överväganden och konfigurationer som gäller inkommande och utgående från din App Service-miljön. I exemplen används domänsuffixet appserviceenvironment.net från Azure Public Cloud. Om du använder andra moln som Azure Government måste du använda deras respektive domänsuffix. För App Service-miljön domäner trunkeras platsnamnet med 40 tecken på grund av DNS-gränser. Om du har ett fack trunkeras facknamnet med 19 tecken.

DNS-konfiguration till din App Service-miljön

Om din App Service-miljön görs med en extern VIP placeras dina appar automatiskt i offentlig DNS. Om din App Service-miljön görs med en intern VIP har du två alternativ när du skapar din App Service-miljön. Om du väljer att konfigurera privata Azure DNS-zoner automatiskt konfigureras DNS i ditt virtuella nätverk. Om du väljer att konfigurera DNS manuellt måste du antingen använda din egen DNS-server eller konfigurera privata Azure DNS-zoner. Om du vill hitta den inkommande adressen går du till App Service-miljön-portalen och väljer IP-adresser.

Om du vill använda din egen DNS-server lägger du till följande poster:

1. Skapa en zon för <App Service Environment-name>.appserviceenvironment.net.
2. Skapa en A-post i den zonen som pekar * på den inkommande IP-adress som används av din App Service-miljön.
3. Skapa en A-post i den zonen som pekar @ på den inkommande IP-adress som används av din App Service-miljön.
4. Skapa en zon i <App Service Environment-name>.appserviceenvironment.net med namnet scm.
5. Skapa en A-post i scm zonen som pekar * på DEN IP-adress som används av den privata slutpunkten för din App Service-miljön.

Så här konfigurerar du DNS i privata Azure DNS-zoner:

1. Skapa en privat Azure DNS-zon med namnet <App Service Environment-name>.appserviceenvironment.net.
2. Skapa en A-post i den zonen som pekar * på den inkommande IP-adressen.
3. Skapa en A-post i den zonen som pekar @ på den inkommande IP-adressen.
4. Skapa en A-post i den zonen som pekar *.scm till den inkommande IP-adressen.

Förutom standarddomänen som tillhandahålls när en app skapas kan du även lägga till en anpassad domän i din app. Du kan ange ett anpassat domännamn utan validering av dina appar. Om du använder anpassade domäner måste du se till att de har DNS-poster konfigurerade. Du kan följa föregående vägledning för att konfigurera DNS-zoner och poster för ett anpassat domännamn (ersätt standarddomännamnet med det anpassade domännamnet). Det anpassade domännamnet fungerar för appbegäranden, men fungerar inte för webbplatsen scm . Webbplatsen scm är endast tillgänglig på <appname.scm>.<asename.appserviceenvironment.net>.

DNS-konfiguration för FTP-åtkomst

För FTP-åtkomst till intern lastbalanserare (ILB) App Service-miljön v3 specifikt måste du se till att DNS har konfigurerats. Konfigurera en privat Azure DNS-zon eller motsvarande anpassad DNS med följande inställningar:

1. Skapa en privat Azure DNS-zon med namnet ftp.appserviceenvironment.net.
2. Skapa en A-post i den zonen som pekar <App Service Environment-name> på den inkommande IP-adressen.

Förutom att konfigurera DNS måste du även aktivera det i App Service-miljön-konfigurationen och på appnivå.

DNS-konfiguration från din App Service-miljön

Apparna i din App Service-miljön använda den DNS som ditt virtuella nätverk har konfigurerats med. Om du vill att vissa appar ska använda en annan DNS-server kan du ange den manuellt per app, med appinställningarna WEBSITE_DNS_SERVER och WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER konfigurerar den sekundära DNS-servern. Den sekundära DNS-servern används bara när det inte finns något svar från den primära DNS-servern.

Fler resurser

• Referens för miljövariabler och appinställningar