Migrering till App Service-miljö v3

Artikel
07/26/2024

Kommentar

Det finns två automatiserade migreringsfunktioner som hjälper dig att uppgradera till App Service Environment v3. Mer information om dessa funktioner och om du behöver hjälp med att avgöra vilket migreringsalternativ som passar dig finns i Beslutsträd för migreringsväg. Överväg ett av de automatiserade alternativen för en snabbare sökväg till App Service Environment v3.

Om du för närvarande använder App Service Environment v1 eller v2 har du möjlighet att migrera dina arbetsbelastningar till App Service Environment v3. App Service Environment v3 har fördelar och funktionsskillnader som ger förbättrat stöd för dina arbetsbelastningar och kan minska de totala kostnaderna. Överväg att använda de automatiserade migreringsfunktionerna om din miljö uppfyller kriterierna som beskrivs i beslutsträdet för migreringssökväg.

Om apptjänstmiljön inte stöds för migreringsfunktionerna måste du använda någon av de manuella metoderna för att migrera till App Service Environment v3.

Förutsättningar

Scenario: Du har en app som körs på App Service Environment v1 eller App Service Environment v2, och du behöver den appen för att köras på App Service Environment v3.

För alla migreringsmetoder som inte använder funktionerna för automatisk migrering måste du skapa App Service Environment v3-resursen och ett nytt undernät med valfri metod.

Nätverksändringar mellan App Service Environment v1/v2 och App Service Environment v3 omfattar nya (och för internetuppkopplade miljöer, ytterligare) IP-adresser. Du måste uppdatera alla infrastrukturer som förlitar sig på dessa IP-adresser. Se till att ta hänsyn till ändringar av inkommande beroenden, till exempel Azure Load Balancer-porten.

Flera App Service-miljöer kan inte finnas i ett enda undernät. Om du behöver använda ditt befintliga undernät för din nya App Service Environment v3-resurs måste du ta bort den befintliga App Service-miljön innan du skapar en ny. I det här scenariot rekommenderar vi att du säkerhetskopierar dina appar och sedan återställer dem i den nya miljön när du har skapat och konfigurerat miljön. Den här processen orsakar programavbrott på grund av den tid det tar att:

Ta bort den gamla miljön.
Skapa App Service Environment v3-resursen.
Konfigurera alla infrastrukturer och anslutna resurser så att de fungerar med den nya miljön.
Distribuera dina appar till den nya miljön.

Checklista innan du migrerar appar

Skapa en App Service Environment v3-resurs .
Uppdatera eventuella nätverksberoenden med DE IP-adresser som är associerade med den nya miljön.
Planera för stilleståndstid (om tillämpligt).
Besluta om en process för att återskapa dina appar i din nya miljö.

Storlek och skala miljön

App Service Environment v3 använder Isolerade v2 Azure App Service-planer som prissätts och storleksanpassas på ett annat sätt än isolerade planer. Granska prisinformationen för att förstå hur du är en ny miljö måste vara storleksanpassad och skalad för att säkerställa lämplig kapacitet. Det finns ingen skillnad i hur du skapar App Service-planer för App Service Environment v3 jämfört med tidigare versioner.

Utvärdera säkerhetskopiering och återställning

Du kan använda säkerhetskopierings - och återställningsfunktionen för att hålla appkonfigurationen, filinnehållet och databasen ansluten till din app när du migrerar till den nya miljön.

Du måste konfigurera anpassade säkerhetskopior för dina appar för att kunna återställa dem till App Service Environment v3. Automatisk säkerhetskopiering stöder inte återställning i olika App Service Environment-versioner. Mer information om anpassade säkerhetskopior finns i Automatiska eller anpassade säkerhetskopieringar. Skärmbild som visar alternativ för att konfigurera anpassade säkerhetskopior för en App Service-app.

Du kan välja en anpassad säkerhetskopia och återställa den till App Service i din App Service Environment v3-resurs. Du måste skapa den App Service-plan som du ska återställa till innan du återställer appen. Du kan välja att återställa säkerhetskopian till produktionsplatsen, ett befintligt fack eller ett nytt fack som du skapar under återställningsprocessen.

Skärmbild som visar hur du använder en säkerhetskopia för att återställa en App Service-app i App Service Environment v3.

Förmåner	Begränsningar
Snabb – bör bara ta 5 till 10 minuter per app.	Stödet är begränsat till vissa databastyper.
Du kan återställa flera appar samtidigt. (Du måste konfigurera återställning för varje app individuellt.)	Den gamla miljön, den nya miljön och stödresurserna (till exempel appar, databaser, lagringskonton och containrar) måste alla finnas i samma prenumeration.
MySQL-databaser i appen säkerhetskopieras automatiskt utan någon konfiguration.	Säkerhetskopior kan vara upp till 10 GB app- och databasinnehåll. Upp till 4 GB av innehållet kan vara databassäkerhetskopian. Om säkerhetskopieringsstorleken överskrider den här gränsen får du ett fel.
Du kan återställa appen till en ögonblicksbild av ett tidigare tillstånd.	Det går inte att använda ett brandväggsaktiverat lagringskonto som mål för dina säkerhetskopior.
Du kan integrera med Azure Traffic Manager och Azure Application Gateway för att distribuera trafik över gamla och nya miljöer.	Det går inte att använda ett lagringskonto med privata slutpunkter för säkerhetskopiering och återställning.
Du kan skapa tomma webbappar att återställa till i den nya miljön innan du börjar återställa för att påskynda processen.	Endast anpassade säkerhetskopior stöds.

Klona din app till App Service Environment v3

Kloning av dina appar är en annan funktion som du kan använda för att få dina Windows-appar till App Service Environment v3. Begränsningarna för kloning av appar är desamma som för apptjänstens säkerhetskopieringsfunktion. Mer information finns i Säkerhetskopiera en app i Azure App Service.

Kommentar

Kloning av appar stöds endast för App Service-planer i Windows.

Vi rekommenderar den här lösningen för användare som använder App Service i Windows och inte kan migrera med hjälp av migreringsfunktionen. Du måste konfigurera din nya App Service Environment v3-resurs innan du klonar några appar. Kloning av en app kan ta upp till 30 minuter att slutföra.

Om du vill klona en app med hjälp av PowerShell läser du anvisningarna.

Så här klonar du en app med hjälp av Azure-portalen:

Gå till din befintliga App Service-plan i Azure-portalen. Under Utvecklingsverktyg väljer du Klona app.
Fyll i de obligatoriska fälten med hjälp av informationen för din nya App Service Environment v3-resurs:
1. För Resursgrupp väljer du en befintlig resursgrupp eller skapar en ny.
2. Ge din app ett namn som Namn. Det här namnet kan vara samma som den gamla appen, men webbplatsens standard-URL för den nya miljön kommer att vara annorlunda. Du måste uppdatera anpassade DNS- eller anslutna resurser så att de pekar på den nya URL:en.
3. För Region använder du ditt App Service Environment v3-namn.
4. Om du vill klona distributionskällan markerar du kryssrutan Klona distributionskällan .
5. För Windows-plan kan du använda en befintlig App Service-plan från din nya miljö om du redan har skapat en, eller så kan du skapa en ny plan. Tillgängliga App Service-planer i din nya App Service Environment v3-resurs visas i listrutan.
6. För Sku och storlek ändrar du minnet och processorn efter behov genom att använda något av alternativen Isolerad v2 om du skapar en ny App Service-plan. App Service Environment v3 använder isolerade v2-planer, som har mer minne och processor per motsvarande instansstorlek jämfört med isolerade planer. Mer information finns i prisinformationen för App Service Environment v3.

Skärmbild som visar alternativ för att klona en app till App Service Environment v3 med hjälp av portalen.

Förmåner	Begränsningar
Du kan automatisera kloningen med hjälp av PowerShell.	Stöds endast för App Service-planer i Windows.
Du kan klona flera appar samtidigt. (Kloning måste konfigureras för varje app individuellt eller via ett skript.)	Stödet är begränsat till vissa databastyper.
Du kan integrera med Azure Traffic Manager och Azure Application Gateway för att distribuera trafik över gamla och nya miljöer.	Den gamla miljön, den nya miljön och stödresurserna (till exempel appar, databaser, lagringskonton och containrar) måste alla finnas i samma prenumeration.

Skapa dina appar manuellt i App Service Environment v3

Om migreringsfunktionen inte stöder dina appar eller om du vill ta en mer manuell väg kan du distribuera dina appar genom att följa samma process som du använde för din befintliga App Service-miljö.

Du kan exportera Azure Resource Manager-mallar (ARM-mallar) för dina befintliga appar, App Service-planer och andra resurser som stöds och distribuera dem i eller med din nya miljö. Om du vill exportera en mall för bara en app går du till din App Service-plan. Under Automation väljer du Exportera mall.

Skärmbild av alternativet att exportera en mall i den vänstra rutan i Azure-portalen.

Du kan också exportera mallar för flera resurser direkt från resursgruppen. Gå till resursgruppen, välj de resurser som du vill ha en mall för och välj sedan Exportera mall.

Skärmbild av alternativet för att exportera en mall för resurser från en resursgrupp.

Följande inledande ändringar av ARM-mallarna krävs för att få dina appar till App Service Environment v3:

Uppdatera sku parametrar för en App Service-plan till en isolerad v2-plan:

"type": "Microsoft.Web/serverfarms",
"apiVersion": "2021-02-01",
"name": "[parameters('serverfarm_name')]",
"location": "East US",
"sku": {
    "name": "I1v2",
    "tier": "IsolatedV2",
    "size": "I1v2",
    "family": "Iv2",
    "capacity": 1
},

Uppdatera parametern App Service-plan (serverfarm) som appen ska distribueras till till den plan som är associerad med App Service Environment v3.
Uppdatera parametern värdmiljöprofil (hostingEnvironmentProfile) till det nya resurs-ID:t för App Service Environment v3.

En ARM-mallexport innehåller alla egenskaper som resursprovidrar exponerar för resurserna. Ta bort alla icke-obligatoriska egenskaper, till exempel egenskaper som pekar på domänen för den gamla appen. Du kan till exempel förenkla resursen sites till följande exempel:

"type": "Microsoft.Web/sites",
"apiVersion": "2021-02-01",
"name": "[parameters('site_name')]",
"location": "East US",
"dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]"
],
"properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]",
    "siteConfig": {
        "linuxFxVersion": "NODE|14-lts"
     },
    "hostingEnvironmentProfile": {
        "id": "[parameters('hostingEnvironments_externalid')]"
    }
}

Andra ändringar kan krävas, beroende på hur du har konfigurerat din app. Om du till exempel använder systemtilldelade hanterade identiteter och samma programnamn för dina gamla och nya miljöer kan det uppstå konflikter. För att lösa den här konflikten och undvika stilleståndstid kan du använda en användartilldelad hanterad identitet.

Du kan distribuera ARM-mallar med hjälp av Azure-portalen, Azure CLI eller PowerShell.

Migrera manuellt

Migreringsfunktionen på plats automatiserar migreringen till App Service Environment v3 och överför alla dina appar till den nya miljön. Det är ungefär en timmes stilleståndstid under den här migreringen. Om dina appar inte kan ha någon stilleståndstid rekommenderar vi att du använder migreringsfunktionen sida vid sida, vilket är ett alternativ för migrering utan avbrott eftersom den nya miljön skapas i ett annat undernät. Om du också väljer att inte använda migreringsfunktionen sida vid sida kan du använda något av de manuella alternativen för att återskapa dina appar i App Service Environment v3.

Du kan distribuera trafik mellan dina gamla och nya miljöer med hjälp av Application Gateway. Om du använder en intern apptjänstmiljö för lastbalanserare (ILB) skapar du en Azure Application Gateway-instans med en extra serverdelspool för att distribuera trafik mellan dina miljöer. Information om ILB App Service-miljöer och Internetuppkopplade App Service-miljöer finns i Application Gateway-integrering.

Du kan också använda tjänster som Azure Front Door, Azure Content Delivery Network och Azure Traffic Manager för att distribuera trafik mellan miljöer. Med hjälp av dessa tjänster kan du testa din nya miljö på ett kontrollerat sätt och hjälper dig att flytta till din nya miljö i din egen takt.

När migreringen och alla tester med den nya miljön har slutförts tar du bort din gamla App Service-miljö, de appar som finns på den och eventuella stödresurser som du inte längre behöver. Du fortsätter att debiteras för alla resurser som du inte tar bort.

Vanliga frågor och svar

Hur vet jag om jag ska migrera till App Service Environment v3 med något av de manuella alternativen?
Mer information om vilket migreringsalternativ som passar dig finns i Beslutsträd för migreringssökväg. Om din miljö uppfyller de kriterier som beskrivs i beslutsträdet för migreringssökväg bör du överväga att använda en av de automatiserade migreringsfunktionerna för en snabbare väg till App Service Environment v3. Manuell migrering rekommenderas om du långsamt behöver flytta dina appar till din nya miljö och verifiera under hela processen.
Kommer det att uppstå avbrott under migreringen?
Stilleståndstiden är beroende av migreringsprocessen. Om du har en annan App Service-miljö som du kan peka trafik till när du migrerar, eller om du kan använda ett annat undernät för att skapa din nya miljö, får du inte avbrottstid. Om du måste använda samma undernät är det stilleståndstid när du tar bort den gamla miljön, skapar App Service Environment v3-resursen, skapar de nya App Service-planerna, skapar apparna igen och uppdaterar alla resurser som använder de nya IP-adresserna.
Behöver jag ändra något om mina appar för att få dem att köras i App Service Environment v3?
Nej. Appar som körs i App Service Environment v1 och v2 bör inte behöva några ändringar för att köras på App Service Environment v3. Om du använder IP SSL måste du ta bort IP SSL-bindningarna innan du migrerar.
Vad händer om App Service-miljön har ett anpassat domänsuffix?
Migreringsfunktionen stöder detta migreringsscenario. Du kan migrera med hjälp av en manuell metod om du inte vill använda migreringsfunktionen. Du kan konfigurera ditt anpassade domänsuffix när du skapar din App Service Environment v3-resurs eller när som helst efter.
Vad händer om min App Service Environment v2-resurs är zonfäst?
Zonanslutning stöds inte i App Service Environment v3. Du kan välja att aktivera zonredundans när du skapar din App Service Environment v3-resurs.
Vilka egenskaper för min App Service-miljö ändras?
Granska funktionsskillnaderna mellan App Service Environment v3 och tidigare versioner. För ILB App Service-miljöer behåller du samma IP-adress för ILB. För Internetuppkopplade App Service-miljöer ändras den offentliga IP-adressen och den utgående IP-adressen.

För Internetuppkopplade App Service-miljöer fanns det tidigare en enda IP-adress för både inkommande och utgående. För App Service-miljön v3 används separata adresser. Mer information finns i Nätverk för App Service-miljö V3.
Stöds för säkerhetskopiering och återställning för att flytta appar från App Service-miljön v2 till v3? Säkerhetskopierings - och återställningsfunktionen stöder återställning av appar mellan App Service Environment-versioner så länge du använder en anpassad säkerhetskopia för återställningen. Automatisk säkerhetskopiering stöder inte återställning till olika App Service Environment-versioner.
Vad händer med mina App Service Environment v1- och v2-resurser efter den 31 augusti 2024?
Om du inte har migrerat till App Service Environment v3 efter den 31 augusti 2024 kommer dina App Service Environment v1- och v2-resurser och de appar som distribueras i dem inte längre att vara tillgängliga.

App Service Environment v1 och v2 finns i App Service-skalningsenheter som körs i Azure Cloud Services-arkitektur (klassisk). Eftersom den här arkitekturen kommer att dras tillbaka den 31 augusti 2024 kommer App Service Environment v1 och v2 inte att vara tillgängliga efter det datumet. Migrera till App Service Environment v3 för att hålla dina appar igång, eller spara eller säkerhetskopiera alla resurser eller data som du behöver underhålla.