Dela via

Flytta funktionsappen till en annan Azure-region

  • Artikel

Den här artikeln beskriver hur du flyttar en Azure Functions-värdbaserad funktionsapp 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.

De Azure-resurser som är värdar för din funktionsapp är regionspecifika och kan inte flyttas mellan regioner. I stället måste du skapa en kopia av dina befintliga funktionsappresurser i målregionen och sedan distribuera om funktionskoden till den nya appen.

Du kan flytta samma resurser till en annan resursgrupp eller prenumeration, så länge de finns kvar i samma region. Mer information finns i Flytta App Service-resurser till en ny resursgrupp eller prenumeration.

Förutsättningar

  • Kontrollera att målregionen stöder Azure Functions och alla relaterade tjänster vars resurser du vill flytta.
  • Se till att du har behörighet att skapa de resurser som behövs i den nya regionen.

Förbereda

Identifiera alla funktionsappresurser som används i källregionen, vilket potentiellt omfattar:

När du förbereder för att flytta din app till en ny region finns det några delar av arkitekturen som kräver särskild hänsyn och planering.

Funktionsappens namn

Funktionsappnamn måste vara globalt unika för alla Azure-appar. Det innebär att den nya funktionsappen inte kan ha samma namn och URL som den ursprungliga. Detta gäller även när du använder en anpassad DNS, eftersom den underliggande fortfarande <APP_NAME>.azurewebsites.net måste vara unik. Du kan behöva uppdatera alla klienter som ansluter till HTTP-slutpunkter i funktionsappen. Dessa klienter måste använda den nya URL:en när de gör begäranden.

Källkod

Vi rekommenderar att du underhåller källkoden på en kodlagringsplats av något slag, eller på en containerlagringsplats om den körs i en Linux-container. Om du använder kontinuerlig distribution planerar du att byta lagringsplats eller containerdistributionsanslutning till den nya funktionsappens adress. Om du av någon anledning inte längre har källkoden kan du ladda ned det paket som körs från den ursprungliga funktionsappen. Vi rekommenderar att du lagrar dina källfiler på en kodlagringsplats och använder kontinuerlig distribution för uppdateringar.

Standardlagringskonto

Functions-värden kräver ett Azure Storage-konto. Mer information finns i Krav för lagringskonto. För bästa prestanda bör din funktionsapp använda ett lagringskonto i samma region. När du skapar en ny app med ett nytt lagringskonto i din nya region får appen en ny uppsättning funktionsåtkomstnycklar och tillståndet för alla utlösare (till exempel timerutlösare) återställs.

Sparad lokal lagring

Funktionskörningar är avsedda att vara tillståndslösa. Men vi hindrar dig inte från att skriva data till det lokala filsystemet. Det går att lagra data som genereras och används av ditt program på den %HOME%\site virtuella enheten, men dessa data bör inte vara tillståndsrelaterade. Om ditt scenario kräver att du underhåller tillståndet mellan funktionskörningar bör du i stället överväga att använda Durable Functions.

Om ditt program bevarar data till appens delade lagringssökväg måste du planera hur du ska hantera det tillståndet under en resursflytt. Tänk på att för dedikerade (App Service)-planappar är resursen en del av webbplatsen. För förbruknings- och Premium-abonnemang är resursen som standard en Azure Files-resurs i standardlagringskontot. Appar som körs på Linux kanske använder en explicit monterad resurs för sparad lagring.

Anslutna tjänster

Dina funktioner kan ansluta till Azure Services och andra resurser med antingen en tjänst-SDK eller utlösare och bindningar. Alla anslutna tjänster kan påverkas negativt när appen flyttas till en ny region. Om svarstiden eller hela frågan är problem kan du överväga att flytta alla anslutna tjänster till den nya regionen också. Information om hur du flyttar dessa resurser mellan regioner finns i dokumentationen för respektive tjänster. När du flyttar en app med anslutna tjänster kanske du vill överväga en strategi för haveriberedskap mellan regioner och affärskontinuitet under flytten.

Ändringar av anslutna tjänster kan kräva att du uppdaterar de värden som lagras i programinställningarna, som används för att ansluta till dessa tjänster.

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.

Anpassade domäner

Om din funktionsapp använder en anpassad domän binder du den förebyggande till målappen. Verifiera och aktivera domänen i målappen. Efter flytten måste du mappa om domännamnet.

Virtuella nätverk

Med Azure Functions kan du integrera dina appar med virtuella nätverksresurser och även köra dem i ett virtuellt nätverk. Mer information finns i Nätverksalternativ för Azure Functions. När du flyttar till en ny region måste du först flytta eller återskapa alla nödvändiga virtuella nätverk och undernätsresurser innan du distribuerar appen. Detta inkluderar att flytta eller återskapa privata slutpunkter och tjänstslutpunkter.

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.

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.

Access keys

Functions använder åtkomstnycklar för att göra det svårare att komma åt HTTP-slutpunkter i funktionsappen. Dessa nycklar underhålls krypterade i standardlagringskontot. När du skapar en ny app i den nya regionen skapas en ny uppsättning nycklar. Du måste uppdatera alla befintliga klienter som använder åtkomstnycklar för att använda de nya nycklarna i den nya regionen. Även om du bör använda de nya nycklarna är det möjligt att återskapa de gamla nycklarna i den nya appen. Mer information finns i Arbeta med åtkomstnycklar i Azure Functions.

Driftstopp

Om minimal stilleståndstid är ett krav bör du överväga att köra funktionsappen i båda regionerna, vilket rekommenderas för att implementera en arkitektur för haveriberedskap. Vilken arkitektur du implementerar beror på utlösartyperna i funktionsappen. Mer information finns i Tillförlitlighet i Azure Functions.

Bestående funktioner

Med tillägget Durable Functions kan du definiera orkestreringar, där tillståndet underhålls i funktionskörningarna med tillståndskänsliga entiteter. Helst bör du tillåta att orkestreringarna körs innan du migrerar din Durable Functions-app, särskilt när du planerar att byta till ett nytt lagringskonto i den nya regionen. När du migrerar dina Durable Functions-appar bör du överväga att använda någon av dessa strategier för haveriberedskap och geo-distribution.

Omlokalisera

Om du återskapar din funktionsapp i en ny region måste du först återskapa Azure-infrastrukturen för en App Service-plan, funktionsappinstans och relaterade resurser, till exempel virtuella nätverk, identiteter och platser. Du måste också återansluta eller återskapa de Azure-resurser som krävs av appen i den nya regionen. Dessa resurser kan innehålla standardkontot för Azure Storage och Application Insights-instansen.

Sedan kan du paketera och distribuera om den faktiska programkällan eller containern till funktionsappen som körs i den nya regionen.

Återskapa din Azure-infrastruktur

Det finns flera sätt att skapa en funktionsapp och relaterade resurser i Azure i målregionen:

  • Distributionsmallar: Om du ursprungligen distribuerade funktionsappen med hjälp av IaC-filer (infrastruktur som kod) (Bicep, ARM-mallar eller Terraform) kan du uppdatera de tidigare distributionerna för att rikta in dig på den nya regionen och använda dem för att återskapa resurser i den nya regionen. Om du inte längre har dessa distributionsfiler kan du alltid ladda ned en ARM-mall för din befintliga resursgrupp från Azure Portal.
  • Azure CLI/PowerShell-skript: Om du ursprungligen distribuerade din funktionsapp med hjälp av Azure CLI- eller Azure PowerShell-skript kan du uppdatera dessa skript för att i stället rikta in dig på den nya regionen och köra dem igen. Om du inte längre har dessa skript kan du också ladda ned en ARM-mall för din befintliga resursgrupp från Azure Portal.
  • Azure Portal: Om du skapade funktionsappen i portalen ursprungligen eller inte känner dig bekväm med att använda skript eller IaC-filer kan du återskapa allt i portalen. Se till att använda samma värdplan, språkkörning och språkversion som din ursprungliga app.

Granska konfigurerade resurser

Granska och konfigurera de resurser som identifierades i steget Förbered ovan i målregionen om de inte konfigurerades under distributionen. Om du använder kontinuerlig distribution med hanterad identitetsautentisering kontrollerar du att de identiteter och rollmappningar som krävs finns i den nya funktionsappen.

Distribuera om källkoden

Nu när du har infrastrukturen på plats kan du paketera om och distribuera om källkoden till funktionsappen. Det här är ett bra tillfälle att flytta källkoden eller containeravbildningen till en lagringsplats och aktivera kontinuerlig distribution från lagringsplatsen.

Du kan också använda andra publiceringsmetoder som stöds av Functions. De flesta verktygsbaserade publiceringar kräver att du aktiverar grundläggande autentisering på scm slutpunkten, vilket inte rekommenderas för produktionsappar.

Omlokaliseringsöverväganden

Rensa

När flytten är klar tar du bort funktionsappen och värdplanen från källregionen. Du betalar för funktionsappar i Premium- eller Dedikerade planer, även om själva appen inte körs. Om du har återskapat andra tjänster i den nya regionen bör du också ta bort de äldre tjänsterna när du är säker på att de inte längre behövs.

I Azure Architecture Center finns exempel på funktionsappar som körs i flera regioner som en del av mer avancerade och geo-redundanta lösningsarkitekturer.