App Service-miljön hanteringsadresser
Viktigt!
Den här artikeln handlar om App Service-miljön v2, som används med isolerade App Service-planer. App Service-miljön v1 och v2 dras tillbaka från och med den 31 augusti 2024. Det finns en ny version av App Service-miljön som är enklare att använda och köra på kraftfullare infrastruktur. Om du vill veta mer om den nya versionen börjar du med Introduktion till App Service-miljön. Om du för närvarande använder App Service-miljön v1 följer du stegen i den här artikeln för att migrera till den nya versionen.
Från och med den 31 augusti 2024 gäller serviceavtal (SLA) och tjänstkrediter inte längre för App Service-miljön v1- och v2-arbetsbelastningar som fortsätter att vara i produktion eftersom de är tillbakadragna produkter. Avvecklingen av maskinvaran App Service-miljön v1 och v2 har påbörjats, vilket kan påverka tillgängligheten och prestandan för dina appar och data.
Du måste slutföra migreringen till App Service-miljön v3 omedelbart eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera eventuella återstående App Service-miljön v1 och v2 på bästa sätt med hjälp av migreringsfunktionen på plats, men Microsoft gör inga anspråk eller garantier om programtillgänglighet efter automatisk migrering. Du kan behöva utföra manuell konfiguration för att slutföra migreringen och optimera ditt SKU-val för App Service-plan för att uppfylla dina behov. Om automatisk migrering inte är möjlig tas dina resurser och associerade appdata bort. Vi uppmanar dig starkt att agera nu för att undvika något av dessa extrema scenarier.
Om du behöver ytterligare tid kan vi erbjuda en respitperiod på 30 dagar för att slutföra migreringen. Mer information och för att begära den här respitperioden finns i översikten över respitperioden och gå sedan till Azure Portal och gå till migreringsbladet för var och en av dina App Service-miljön.
Den senaste informationen om App Service-miljön v1/v2-tillbakadragning finns i App Service-miljön v1- och v2-pensionsuppdateringen.
Förutsättningar
Använd Bash-miljön i Azure Cloud Shell. Mer information finns i Snabbstart för Bash i Azure Cloud Shell.
Om du föredrar att köra CLI-referenskommandon lokalt installerar du Azure CLI. Om du kör i Windows eller macOS kan du köra Azure CLI i en Docker-container. Mer information finns i Så här kör du Azure CLI i en Docker-container.
Om du använder en lokal installation loggar du in på Azure CLI med hjälp av kommandot az login. Slutför autentiseringsprocessen genom att följa stegen som visas i terminalen. Andra inloggningsalternativ finns i Logga in med Azure CLI.
När du uppmanas att installera Azure CLI-tillägget vid första användningen. Mer information om tillägg finns i Använda tillägg med Azure CLI.
Kör az version om du vill hitta versionen och de beroende bibliotek som är installerade. Om du vill uppgradera till den senaste versionen kör du az upgrade.
Sammanfattning
App Service-miljön (ASE) är en enda klientdistribution av Azure App Service som körs i ditt virtuella Azure-nätverk. Även om ASE körs i ditt virtuella nätverk måste den fortfarande vara tillgänglig från ett antal dedikerade IP-adresser som används av Azure App Service för att hantera tjänsten. När det gäller en ASE passerar hanteringstrafiken det användarkontrollerade nätverket. Om den här trafiken blockeras eller felutlöss kommer ASE att pausas. Mer information om ASE-nätverksberoenden finns i Nätverksöverväganden och App Service-miljön. För allmän information om ASE kan du börja med Introduktion till App Service-miljön.
Alla ASE:er har en offentlig VIP som hanteringstrafiken kommer in i. Inkommande hanteringstrafik från dessa adresser kommer in från portarna 454 och 455 på den offentliga VIP:en för din ASE. Det här dokumentet visar apptjänstens källadresser för hanteringstrafik till ASE. Dessa adresser finns också i IP Service-taggen med namnet AppServiceManagement.
Adresserna i tjänsttaggen AppServiceManagement kan konfigureras i en routningstabell för att undvika asymmetriska routningsproblem med hanteringstrafiken. Där det är möjligt bör du använda tjänsttaggen i stället för de enskilda adresserna. Vägar agerar på trafik på IP-nivå och har ingen medvetenhet om trafikriktning eller att trafiken är en del av ett TCP-svarsmeddelande. Om svarsadressen för en TCP-begäran skiljer sig från den adress som den skickades till har du ett asymmetriskt routningsproblem. För att undvika asymmetriska routningsproblem med ASE-hanteringstrafiken måste du se till att svar skickas tillbaka från samma adress som de skickades till. Mer information om hur du konfigurerar din ASE att fungera i en miljö där utgående trafik skickas lokalt finns i Konfigurera din ASE med tvingad tunneltrafik.
Lista över hanteringsadresser
Om du behöver se IP-adresserna för hanteringsadresserna laddar du ned referensen för tjänsttaggen för din region för att få den senaste listan med adresser. De App Service-miljön hanteringsadresserna visas i servicetaggen AppServiceManagement.
Region | Referens för tjänsttagg |
---|---|
Alla offentliga regioner | Azure IP-intervall och servicemärken – offentligt moln |
Microsoft Azure Government | Azure IP-intervall och servicemärken – Amerikanskt myndighetsmoln |
Microsoft Azure drivs av 21Vianet | Azure IP-intervall och servicemärken – Kinesiskt moln |
Konfigurera en nätverkssäkerhetsgrupp
Med Nätverkssäkerhetsgrupper behöver du inte bekymra dig om de enskilda adresserna eller underhålla din egen konfiguration. Det finns en IP-tjänsttagg med namnet AppServiceManagement som hålls uppdaterad med alla adresser. Om du vill använda den här IP-tjänsttaggen i din NSG går du till portalen, öppnar användargränssnittet för nätverkssäkerhetsgrupper och väljer Inkommande säkerhetsregler. Om du har en befintlig regel för inkommande hanteringstrafik redigerar du den. Om den här NSG:n inte har skapats med din ASE eller om allt är nytt väljer du Lägg till. Under listrutan Källa väljer du Tjänsttagg. Under taggen Källtjänst väljer du AppServiceManagement. Ange källportintervallen till *, Mål till Alla, Målportintervall till 454-455, Protokoll till TCP och Åtgärd till Tillåt. Om du skapar regeln måste du ange Prioritet.
Konfigurera en routningstabell
Hanteringsadresserna kan placeras i en routningstabell med nästa hopp av Internet för att säkerställa att all inkommande hanteringstrafik kan gå tillbaka via samma sökväg. Dessa vägar behövs när du konfigurerar tvingad tunneltrafik. När det är möjligt använder du servicetaggen AppServiceManagement i stället för de enskilda adresserna. Om du vill skapa routningstabellen kan du använda portalen, PowerShell eller Azure CLI. Kommandona för att skapa en routningstabell med Hjälp av Azure CLI från en PowerShell-prompt finns nedan.
$sub = "subscription ID"
$rg = "resource group name"
$rt = "route table name"
$location = "azure location"
az network route-table route create --subscription $sub -g $rg --route-table-name $rt -n 'AppServiceManagement' --address-prefix 'AppServiceManagement' --next-hop-type 'Internet'
När routningstabellen har skapats måste du ange den i ASE-undernätet.
Hämta dina hanteringsadresser från API:et
Du kan lista de hanteringsadresser som matchar din ASE med följande API-anrop.
get /subscriptions/<subscription ID>/resourceGroups/<resource group>/providers/Microsoft.Web/hostingEnvironments/<ASE Name>/inboundnetworkdependenciesendpoints?api-version=2016-09-01
API:et returnerar ett JSON-dokument som innehåller alla inkommande adresser för din ASE. Listan med adresser innehåller hanteringsadresserna, DEN VIP som används av din ASE och själva ASE-undernätets adressintervall.
Om du vill anropa API:et med armclienten använder du följande kommandon men ersätter i ditt prenumerations-ID, resursgrupp och ASE-namn.
armclient login
armclient get /subscriptions/<subscription ID>/resourceGroups/<resource group>/providers/Microsoft.Web/hostingEnvironments/<ASE Name>/inboundnetworkdependenciesendpoints?api-version=2016-09-01