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 niska veze. Databas niska veze 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 även niska veze som måste uppdateras som en del av ändringen i App Configuration.

Certifikat

Det finns ett antal olika typer av certifikat som måste beaktas när du planerar din App Service-flytt:

• Ett kostnadsfritt hanterat certifikat från App Service kan inte exporteras.
• Ett App Service-certifikat via Azure Key Vault kan exporteras med PS1/CLI.
• Ett certifikat som du hanterar utanför App Service.
• Ett App Service-certifikat, som inte hanteras via Azure Key Vault, kan exporteras.
• App Service-certifikatresurser kan flyttas till en ny resursgrupp eller prenumeration men inte mellan regioner. Flytt mellan regioner stöds inte av App Service-certifikat.
• Certifikat som hanteras som du hanterar och lagrar i Azure Key Vault måste först exporteras från källnyckelvalvet och importeras på nytt till målnyckelvalvet som är associerat med målappen.

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 Environment ä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 Environment tillåter i dag inte köp av SSL-certifikat, utan endast Bring Your Own-certifikat. IP-SSL är inte möjligt (och är inte meningsfullt), men SNI är det. Den 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 Environment v3 i externt läge delar samma funktioner som den vanliga apptjänsten för flera klientorganisationer.

Konfiguration

• Granska Appkonfiguration för miljö- och regionspecifika inställningar som kan behöva ändras. Se till att kontrollera innehåller diskfilskonfiguration, som kanske eller kanske inte åsidosättas med appinställningar.

• Tänk på att konfigurationen också kan hanteras från ett centralt (nedströms) databasberoende eller en tjänst som Azure Application Configuration.

• Återskapa Referenser till App Service Key Vault. Key Vault-referenser är relaterade till den unika MSI som tilldelats resursen (som har åtkomst till KV-dataplanet) och själva Nyckelvalvet måste troligen finnas i samma källregion. Az Key Vault-innehåll kan inte exporteras över en geografisk Azure-gräns.

VNet-anslutning/Anpassade namn/DNS

• App Service Environment är en VNet-inmatad enskild klienttjänst. App Service Environment-nätverk skiljer sig från App Service med flera klientorganisationer, vilket 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 Environments egna underordnade beroenden är inte synliga för kundens virtuella nätverk, vilket avsevärt förenklar konfigurationen som krävs där kunden använder en force-tunnel 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 Hybrid-Upravljač za uspostavljanje veze. Hybrid-Upravljač za uspostavljanje veze plats 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 Environment 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 Environment 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 slutpunkt för App Service Environment-ingressen. App Service Environment kräver inte domänverifiering.

  Kommentar

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

  För App Service Environment äger kunden routningen och därför de resurser som används för cut-over. Oavsett var å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}.azurwwebsites.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

• Återskapa apptjänsthanterade tjänstidentiteter i den nya målregionen.

• Tilldela den nya NEDSTRÖMS-tjänståtkomsten (RBAC) för MSI-autentiseringsuppgifter. Vanligtvis är en automatiskt skapad Microsoft Entra-ID-app (en som används av EasyAuth) standardvärdet för appens resursnamn. Du kan tänka på detta för att återskapa en ny resurs i målregionen. Ett användardefinierat tjänsthuvudnamn skulle vara användbart eftersom det kan tillämpas på både källa och mål med extra åtkomstbehörigheter för måldistributionsresurser.

• 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-portalen, Azure CLI eller Azure PowerShell.

Omlokalisera

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

Flytta med Hjälp av Azure-portalen

Den största fördelen med att använda Azure-portalen 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 Environment (isolerad) 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-portalen:

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 Environment (App Service Environment v3) stöder tillgänglighetszoner och vi rekommenderar att du konfigurerar med en konfiguration i tillgänglighetszonen. 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