Overzicht van de netwerkarchitectuur van App Service-omgevingen
Belangrijk
Dit artikel gaat over App Service Environment v1. App Service Environment v1 en v2 worden vanaf 31 augustus 2024 buiten gebruik gesteld. Er is een nieuwe versie van App Service Environment die eenvoudiger te gebruiken is en wordt uitgevoerd op een krachtigere infrastructuur. Voor meer informatie over de nieuwe versie begint u met de inleiding tot de App Service-omgeving. Als u momenteel App Service Environment v1 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.
Vanaf 31 augustus 2024 zijn Service Level Agreement (SLA) en servicetegoeden niet langer van toepassing op App Service Environment v1- en v2-workloads die in productie blijven omdat ze buiten gebruik worden gesteld. Het buiten gebruik stellen van de App Service Environment v1- en v2-hardware is gestart. Dit kan van invloed zijn op de beschikbaarheid en prestaties van uw apps en gegevens.
U moet de migratie naar App Service Environment v3 onmiddellijk voltooien of uw apps en resources kunnen worden verwijderd. We proberen alle resterende App Service Environment v1 en v2 automatisch te migreren met behulp van de in-place migratiefunctie, maar Microsoft maakt geen claim of garanties over de beschikbaarheid van toepassingen na automatische migratie. Mogelijk moet u handmatige configuratie uitvoeren om de migratie te voltooien en de SKU-keuze van uw App Service-plan te optimaliseren om aan uw behoeften te voldoen. Als automatische migratie niet haalbaar is, worden uw resources en bijbehorende app-gegevens verwijderd. We dringen er ten zeerste op aan dat u nu actie moet ondernemen om een van deze extreme scenario's te voorkomen.
Als u extra tijd nodig hebt, kunnen we een eenmalige respijtperiode van 30 dagen aanbieden om uw migratie te voltooien. Raadpleeg het overzicht van de respijtperiode voor meer informatie en om deze respijtperiode aan te vragen. Ga vervolgens naar Azure Portal en ga naar de blade Migratie voor elk van uw App Service-omgevingen.
Zie de buitengebruikstelling van App Service Environment v1/v2 voor de meest recente informatie over de buitengebruikstelling van App Service Environment v1 en v2.
App Service-omgevingen worden altijd gemaakt in een subnet van een virtueel netwerk . Apps die worden uitgevoerd in een App Service-omgeving kunnen communiceren met privé-eindpunten binnen dezelfde topologie van het virtuele netwerk. Omdat klanten onderdelen van hun virtuele netwerkinfrastructuur kunnen vergrendelen, is het belangrijk om inzicht te hebben in de typen netwerkcommunicatiestromen die zich voordoen met een App Service-omgeving.
Algemene netwerkstroom
Wanneer een App Service Environment (ASE) een openbaar VIRTUEEL IP-adres (VIP) gebruikt voor apps, komt al het binnenkomende verkeer binnen op dat openbare VIP. Dit verkeer omvat HTTP- en HTTPS-verkeer voor apps en ander verkeer voor FTP, functionaliteit voor externe foutopsporing en Azure-beheerbewerkingen. Zie het artikel over het beheren van inkomend verkeer naar een App Service-omgeving voor een volledige lijst met specifieke poorten (zowel vereist als optioneel) die beschikbaar zijn op het openbare VIP.
App Service Environments biedt ook ondersteuning voor het uitvoeren van apps die alleen zijn gebonden aan een intern adres van een virtueel netwerk, ook wel een ILB-adres (interne load balancer) genoemd. Op een MET ILB ingeschakeld ASE-, HTTP- en HTTPS-verkeer voor apps en externe foutopsporingsaanroepen, arriveert u op het ILB-adres. Voor de meest voorkomende ILB-ASE-configuraties komt FTP-/FTPS-verkeer ook binnen op het ILB-adres. Azure-beheerbewerkingenstroom naar poorten 454/455 op het openbare VIP van een as-omgeving met ILB-functionaliteit.
In het volgende diagram ziet u een overzicht van de verschillende binnenkomende en uitgaande netwerkstromen voor een App Service-omgeving waarin de apps zijn gebonden aan een openbaar virtueel IP-adres:
Een App Service-omgeving kan communiceren met privé-klanteindpunten. Apps die in de App Service Environment worden uitgevoerd, kunnen bijvoorbeeld verbinding maken met databaseservers die worden uitgevoerd op virtuele IaaS-machines in dezelfde topologie van het virtuele netwerk.
Belangrijk
Als u het netwerkdiagram bekijkt, worden de 'Andere rekenresources' geïmplementeerd in een ander subnet dan de App Service Environment. Als u resources in hetzelfde subnet implementeert met de ASE, wordt de connectiviteit van ASE naar deze resources geblokkeerd (met uitzondering van specifieke intra-ASE-routering). Implementeer in plaats daarvan naar een ander subnet (in hetzelfde VNET). De App Service-omgeving kan vervolgens verbinding maken. Er is geen aanvullende configuratie nodig.
App Service-omgevingen communiceren ook met Sql DB- en Azure Storage-resources die nodig zijn voor het beheren en uitvoeren van een App Service-omgeving. Sommige sql- en opslagbronnen waarmee een App Service-omgeving communiceert, bevinden zich in dezelfde regio als de App Service Environment, terwijl andere zich in externe Azure-regio's bevinden. Als gevolg hiervan is uitgaande verbinding met internet altijd vereist om een App Service-omgeving goed te laten functioneren.
Omdat een App Service-omgeving wordt geïmplementeerd in een subnet, kunnen netwerkbeveiligingsgroepen worden gebruikt om inkomend verkeer naar het subnet te beheren. Zie het volgende artikel voor meer informatie over het beheren van inkomend verkeer naar een App Service-omgeving.
Zie het volgende artikel over het werken met Express Route voor meer informatie over het toestaan van uitgaande internetverbinding vanuit een App Service Environment. Dezelfde benadering die in het artikel wordt beschreven, geldt voor het werken met site-naar-site-connectiviteit en het gebruik van geforceerde tunneling.
Uitgaande netwerkadressen
Wanneer een App Service Environment uitgaande aanroepen doet, wordt er altijd een IP-adres gekoppeld aan de uitgaande aanroepen. Het specifieke IP-adres is afhankelijk van of het eindpunt dat wordt aangeroepen zich binnen de topologie van het virtuele netwerk bevindt of buiten de topologie van het virtuele netwerk.
Als het eindpunt dat wordt aangeroepen zich buiten de topologie van het virtuele netwerk bevindt, is het uitgaande adres (ook wel het uitgaande NAT-adres genoemd) het openbare VIP van de App Service-omgeving. Dit adres vindt u in de gebruikersinterface van de portal voor de App Service-omgeving in de sectie Eigenschappen.
Dit adres kan ook worden bepaald voor AS's die alleen een openbaar VIP hebben door een app te maken in de App Service Environment en vervolgens een nslookup uit te voeren op het adres van de app. Het resulterende IP-adres is zowel het openbare VIP als het uitgaande NAT-adres van de App Service Environment.
Als het eindpunt dat wordt aangeroepen zich binnen de topologie van het virtuele netwerk bevindt, is het uitgaande adres van de aanroepende app het interne IP-adres van de afzonderlijke rekenresource waarop de app wordt uitgevoerd. Er is echter geen permanente toewijzing van interne IP-adressen van virtuele netwerken aan apps. Apps kunnen navigeren over verschillende rekenresources en de groep beschikbare rekenresources in een App Service-omgeving kan veranderen vanwege schaalbewerkingen.
Omdat een App Service-omgeving zich echter altijd in een subnet bevindt, weet u zeker dat het interne IP-adres van een rekenresource waarop een app wordt uitgevoerd, altijd binnen het CIDR-bereik van het subnet valt. Als er fijnmazige ACL's of netwerkbeveiligingsgroepen worden gebruikt om toegang tot andere eindpunten binnen het virtuele netwerk te beveiligen, moet het subnetbereik met de App Service-omgeving toegang krijgen.
In het volgende diagram ziet u de volgende concepten in meer detail:
In het bovenstaande diagram:
- Omdat het openbare VIP van de App Service Environment 192.23.1.2 is, is dat het uitgaande IP-adres dat wordt gebruikt bij het aanroepen naar interneteindpunten.
- Het CIDR-bereik van het subnet voor de App Service Environment is 10.0.1.0/26. Andere eindpunten binnen dezelfde infrastructuur voor virtuele netwerken zien aanroepen van apps die afkomstig zijn van ergens binnen dit adresbereik.
Aanroepen tussen App Service-omgevingen
Een complexer scenario kan optreden als u meerdere App Service-omgevingen in hetzelfde virtuele netwerk implementeert en uitgaande aanroepen vanuit de ene App Service-omgeving naar een andere App Service-omgeving uitvoert. Deze typen cross App Service Environment-aanroepen worden ook behandeld als 'internet'-aanroepen.
In het volgende diagram ziet u een voorbeeld van een gelaagde architectuur met apps in één App Service Environment (bijvoorbeeld 'Front door'-web-apps) die apps aanroepen in een tweede App Service-omgeving (bijvoorbeeld interne back-end-API-apps die niet zijn bedoeld om toegankelijk te zijn vanaf internet).
In het bovenstaande voorbeeld heeft de App Service Environment 'ASE One' een uitgaand IP-adres van 192.23.1.2. Als een app die wordt uitgevoerd in deze App Service-omgeving een uitgaande aanroep uitvoert naar een app die wordt uitgevoerd in een tweede App Service Environment ('ASE Two') die zich in hetzelfde virtuele netwerk bevindt, wordt de uitgaande aanroep behandeld als een internetaanroep. Als gevolg hiervan wordt het netwerkverkeer dat binnenkomt in de tweede App Service-omgeving weergegeven als afkomstig van 192.23.1.2 (dat wil gezegd, niet het adresbereik van het subnet van de eerste App Service-omgeving).
Hoewel aanroepen tussen verschillende App Service-omgevingen worden behandeld als 'internet'-aanroepen, blijven beide App Service-omgevingen zich in dezelfde Azure-regio bevinden, het netwerkverkeer op het regionale Azure-netwerk en loopt het niet fysiek via het openbare internet. Als gevolg hiervan kunt u een netwerkbeveiligingsgroep in het subnet van de tweede App Service-omgeving gebruiken om alleen binnenkomende aanroepen van de eerste App Service-omgeving toe te staan (waarvan het uitgaande IP-adres 192.23.1.2 is), waardoor veilige communicatie tussen de App Service-omgevingen wordt gegarandeerd.
Aanvullende koppelingen en informatie
Meer informatie over binnenkomende poorten die worden gebruikt door App Service Environments en het gebruik van netwerkbeveiligingsgroepen om inkomend verkeer te beheren, is hier beschikbaar.
Meer informatie over het gebruik van door de gebruiker gedefinieerde routes om uitgaande internettoegang tot App Service Environments te verlenen, is beschikbaar in dit artikel.