App Service Environment-netwerken

App Service Environment is een implementatie met één tenant van Azure-app Service die als host fungeert voor Windows- en Linux-containers, web-apps, API-apps, logische apps en functie-apps. Wanneer u een App Service Environment installeert, kiest u het virtuele Azure-netwerk waarin u het wilt implementeren. Al het binnenkomende en uitgaande toepassingsverkeer bevindt zich in het virtuele netwerk dat u opgeeft. U implementeert in één subnet in uw virtuele netwerk en niets anders kan in dat subnet worden geïmplementeerd.

Subnetvereisten

Hieronder vindt u de minimale set vereisten voor het subnet waarin uw App Service-omgeving zich bevindt.

• Het subnet moet worden gedelegeerd aan Microsoft.Web/hostingEnvironments.
• Het subnet moet leeg zijn.
• De addressPrefix eigenschap van het subnet moet een string zijn, niet een matrix.

De grootte van het subnet kan van invloed zijn op de schaalbaarheidslimieten van de instanties van het App Service-plan binnen de App Service-omgeving. Voor productieschaal raden we een /24 adresruimte (256 adressen) aan voor uw subnet. Als u van plan bent om te schalen naar de maximale capaciteit van 200 instanties in onze App Service Environment en u regelmatig omhoog/omlaag schaaloperaties plant, raden we een /23 adresruimte (512 adressen) aan voor uw subnet.

Als u een kleiner subnet gebruikt, moet u rekening houden met de volgende beperkingen:

• Elk bepaald subnet heeft vijf adressen die zijn gereserveerd voor beheerdoeleinden. Naast de beheeradressen wordt de ondersteunende infrastructuur dynamisch geschaald in App Service Environment en wordt gebruikgemaakt van 7 tot 27 adressen, afhankelijk van de configuratie en belasting. U gebruikt de resterende adressen voor instances in het App Service-plan. De minimale grootte van uw subnet is een /27 adresruimte (32 adressen).
• Voor elke App Service-plan OS/SKU-combinatie die wordt gebruikt in uw App Service Environment, zoals I1v2 Windows, wordt er één stand-by-exemplaar gemaakt voor elke 20 actieve exemplaren. Voor de stand-by-exemplaren zijn ook IP-adressen vereist.
• Wanneer u App Service-plannen in de App Service-omgeving omhoog/omlaag schaalt, wordt de hoeveelheid IP-adressen die door het App Service-plan worden gebruikt, tijdelijk verdubbeld terwijl de schaalbewerking is voltooid. De nieuwe exemplaren moeten volledig operationeel zijn voordat de bestaande exemplaren worden uitgefaseerd.
• Platformupgrades hebben gratis IP-adressen nodig om ervoor te zorgen dat upgrades kunnen plaatsvinden zonder onderbrekingen van uitgaand verkeer.
• Nadat schalen omhoog, omlaag, of intern is voltooid, kan het even duren voordat IP-adressen worden vrijgegeven. In zeldzame gevallen kan deze bewerking maximaal 12 uur duren.
• Als u geen adressen meer hebt binnen uw subnet, kunt u uw App Service-plannen niet uitschalen in de App Service-omgeving. Een andere mogelijkheid is dat u een verhoogde latentie kunt ervaren tijdens de intensieve belasting van het verkeer, als Microsoft de ondersteunende infrastructuur niet kan schalen.

Adressen

App Service Environment bevat de volgende netwerkgegevens bij het maken:

U vindt details in het gedeelte IP-adressen van de portal, zoals wordt weergegeven in de volgende schermopname:

Wanneer u uw App Service-plannen in uw App Service-omgeving schaalt, gebruikt u meer adressen buiten uw subnet. Het aantal adressen dat u gebruikt varieert, afhankelijk van het aantal exemplaren van het app-serviceplan dat u hebt en de hoeveelheid verkeer. Apps in de App Service Environment hebben geen toegewezen adressen in het subnet. De specifieke adressen die door een app in het subnet worden gebruikt, worden na verloop van tijd gewijzigd.

Gebruik uw eigen ontvangstadres

U kunt uw eigen binnenkomende adres meenemen naar uw App Service Environment. Als u een App Service-omgeving met een intern VIP maakt, kunt u een statisch IP-adres opgeven in het subnet. Als u een App Service-omgeving met een extern VIP maakt, kunt u uw eigen openbare IP-adres van Azure gebruiken door de resource-id van het openbare IP-adres op te geven. Hier volgen beperkingen voor het meenemen van uw eigen binnenkomende adres:

• Voor App Service Environment met extern VIP moet de openbare IP-adresresource van Azure zich in hetzelfde abonnement bevinden als de App Service Environment.
• Het binnenkomende adres kan niet worden gewijzigd nadat de App Service Environment is gemaakt.

Beperking van inkomend verkeer in ILB App Service Environment

Voor App Service-omgevingen met een intern VIP kan binnenkomend verkeer naar de front-ends worden verwijderd als het bron-IP-adres binnen het infrastructuuradresbereik valt dat wordt gebruikt voor de front-ends van de App Service Environment. Gebruik geen bron-IP-adressen in de 172.31.192.0/25 adresruimte wanneer u verbinding maakt met een ILB App Service Environment.

Poorten en netwerkbeperkingen

Zorg ervoor dat de regels voor binnenkomende netwerkbeveiligingsgroepen (NSG) toestaan dat het App Service Environment-subnet verkeer van de vereiste poorten ontvangt, zodat uw App verkeer kan ontvangen. Naast alle poorten waarop u verkeer wilt ontvangen, moet u ervoor zorgen dat Azure Load Balancer verbinding kan maken met het subnet op poort 80. Deze poort wordt gebruikt voor statuscontroles van de interne virtuele machine. U kunt nog steeds poort 80-verkeer van het virtuele netwerk naar uw subnet beheren.

Het is een goed idee om de volgende binnenkomende NSG-regel te configureren:

De minimale vereiste dat App Service Environment operationeel moet zijn, is:

Als u de minimaal vereiste regel gebruikt, hebt u mogelijk een of meer regels nodig voor uw toepassingsverkeer. Als u een van de implementatie- of foutopsporingsopties gebruikt, moet u dit verkeer ook toestaan naar het subnet van de App Service Environment. De bron van deze regels kan het virtuele netwerk zijn, of een of meer specifieke IP-adressen van clients of IP-bereiken. Het doel is altijd het subnetbereik van de App Service Environment.

Het interne status pingverkeer op poort 80 wordt geïsoleerd tussen de load balancer en de interne servers. Er kan geen extern verkeer het eindpunt voor status ping bereiken.

De normale inkomende toegangsporten voor apps zijn als volgt:

Netwerkroutering

U kunt zonder beperkingen routetabellen instellen. U kunt al het uitgaande toepassingsverkeer van uw App Service-omgeving tunnelen naar een uitgaand firewallapparaat, zoals Azure Firewall. In dit scenario hoeft u zich alleen maar zorgen te maken over de afhankelijkheden van uw toepassing.

Toepassingsafhankelijkheden bevatten eindpunten die uw app tijdens runtime nodig heeft. Naast de API's en services die de app aanroept, kunnen afhankelijkheden ook afgeleide eindpunten zijn, zoals certificaatintrekkingslijst (CRL) controle-eindpunten en eindpunten voor identiteits-/authenticatiecontrole, bijvoorbeeld Microsoft Entra ID. Als u continue implementatie in App Service gebruikt, moet u mogelijk ook eindpunten toestaan, afhankelijk van het type en de taal. Specifiek voor Linux continue implementatie moet u toestaan oryx-cdn.microsoft.io:443.

U kunt uw web application firewall-apparaten, zoals Azure Application Gateway, voor het inkomende verkeer plaatsen. Hierdoor kunt u specifieke apps beschikbaar maken in die App Service-omgeving.

Uw toepassing gebruikt een van de standaard uitgaande adressen voor uitgaand verkeer naar openbare eindpunten. Als u het uitgaande adres van uw toepassingen in een App Service Environment wilt aanpassen, kunt u een NAT-gateway toevoegen aan uw subnet.

Privé-eindpunt

Als u privé-eindpunten wilt inschakelen voor apps die worden gehost in uw App Service Environment, moet u deze functie eerst inschakelen op het niveau van de App Service-omgeving.

U kunt deze activeren via Azure Portal. Schakel . Als alternatief kan de volgende CLI deze inschakelen:

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

Zie Het privé-eindpunt van Azure Web App voor meer informatie over privé-eindpunten en web-apps

DNS

In de volgende secties worden de DNS-overwegingen en -configuratie voor inkomend en uitgaand verkeer van en naar uw App Service-omgeving beschreven. In de voorbeelden wordt het domeinachtervoegsel appserviceenvironment.net uit de openbare Azure-cloud gebruikt. Als u andere clouds zoals Azure Government gebruikt, moet u het respectieve domeinachtervoegsel gebruiken. Voor App Service Environment-domeinen wordt de sitenaam afgekapt met 59 tekens vanwege DNS-limieten. Voor App Service Environment-domeinen met slots wordt de sitenaam afgekapt na 40 tekens en de slotnaam na 19 tekens vanwege DNS-limieten.

DNS-configuratie voor uw App Service-omgeving

Als uw App Service-omgeving wordt gemaakt met een extern VIP, worden uw apps automatisch in openbare DNS geplaatst. Als uw App Service Environment is gemaakt met een intern VIP, hebt u twee opties wanneer u uw App Service Environment maakt. Als u selecteert dat azure DNS-privézones automatisch zijn geconfigureerd, wordt DNS geconfigureerd in uw virtuele netwerk. Als u ervoor kiest om DNS handmatig te configureren, moet u uw eigen DNS-server gebruiken of privézones van Azure DNS configureren. Als u het binnenkomende adres wilt vinden, gaat u naar de App Service Environment-portal en selecteert u IP-adressen.

Als u uw eigen DNS-server wilt gebruiken, voegt u de volgende records toe:

1. Maak een zone voor <App Service Environment-name>.appserviceenvironment.net.
2. Maak een A-record in die zone die * verwijst naar het binnenkomende IP-adres dat wordt gebruikt door uw App Service Environment.
3. Maak een A-record in die zone die verwijst naar het binnenkomende IP-adres dat wordt gebruikt door uw App Service Environment.
4. Maak een zone in <App Service Environment-name>.appserviceenvironment.net genaamd scm.
5. Maak een A-record in de scm zone die * verwijst naar het IP-adres dat wordt gebruikt door het privé-eindpunt van uw App Service-omgeving.

DNS configureren in privézones van Azure DNS:

1. Maak een Azure DNS-privézone met de naam <App Service Environment-name>.appserviceenvironment.net.
2. Maak een A-record in die zone die * verwijst naar het binnenkomende IP-adres.
3. Maak een A-record in die zone die @ verwijst naar het binnenkomende IP-adres.
4. Maak in die zone een A-record aan dat *.scm naar het binnenkomende IP-adres verwijst.

Naast het standaarddomein dat wordt opgegeven wanneer een app wordt gemaakt, kunt u ook een aangepast domein toevoegen aan uw app. U kunt een aangepaste domeinnaam instellen zonder validatie voor uw apps. Als u aangepaste domeinen gebruikt, moet u ervoor zorgen dat dns-records zijn geconfigureerd. U kunt de voorgaande richtlijnen volgen voor het configureren van DNS-zones en -records voor een aangepaste domeinnaam (vervang de standaarddomeinnaam door de aangepaste domeinnaam). De aangepaste domeinnaam werkt voor app-aanvragen, maar werkt niet voor de scm site. De scm site is alleen beschikbaar op <appname.scm>.<asename.appserviceenvironment.net>.

DNS-configuratie voor FTP-toegang

Voor FTP-toegang tot ILB (Internal Load Balancer) App Service Environment v3 moet u ervoor zorgen dat DNS is geconfigureerd. Configureer een privézone van Azure DNS of gelijkwaardige aangepaste DNS met de volgende instellingen:

1. Maak een Azure DNS-privézone met de naam ftp.appserviceenvironment.net.
2. Maak een A-record in die zone die verwijst <App Service Environment-name> naar het binnenkomende IP-adres.

Naast het instellen van DNS moet u deze ook inschakelen in de App Service Environment-configuratie en op app-niveau.

DNS-configuratie vanuit uw App Service-omgeving

De apps in uw App Service Environment gebruiken de DNS waarmee uw virtuele netwerk is geconfigureerd. Als u wilt dat sommige apps een andere DNS-server gebruiken, kunt u deze handmatig instellen per app, met de app-instellingen WEBSITE_DNS_SERVER en WEBSITE_DNS_ALT_SERVER. WEBSITE_DNS_ALT_SERVER hiermee configureert u de secundaire DNS-server. De secundaire DNS-server wordt alleen gebruikt wanneer er geen reactie van de primaire DNS-server is.

Meer middelen

• Naslaginformatie over omgevingsvariabelen en app-instellingen