Flytta Azure App Services till en annan region

Den här artikeln beskriver hur du flyttar App Service-resurser till en annan Azure-region.

Det finns olika orsaker till varför du kanske vill flytta dina befintliga Azure-resurser från en region till en annan. Du kanske vill:

• Dra nytta av en ny Azure-region.
• Distribuera endast funktioner eller tjänster som är tillgängliga i specifika regioner.
• Uppfylla interna policy- och styrningskrav.
• Justera med företagsfusioner och förvärv
• Uppfylla kapacitetsplaneringskraven.

App Service-resurser är regionspecifika och kan inte flyttas mellan regioner. Du måste skapa en kopia av dina befintliga App Service-resurser i målregionen och sedan flytta innehållet till den nya appen. Om källappen använder en anpassad domän kan du migrera den till den nya appen i målregionen när flytten har slutförts.

För att göra det enklare att kopiera din app kan du säkerhetskopiera och återställa enskilda App Service-appar till en App Service-plan i en annan region.

Förutsättningar

• Kontrollera att App Service-appen finns i den Azure-region som du vill flytta från.
• Kontrollera att målregionen stöder App Service och alla relaterade tjänster, vars resurser du vill flytta.
• Kontrollera att det finns tillräcklig behörighet för att distribuera App Service-resurser till målprenumerationen och -regionen.
• Kontrollera om någon Azure-princip har tilldelats en regionbegränsning.
• Överväg eventuella driftskostnader eftersom priserna på beräkningsresurser kan variera från region till region. Information om hur du beräknar eventuella kostnader finns i Priskalkylatorn.

Förbereda

Identifiera alla App Service-resurser som du använder för närvarande. Till exempel:

• App Service-appar
• App Service-planer
• Distributionsplatser
• Anpassade domäner som köpts i Azure
• TLS/SSL-certifikat
• Azure Virtual Network-integrering
• Hybridanslutningar.
• Hanterade identiteter
• Inställningar för säkerhetskopiering

Vissa resurser, till exempel importerade certifikat eller hybridanslutningar, innehåller integrering med andra Azure-tjänster. Information om hur du flyttar dessa resurser mellan regioner finns i dokumentationen för respektive tjänster.

Planera

Det här avsnittet är en checklista för planering inom följande områden:

• Tillstånds-, lagrings- och underordnade beroenden
• Certifikat
• Konfiguration
• VNet-anslutning/Anpassade namn/DNS
• Identiteter
• Tjänstslutpunkter

Tillstånds-, lagrings- och nedströmsberoenden

• Avgör om din App Service-app är tillståndskänslig eller tillståndslös. Även om vi rekommenderar att App Service Apps är tillståndslösa och att filerna på %HOME%\site enheten bara ska vara de som krävs för att köra det distribuerade programmet med temporära filer, är det fortfarande möjligt att lagra körningsprogramtillståndet på den %HOME%\site virtuella enheten. Om ditt program skriver tillstånd på den delade lagringssökvägen för appen måste du planera hur du ska hantera det tillståndet under en resursflytt.

  Dricks

  Du kan använda Kudu för att, tillsammans med portalåtkomst, tillhandahålla ett API för filåtkomst (VFS) som kan läsa/skriva filer under %HOME%\site katalogen. Mer information finns i Kudu Wiki.

• Sök efter intern cachelagring och tillstånd i programkoden.

• Inaktivera inställningen för sessionstillhörighet. Där det är möjligt rekommenderar vi att du inaktiverar inställningen för sessionstillhörighet. Om du inaktiverar sessionstillhörighet förbättras belastningsutjämningen för en horisontell utskalning. Alla interna tillstånd kan påverka planeringen för att minska en arbetsbelastning – särskilt om noll nedtid är ett krav. Om möjligt kan det vara fördelaktigt att omstrukturera alla programtillstånd för att göra programmet tillståndslöst inför flytten.

• Analysera databas anslutningssträng. Databas anslutningssträng finns i appinställningarna. De kan dock också vara hårdkodade eller hanterade i konfigurationsfiler som levereras med programmet. Analysera och planera för datamigrering/replikering som en del av planeringen på högre nivå för att flytta arbetsbelastningen. För chattiga eller svarstidskritiska program fungerar det inte för programmet i målregionen att nå tillbaka till datakällor i källregionen.

• Analysera extern cachelagring (till exempel Redis). Programcacheminnen ska distribueras så nära programmet som möjligt. Analysera hur cacheminnen fylls i, principer för förfallodatum/borttagning och eventuella effekter som en kall cache kan ha på de första användarna att komma åt arbetsbelastningen efter cut-over.

• Analysera och planera för API-beroenden (eller program)-beroenden Kommunikationen mellan regioner är betydligt mindre högpresterande om appen i målregionen når tillbaka till beroenden som fortfarande finns i källregionen. Vi rekommenderar att du flyttar alla underordnade beroenden som en del av arbetsbelastningsflytten. Men *lokala* resurser är undantaget, särskilt de resurser som ligger geografiskt närmare målregionen (vilket kan vara fallet för repatrieringsscenarier).

  Azure Container Registry kan vara ett underordnat (körningsberoende) beroende för App Service som är konfigurerat att köras mot anpassade containeravbildningar. Det är mer meningsfullt att containerregistret finns i samma region som själva appen. Överväg att ladda upp de bilder som krävs till en ny ACR i mål-get-regionen. Annars bör du överväga att använda geo-replikeringsfunktionen om du planerar att behålla bilderna i källregionen.

• Analysera och planera för regionala tjänster. Application Insights- och Log Analytics-data är regionala tjänster. Överväg att skapa nya Application Insights- och Log Analytics-lagring i målregionen. För App Insights påverkar en ny resurs också anslutningssträng som måste uppdateras som en del av ändringen i App Configuration.

Certifikat

App Service-certifikatresurser kan flyttas till en ny resursgrupp eller prenumeration, men inte mellan regioner. Certifikat som kan exporteras kan också importeras till appen eller till Key Vault i den nya regionen. Den här export- och importprocessen motsvarar en flytt mellan regioner.

Det finns olika typer av certifikat som måste beaktas när du planerar din tjänstflytt:

Certifikattyp	Exportera	Kommentarer
App Service-hanterad	Nej	Återskapa dessa certifikat i den nya regionen.
Hanterat Azure Key Vault	Ja	Dessa certifikat kan exporteras från Key Vault och sedan importeras till Key Vault i den nya regionen.
Privat nyckel (självhanterad)	Ja	Certifikat som du har skaffat utanför Azure kan exporteras från App Service och sedan importeras antingen till den nya appen eller till Key Vault i den nya regionen.
Offentlig nyckel	Nej	Din app kan ha certifikat med endast en offentlig nyckel och ingen hemlighet, som används för att komma åt andra skyddade slutpunkter. Hämta nödvändiga certifikatfiler för offentlig nyckel och importera dem till appen i den nya regionen.

Några ytterligare saker att tänka på:

• Apptilldelade adresser, där en App Service-apps SSL-anslutning är bunden till en specifik app som är avsedd FÖR IP, kan användas för att tillåta anrop från tredjepartsnätverk till App Service. Till exempel kanske ett nätverk/IT-administratör vill låsa utgående anrop från ett lokalt nätverk eller ett virtuellt nätverk för att använda en statisk, välkänd adress. Om funktionen Apptilldelad adress används bör därför överordnade brandväggsregler – till exempel interna, externa eller tredje parter – för anroparna till appen kontrolleras och informeras om den nya adressen. Brandväggsregler kan vara interna, externa eller tredje parter, till exempel partner eller välkända kunder.

• Överväg eventuell överordnad virtuell nätverksinstallation (NVA) eller omvänd proxy. NVA-konfigurationen kan behöva ändras om du skriver om värdhuvudet eller SSL-avslutningen.

Kommentar

App Service-miljön är det enda App Service-erbjudandet som tillåter underordnade anrop till underordnade programberoenden via SSL, där SSL förlitar sig på självsignerade/PKI med byggda med rotcertifikatutfärdarcertifikat som inte är standard. Tjänsten för flera klientorganisationer ger inte åtkomst för kunder att ladda upp till det betrodda certifikatarkivet.

App Service-miljön i dag tillåter inte SSL-certifikatköp, utan endast Bring Your Own-certifikat. IP-SSL är inte möjligt (och är inte meningsfullt), men SNI är det. Interna App Service-miljön skulle inte associeras med en offentlig domän och därför måste de SSL-certifikat som används tillhandahållas av kunden och kan därför transporteras, till exempel certifikat för internt bruk som genereras med hjälp av PKI. App Service-miljön v3 i externt läge har samma funktioner som den vanliga apptjänsten för flera klientorganisationer.

Konfiguration

• Du kan ta en ögonblicksbild av befintliga appinställningar och anslutningssträng från Azure Portal. Expandera Inställningar>Miljövariabler, välj Avancerad redigering under antingen Appinställningar eller Anslutningssträngar och spara JSON-utdata som innehåller befintliga inställningar eller anslutningar. Du måste återskapa de här inställningarna i den nya regionen, men själva värdena kommer sannolikt att ändras till följd av efterföljande regionändringar i de anslutna tjänsterna.

• Befintliga Key Vault-referenser kan inte exporteras över en geografisk Azure-gräns. Du måste återskapa alla nödvändiga referenser i den nya regionen.

• Din appkonfiguration kan hanteras av Azure App Configuration eller från något annat centralt (nedströms) databasberoende. Granska alla appkonfigurationslager eller liknande butiker för miljö- och regionspecifika inställningar som kan kräva ändringar.

• Kontrollera vilken diskfilkonfiguration som helst, som kanske eller kanske inte åsidosättas av programinställningarna.

VNet-anslutning/Anpassade namn/DNS

• App Service-miljön är en VNet-inmatad enskild klienttjänst. App Service-miljön nätverk skiljer sig från App Service för flera klientorganisationer, som kräver en eller båda "privata slutpunkter" eller "Regional VNet-integrering". Andra alternativ som kan vara i spel är äldre P2S VPN-baserad VNet-integrering och Hybridanslutningar (en Azure Relay-tjänst).

  Kommentar

  ASEv3-nätverk förenklas – Azure Management-trafiken och App Service-miljön egna underordnade beroenden är inte synliga för kundens virtuella nätverk, vilket avsevärt förenklar den konfiguration som krävs där kunden använder en krafttunnel för all trafik eller skickar en delmängd av utgående trafik via en virtuell nätverksinstallation/brandvägg.

  Hybridanslutningar (Azure Relay) är regionala. Om hybridanslutningar används och även om ett Azure Relay-namnområde kan flyttas till en annan region, skulle det vara enklare att distribuera om hybridanslutningen (se till att hybridanslutningen är konfigurerad i den nya regionen vid distribution av målresurserna) och länka om den till Hybridanslutningshanteraren. Den Hybridanslutningshanteraren platsen bör övervägas noggrant.

• Följ strategin för en varm väntelägesregion. Se till att kärnnätverk och anslutning, hubbnätverk, domänkontrollanter, DNS, VPN eller Express Route osv., finns och testas före resursflytten.

• Verifiera eventuella överordnade eller underordnade nätverks-ACL:er och konfigurationer. Du kan till exempel överväga en extern nedströmstjänst som endast tillåterlistning av din apptrafik. En flytt till en ny programplan för en apptjänst med flera klientorganisationer skulle då också vara en ändring i utgående IP-adresser.

• I de flesta fall är det bäst att se till att målregionens virtuella nätverk har unikt adressutrymme. Ett unikt adressutrymme underlättar VNet-anslutningen om det till exempel krävs för att replikera data. I dessa scenarier finns det därför ett implicit krav på att ändra:

  • Privat DNS
  • Hårdkodad eller extern konfiguration som refererar till resurser efter IP-adress (utan värdnamn)
  • Nätverks-ACL:er inklusive nätverkssäkerhetsgrupper och brandväggskonfiguration (överväg påverkan på eventuella lokala NVA:er även här)
  • Routningsregler, användardefinierade routningstabeller

  Se också till att kontrollera konfigurationen inklusive regionspecifika IP-intervall/tjänsttaggar om du fortsätter med befintliga DevOps-distributionsresurser.

• Färre ändringar krävs för kunddistribuerad privat DNS som är konfigurerad att vidarebefordra till Azure för Azure-domäner och privata Azure DNS-zoner. Men eftersom privata slutpunkter baseras på ett resurs-FQDN och detta ofta också är resursnamnet (som kan förväntas vara annorlunda i målregionen), kom ihåg att korskontrollera konfigurationen för att säkerställa att FQDN som refereras i konfigurationen uppdateras i enlighet med detta.

• Återskapa privata slutpunkter, om de används, i målregionen. Detsamma gäller för regional VNet-integrering.

• DNS för App Service-miljön hanteras vanligtvis via kundernas privata anpassade DNS-lösning (det finns en manuell åsidosättning av inställningarna som är tillgängliga för en grundläggande per app). App Service-miljön tillhandahåller en lastbalanserare för ingress/utgående, medan App Service själv filtrerar på värdhuvuden. Därför kan flera anpassade namn pekas mot samma App Service-miljön ingressslutpunkt. App Service-miljön kräver inte domänverifiering.

  Kommentar

  Kudu-slutpunkten för App Service-miljön v3 är endast tillgänglig på {resourcename}.scm.{asename}.appserviceenvironment.net. Mer information om App Service-miljön v3 DNS och nätverk osv. finns i App Service-miljön nätverk.

  För App Service-miljön äger kunden routningen och därför de resurser som används för cut-over. Där åtkomst är aktiverad till App Service-miljön externt – vanligtvis via en NVA för Layer 7 eller omvänd proxy – kan Traffic Manager eller Azure Front Door/Other L7 Global Load Balancing Service användas.

• För den offentliga multitenantversionen av tjänsten etableras ett standardnamn {resourcename}.azurewebsites.net för dataplanets slutpunkter, tillsammans med ett standardnamn för Kudu-slutpunkten (SCM). Eftersom tjänsten tillhandahåller en offentlig slutpunkt som standard måste bindningen verifieras för att bevisa domänägarskapet. Men när bindningen är på plats krävs ingen omverifiering och krävs inte heller för att offentliga DNS-poster ska peka på App Service-slutpunkten.

• Om du använder en anpassad domän binder du den förebyggande till målappen. Verifiera och aktivera domänen i målappen.

Identiteter

• Du måste återskapa alla systemtilldelade hanterade identiteter tillsammans med din app i den nya målregionen. Vanligtvis skapas en automatiskt Skapad Microsoft Entra-ID-app, som används av EasyAuth, som standard till appens resursnamn.

• Användartilldelade hanterade identiteter kan inte heller flyttas mellan regioner. Om du vill behålla användartilldelade hanterade identiteter i samma resursgrupp med din app måste du återskapa dem i den nya regionen. Mer information finns i Flytta hanterade identiteter för Azure-resurser till en annan region.

• Ge de hanterade identiteterna samma behörigheter i dina omlokaliserade tjänster som de ursprungliga identiteter som de ersätter, inklusive gruppmedlemskap.

• Planera för att flytta identitetsprovidern (IDP) till målregionen. Även om Microsoft Entra ID är en global tjänst förlitar sig vissa lösningar på en lokal (eller nedströms lokal) IDP.

• Uppdatera alla resurser till App Service som kan förlita sig på Kudu FTP-autentiseringsuppgifter.

Tjänstslutpunkter

Tjänstslutpunkterna för virtuella nätverk för Azure App Service begränsar åtkomsten till ett angivet virtuellt nätverk. Slutpunkterna kan också begränsa åtkomsten till en lista över adressintervall för IPv4 (Internet Protocol version 4). Alla användare som ansluter till händelsehubbar utanför dessa källor nekas åtkomst. Om tjänstslutpunkter konfigurerades i källregionen för Event Hubs-resursen skulle samma sak behöva göras i målområdet.

För att Azure App Service ska kunna återskapas till målregionen måste det virtuella nätverket och undernätet skapas i förväg. Om flytten av dessa två resurser utförs med Azure Resource Mover-verktyget konfigureras inte tjänstslutpunkterna automatiskt. Därför måste de konfigureras manuellt, vilket kan göras via Azure Portal, Azure CLI eller Azure PowerShell.

Omlokalisera

Om du vill flytta App Service-resurser kan du använda antingen Azure Portal eller Infrastruktur som kod (IaC).

Flytta med hjälp av Azure Portal

Den största fördelen med att använda Azure Portal för att flytta är dess enkelhet. Appen, planen och innehållet samt många inställningar klonas till den nya App Service-resursen och planen.

Tänk på att för nivåerna App Service-miljön (isolerade) måste du distribuera om hela App Service-miljön i en annan region först, och sedan kan du börja distribuera om de enskilda planerna i den nya App Service-miljön i den nya regionen.

Så här flyttar du dina App Service-resurser till en ny region med hjälp av Azure Portal:

1. Skapa en säkerhetskopiering av källappen.
2. Skapa en app i en ny App Service-plan i målregionen.
3. Återställa säkerhetskopieringen i målappen
4. Om du använder en anpassad domän binder du den förebyggande till målappen med asuid. och aktiverar domänen i målappen.
5. Konfigurera allt annat i målappen så att det är samma som källappen och verifiera konfigurationen.
6. När du är redo för att den anpassade domänen ska peka på målappen ska du mappa om domännamnet.

Flytta med IaC

Använd IaC när det finns en befintlig CI/CD-pipeline (Continuous Integration and Continuous Delivery/Deployment) eller kan skapas. Med en CI/CD-pipeline på plats kan din App Service-resurs skapas i målregionen med hjälp av en distributionsåtgärd eller en Kudu zip-distribution.

SLA-kraven bör avgöra hur mycket ytterligare arbete som krävs. Till exempel: Är detta en omdistribuering med begränsad stilleståndstid, eller krävs det en nära realtidsnedskärning med minimal till ingen stilleståndstid?

Införandet av externa, globala trafikroutningstjänster, till exempel Traffic Manager eller Azure Front Door, hjälper till att underlätta gränsdragningen för externa användare och program.

Dricks

Det är möjligt att använda Traffic Manager (ATM) när du redväxlar över App Services bakom privata slutpunkter. Även om de privata slutpunkterna inte kan nås av Traffic Manager-avsökningar – om alla slutpunkter är degraderade tillåter ATM routning. Mer information finns i Kontrollera Azure App Service-trafik med Azure Traffic Manager.

Validera

När flytten är klar testar och validerar du Azure App Service med de rekommenderade riktlinjerna:

• När Azure App Service har flyttats till målregionen kör du ett rök- och integrationstest. Du kan testa eller köra ett test manuellt via ett skript. Kontrollera att alla konfigurationer och beroende resurser är korrekt länkade och att alla konfigurerade data är tillgängliga.

• Verifiera alla Azure App Service-komponenter och integrering.

• Utför integreringstestning på målregionens distribution, inklusive alla formella regressionstester. Integreringstestning bör överensstämma med de vanliga rhythm of business-distributions- och testprocesserna som gäller för arbetsbelastningen.

• I vissa scenarier, särskilt när omlokaliseringen innehåller uppdateringar, ändringar av program eller Azure-resurser eller en ändring i användningsprofilen, använder du belastningstestning för att verifiera att den nya arbetsbelastningen är lämplig för ändamålet. Belastningstestning är också en möjlighet att verifiera åtgärder och övervakningstäckning. Använd till exempel belastningstestning för att verifiera att nödvändig infrastruktur och programloggar genereras korrekt. Belastningstester ska mätas mot etablerade arbetsbelastningsprestandabaslinjer.

Dricks

En App Service-flytt är också en möjlighet att utvärdera tillgänglighets- och haveriberedskapsplaneringen på nytt. App Service och App Service-miljön (App Service-miljön v3) stöder tillgänglighetszoner och vi rekommenderar att du konfigurerar med en konfiguration av tillgänglighetszoner. Tänk på förutsättningarna för distribution, prissättning och begränsningar och ta med dessa i planeringen för resursflytt. Mer information om tillgänglighetszoner och App Service finns i Tillförlitlighet i Azure App Service.

Rensa

Ta bort källappen och App Service-planen. En App Service-plan på den icke-kostnadsfria nivån medför en avgift, även om ingen app körs i den.

Nästa steg

Kloning av Azure App Service-appar med PowerShell