Nätverk för App Service-miljö

App Service Environment ä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ö 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 Environment v3, som används med Isolerade v2 App Service-planer.

Krav för undernät

Du måste delegera undernätet till Microsoft.Web/hostingEnvironmentsoch undernätet måste vara tomt.

Storleken på undernätet kan påverka skalningsgränserna för App Service-planinstanserna i 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ö 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. Utöver hanteringsadresserna skalar App Service Environment 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-plan-OS/SKU som används i din App Service-miljö som I1v2 Windows skapas en standby-instans för varje 20 aktiva instanser. Standby-instanserna kräver också IP-adresser.
• När apptjänstplaner skalas upp/ned i App Service-miljön fördubblas tillfälligt mängden IP-adresser som används av App Service-planen 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ö till exempel har 2 Windows Container App Service-planer 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 Environment innehåller följande nätverksinformation när du skapar:

Adresstyp	beskrivning
Virtuellt nätverk för App Service Environment	Det virtuella nätverket som distribueras till.
App Service Environment-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 apptjänstmiljöns 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 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 Environment 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ö. Om du skapar en App Service-miljö med en intern VIP kan du ange en statisk IP-adress i undernätet. Om du skapar en App Service-miljö 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 Environment 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 Environment har skapats.

Portar och nätverksbegränsningar

För att appen ska ta emot trafik kontrollerar du att regler för inkommande nätverkssäkerhetsgrupp (NSG) tillåter att App Service Environment-undernätet tar emot trafik från de portar som krävs. 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	Undernätsintervall för App Service Environment	Tillåt apptrafik och intern hälso-ping-trafik

Det minsta kravet på att App Service Environment ska vara i drift är:

Käll-/målportar	Riktning	Källa	Mål	Syfte
* / 80	Inkommande	AzureLoadBalancer	Undernätsintervall för App Service Environment	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 Environment-undernätet. 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 undernätsintervallet för App Service Environment.

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 Environment-undernätsintervallet 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ö 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 i apptjänstmiljön.

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

Kommentar

Utgående SMTP-anslutning (port 25) stöds för App Service Environment 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 apptjänstmiljön måste du först aktivera den här funktionen på App Service-miljönivå.

Du kan aktivera den via Azure-portalen. I konfigurationsfönstret för App Service Environment 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ö. 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 Environment-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ö

Om din App Service-miljö görs med en extern VIP placeras dina appar automatiskt i offentlig DNS. Om din App Service-miljö skapas med en intern VIP har du två alternativ när du skapar din App Service-miljö. 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 Environment-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ö.
3. Skapa en A-post i den zonen som pekar @ på den inkommande IP-adress som används av Din App Service-miljö.
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 i Din App Service-miljö.

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 App Service Environment v3 för intern lastbalanserare (ILB) 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 Environment-konfigurationen och på appnivå.

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

Apparna i App Service Environment använder 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