Använd migreringsfunktionen sida vid sida för att migrera App Service-miljön v2 till App Service-miljön v3
Kommentar
Migreringsfunktionen som beskrivs i den här artikeln används för automatisk migrering sida vid sida (olika undernät) för App Service-miljön v2 till App Service-miljön v3.
Om du letar efter information om migreringsfunktionen på plats kan du läsa Migrera till App Service-miljön v3 med hjälp av migreringsfunktionen på plats. Information om manuella migreringsalternativ finns i Manuella migreringsalternativ. Mer information om vilket migreringsalternativ som passar dig finns i Beslutsträd för migreringssökväg. Mer information om App Service-miljön v3 finns i översikten över App Service-miljön v3.
Du kan automatiskt migrera App Service-miljön v2 till App Service-miljön v3 med hjälp av migreringsfunktionen sida vid sida. Mer information om migreringsprocessen och om du vill se om din App Service-miljön stöder migrering just nu finns i översikten över migreringsfunktionen sida vid sida.
Viktigt!
Vi rekommenderar att du använder den här funktionen för utvecklingsmiljöer innan du migrerar några produktionsmiljöer för att undvika oväntade problem. Ge feedback om den här artikeln eller funktionen genom att använda knapparna längst ned på sidan.
Förutsättningar
Se till att du förstår hur migrering till App Service-miljön v3 påverkar dina program. Granska migreringsprocessen för att förstå processtidslinjen och var och när du behöver engagera dig. Läs även vanliga frågor och svar, som kan besvara några av dina frågor.
Se till att det inte finns några lås i ditt virtuella nätverk, resursgrupper, resurser eller prenumeration. Låser blockplattformsåtgärder under migreringen.
Se till att inga Azure-principer blockerar åtgärder som krävs för migreringen, inklusive ändringar i undernätet och skapande av Azure App Service-resurser. Principer som blockerar resursändringar och skapanden kan orsaka att migreringen fastnar eller misslyckas.
Eftersom din App Service-miljön v3 finns i ett annat undernät i det virtuella nätverket måste du se till att du har ett tillgängligt undernät i det virtuella nätverket som uppfyller undernätskraven för App Service-miljön v3. Det undernät som du väljer måste också kunna kommunicera med det undernät som din befintliga App Service-miljön finns i. Se till att det inte finns något som blockerar kommunikationen mellan de två undernäten. Om du inte har ett tillgängligt undernät måste du skapa ett innan du migrerar. Att skapa ett nytt undernät kan innebära att du ökar adressutrymmet för det virtuella nätverket. Mer information finns i Skapa ett virtuellt nätverk och undernät.
Eftersom skalning blockeras under migreringen bör du skala din miljö till önskad storlek innan du påbörjar migreringen. Om du behöver skala din miljö efter migreringen kan du göra det när migreringen är klar.
Följ stegen som beskrivs här i ordning och enligt skrivning eftersom du gör Azure REST API-anrop. Vi rekommenderar att du använder Azure CLI för att göra dessa API-anrop. Information om andra metoder finns i Azure REST API-referens.
I den här guiden installerar du Azure CLI eller använder Azure Cloud Shell och använder ett Bash-gränssnitt.
Kommentar
Vi rekommenderar att du använder ett Bash-gränssnitt för att köra kommandona som anges i den här guiden. Kommandona kanske inte är kompatibla med PowerShell-konventioner och escape-tecken.
Viktigt!
Under migreringen kan Azure-portalen visa felaktig information om dina App Service-miljön och dina appar. Gå inte till migreringsupplevelsen i Azure-portalen eftersom migreringsfunktionen sida vid sida inte är tillgänglig där. Vi rekommenderar att du använder Azure CLI för att kontrollera statusen för migreringen. Kontakta supporten om du har frågor om status för migreringen eller dina appar.
1. Välj undernätet för din nya App Service-miljön v3
Välj ett undernät i din App Service-miljön v3 som uppfyller undernätskraven för App Service-miljön v3. Observera namnet på det undernät som du väljer. Det här undernätet måste skilja sig från det undernät som din befintliga App Service-miljön finns i.
2. Hämta ditt App Service-miljön-ID
Kör följande kommandon för att hämta ditt App Service-miljön-ID och lagra det som en miljövariabel. Ersätt platshållarna för namnet och resursgrupperna med dina värden för den App Service-miljön som du vill migrera. ASE_RGoch VNET_RG är samma om ditt virtuella nätverk och App Service-miljön finns i samma resursgrupp.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
3. Verifiera att migrering stöds
Följande kommando kontrollerar om din App Service-miljön stöds för migrering. Om du får ett fel eller om din App Service-miljön är i ett felfritt eller pausat tillstånd kan du inte migrera just nu. I felsökningsavsnittet finns beskrivningar av potentiella felmeddelanden som du kan få. Om din miljö inte stöds för migrering med hjälp av migreringsfunktionen sida vid sida eller om du vill migrera till App Service-miljön v3 utan att använda migreringsfunktionen sida vid sida läser du alternativen för manuell migrering. Det här kommandot verifierar också att din App Service-miljön finns på den version som stöds för migrering. Om din App Service-miljön inte finns på den version som stöds måste du starta uppgraderingen själv. Mer information om uppgraderingen före migreringen finns i Verifiera att migrering stöds med hjälp av migreringsfunktionen sida vid sida för din App Service-miljön.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
Om det inte finns några fel stöds migreringen och du kan fortsätta till nästa steg.
Om du behöver starta en uppgradering för att uppgradera din App Service-miljön till den version som stöds, vilket kan ta 8–12 timmar eller längre beroende på miljöns storlek, kör du följande kommando. Kör bara det här kommandot om du misslyckas med valideringssteget och du uppmanas att uppgradera din App Service-miljön.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Generera utgående IP-adresser för din nya App Service-miljön v3
Skapa en fil med namnet zoneredundancy.json med följande information för redundansval för din region och zon.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
Du kan göra din nya App Service-miljön v3-zon redundant om din befintliga miljö finns i en region som stöder zonredundans. Zonredundans kan konfigureras genom att ställa in egenskapen på zoneRedundant true. Zonredundans är en valfri konfiguration. Den här konfigurationen kan bara ställas in när du skapar din nya App Service-miljön v3 och kan inte tas bort vid ett senare tillfälle.
Kör följande kommando för att skapa nya utgående IP-adresser. Det här steget tar cirka 15 minuter att slutföra. Skala inte eller gör ändringar i din befintliga App Service-miljön under den här tiden.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
Kör följande kommando för att kontrollera statusen för det här steget:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
Om steget pågår får du statusen Migrating. När du har fått statusen Readykör du följande kommando för att visa dina nya utgående IP-adresser. Om du inte ser de nya IP-adresserna omedelbart väntar du några minuter och försöker igen.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5. Uppdatera beroende resurser med nya utgående IP-adresser
Genom att använda de nya utgående IP-adresserna uppdaterar du någon av dina resurser eller nätverkskomponenter för att säkerställa att den nya miljön fungerar som den är avsedd när migreringen är klar. Det är ditt ansvar att göra nödvändiga uppdateringar.
6. Delegera ditt App Service-miljön undernät
App Service-miljön v3 kräver att det undernät som det finns i har en enda delegering av Microsoft.Web/hostingEnvironments. Tidigare versioner krävde inte den här delegeringen. Du måste bekräfta att ditt undernät har delegerats korrekt och uppdatera delegeringen (om det behövs) innan du migrerar. Du kan uppdatera delegeringen antingen genom att köra följande kommando eller genom att gå till undernätet i Azure-portalen.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7. Bekräfta att det inte finns några lås i det virtuella nätverket
Virtuellt nätverk låser blockplattformsåtgärder under migreringen. Om det virtuella nätverket har lås måste du ta bort dem innan du migrerar. Om det behövs kan du lägga till låsen igen när migreringen är klar.
Lås kan finnas i tre omfång: prenumeration, resursgrupp och resurs. När du använder ett lås i ett överordnat omfång ärver alla resurser inom det omfånget samma lås. Om du har lås som tillämpas på prenumerationen, resursgruppen eller resursomfånget måste du ta bort dem före migreringen. Mer information om lås och lås arv finns i Lås dina resurser för att skydda infrastrukturen.
Använd följande kommando för att kontrollera om det virtuella nätverket har några lås:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Ta bort alla befintliga lås med hjälp av följande kommando:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Relaterade kommandon för att kontrollera om din prenumeration eller resursgrupp har lås finns i Azure CLI-referensen för lås.
8. Förbered dina konfigurationer
Om din befintliga App Service-miljön använder ett anpassat domänsuffix måste du konfigurera ett för din nya App Service-miljön v3-resurs under migreringsprocessen. Migreringen misslyckas om du inte konfigurerar ett anpassat domänsuffix och använder ett för närvarande. Mer information om App Service-miljön anpassade v3-domänsuffix, inklusive krav, stegvisa instruktioner och metodtips finns i Suffix för anpassad domän för App Service-miljön.
Kommentar
Om du konfigurerar ett anpassat domänsuffix bör du när du lägger till nätverksbehörigheterna i ditt Azure-nyckelvalv se till att ditt nyckelvalv tillåter åtkomst från ditt App Service-miljön v3:s nya undernät. Om du kommer åt ditt nyckelvalv med en privat slutpunkt kontrollerar du att du har konfigurerat privat åtkomst korrekt med det nya undernätet.
Om du vill ange dessa konfigurationer, inklusive att identifiera det undernät som du valde tidigare, skapar du en annan fil med namnet parameters.json med följande information baserat på ditt scenario. Se till att använda det nya undernätet som du har valt för din nya App Service-miljön v3. Inkludera inte egenskaperna för ett anpassat domänsuffix om den här funktionen inte gäller för migreringen. Var uppmärksam på värdet för zoneRedundant egenskapen och ställ in den på samma värde som du använde i steget för utgående IP-generering. Du måste använda samma värde för zonredundans som du använde i steget för utgående IP-generering.
Om du migrerar utan ett anpassat domänsuffix använder du den här koden:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
Om du använder en användartilldelad hanterad identitet för din anpassade domänsuffixkonfiguration använder du den här koden:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Om du använder en systemtilldelad hanterad identitet för din anpassade domänsuffixkonfiguration använder du den här koden:
{
"properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
9. Migrera till App Service-miljön v3 och kontrollera status
När du har slutfört alla föregående steg kan du starta migreringen. Se till att du förstår konsekvenserna av migreringen.
Det här steget tar tre till sex timmar att slutföra. Under den tiden finns det ingen programavbrottstid. Skalning, distributioner och ändringar av dina befintliga App Service-miljön blockeras under det här steget.
Kör följande kommando för att starta migreringen:
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
Kör följande kommando för att kontrollera statusen för migreringen:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
När du har fått statusen MigrationPendingDnsChangeär migreringen klar och du har en App Service-miljön v3-resurs. Dina appar körs nu i din nya miljö och i din gamla miljö.
Hämta information om den nya miljön genom att köra följande kommando:
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Viktigt!
Under migreringen och under MigrationPendingDnsChange steget visar Azure-portalen felaktig information om dina App Service-miljön och dina appar. Använd Azure CLI för att kontrollera statusen för migreringen. Kontakta supporten om du har frågor om status för migreringen eller dina appar.
Kommentar
Om din migrering innehåller ett anpassat domänsuffix kan din anpassade domänsuffixkonfiguration visas som degraderad när migreringen är klar på grund av en känd bugg. Din App Service-miljön bör fortfarande fungera som förväntat. Den degraderade statusen bör matcha sig själv inom 6–8 timmar. Om konfigurationen har degraderats efter 8 timmar eller om ditt anpassade domänsuffix inte fungerar kontaktar du supporten.
10. Hämta inkommande IP-adresser för dina nya App Service-miljön v3 och uppdatera beroende resurser
Du har två App Service-miljön i det här skedet i migreringsprocessen. Dina appar körs i båda miljöerna. Du måste uppdatera alla beroende resurser för att använda den nya IP-inkommande adressen för din nya App Service-miljön v3. För interna motkopplade (ILB) App Service-miljön måste du uppdatera dina privata DNS-zoner så att de pekar på den nya inkommande IP-adressen.
Du kan hämta den nya inkommande IP-adressen för din nya App Service-miljön v3 genom att köra följande kommando som motsvarar din App Service-miljön lastbalanserare. Det är ditt ansvar att göra nödvändiga uppdateringar.
För ILB-App Service-miljön hämtar du den privata inkommande IP-adressen genom att köra följande kommando:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
För ELB-App Service-miljön hämtar du den offentliga inkommande IP-adressen genom att köra följande kommando:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
11. Omdirigera kundtrafik, verifiera din App Service-miljön v3 och slutför migreringen
Det här steget är din möjlighet att testa och verifiera din nya App Service-miljön v3. Som standard skickas trafik till dina App Service-miljön v2-klientdelar. Om du använder en ILB-App Service-miljön v3 kan du testa dina App Service-miljön v3-klientdelar genom att uppdatera din privata DNS-zon med den nya inkommande IP-adressen. Om du använder en ELB-App Service-miljön v3 beror testprocessen på din specifika nätverkskonfiguration. En enkel metod att testa för ELB-miljöer är att uppdatera värdfilen så att den använder din nya inkommande IP-adress App Service-miljön v3. Om du har tilldelat anpassade domäner till dina enskilda appar kan du också uppdatera deras DNS så att de pekar på den nya inkommande IP-adressen. Genom att testa den här ändringen kan du verifiera din App Service-miljön v3 helt innan du påbörjar det sista steget i migreringen där din gamla App Service-miljön tas bort. Om du kan komma åt dina appar utan problem innebär det att du är redo att slutföra migreringen.
När du har bekräftat att dina appar fungerar som förväntat kan du omdirigera kundtrafik till din nya App Service-miljön v3 genom att köra följande kommando. Det här kommandot tar också bort din gamla miljö. Du har 14 dagar på dig att slutföra det här steget. Om du inte slutför det här steget på 14 dagar återställs migreringen automatiskt tillbaka till en App Service-miljön v2. Kontakta supporten om du behöver mer än 14 dagar för att slutföra det här steget.
Om du hittar några problem eller bestämmer dig för att du inte längre vill fortsätta med migreringen kontaktar du supporten för att återställa migreringen. Kör inte DNS-ändringskommandot om du behöver återställa migreringen. Mer information finns i Återställa migrering.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
Kör följande kommando för att kontrollera statusen för det här steget:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Under det här steget får du statusen CompletingMigration. När du får statusen utförs omdirigeringssteget MigrationCompletedför trafik och migreringen är klar.