Dela via


Migrera förbrukningsplanappar till Flex Consumption-planen

Den här artikeln innehåller stegvisa instruktioner för att migrera dina befintliga funktionsappar som finns i förbrukningsplanen i Azure Functions för att i stället använda Flex Consumption-planen.

Hur du migrerar din app till Flex Consumption-planen beror på om din app körs på Linux eller i Windows. Se till att välja ditt operativsystem överst i artikeln.

Tips/Råd

Azure Functions tillhandahåller Azure CLI-kommandon i az functionapp flex-migration som automatiserar de flesta av de steg som krävs för att flytta din Linux-app från Consumption- till Flex Consumption-planen. Den här artikeln innehåller dessa kommandon, som för närvarande endast stöds för appar som körs i Linux.

När du migrerar dina befintliga serverlösa appar kan dina funktioner dra nytta av dessa fördelar med Flex Consumption-planen:

  • Förbättrad prestanda: dina appar drar nytta av förbättrad skalbarhet och alltid tillgängliga instanser för att reducera påverkan av kalla starter.
  • Förbättrade kontroller: finjustera dina funktioner med skalning per funktion och samtidighetsinställningar.
  • Utökat nätverk: Med integrering av virtuella nätverk och privata slutpunkter kan du köra dina funktioner i både offentliga och privata nätverk.
  • Framtida plattformsinvesteringar: som den bästa serverlösa värdplanen görs nuvarande och framtida investeringar på Flex Consumption först för plattformsstabilitet, prestanda och funktioner.

Flex Consumption-planen är det rekommenderade serverlösa värdalternativet för dina funktioner framöver. För mer information, se förmåner med Flex Consumption Plan. En detaljerad jämförelse mellan värdplaner finns i Värdalternativ för Azure Functions.

Överväganden

Tänk på följande innan du påbörjar en migrering:

  • Om du kör funktionsappar för förbrukningsplan i Azure Government-regioner läser du nu den här vägledningen för att förbereda migreringen tills Flex Consumption har aktiverats i Azure Government.

  • På grund av de betydande konfigurations- och beteendeskillnaderna mellan de två planerna kan du inte flytta en befintlig förbrukningsplanapp till Flex Consumption-planen. I migreringsprocessen skapar du i stället en ny Flex Consumption-planapp som motsvarar din aktuella app. Den här nya appen körs i samma resursgrupp och med samma beroenden som din aktuella app.

  • Du bör prioritera migreringen av dina appar som körs i en förbrukningsplan i Linux.

  • Den här artikeln förutsätter att du har en allmän förståelse för Functions-begrepp och -arkitekturer och är bekant med funktioner i dina appar som migreras. Sådana begrepp omfattar utlösare och bindningar, autentisering och nätverksanpassning.

  • Den här artikeln visar hur du både utvärderar den aktuella appen och distribuerar din nya Flex Consumption-planapp med hjälp av antingen Azure-portalen eller Azure CLI. Om din aktuella appdistribution definieras med hjälp av infrastruktur som kod (IaC) kan du vanligtvis följa samma steg. Du kan utföra samma åtgärder direkt i ARM-mallar eller Bicep-filer med följande resursspecifika överväganden:

Förutsättningar

  • Åtkomst till Azure-prenumerationen som innehåller en eller flera funktionsappar som ska migreras. Kontot som används för att köra Azure CLI-kommandon måste kunna:

    • Skapa och hantera funktionsappar och värdplaner för App Service.
    • Tilldela roller till hanterade identiteter.
    • Skapa och hantera lagringskonton.
    • Skapa och hantera Application Insights-resurser.
    • Få åtkomst till alla beroende resurser i din app, till exempel Azure Key Vault, Azure Service Bus eller Azure Event Hubs.

    Att tilldelas rollen Ägare eller Deltagare i resursgruppen ger vanligtvis tillräckliga behörigheter.

  • Azure CLI, version v2.77.0 eller en senare version. Skript testas med Azure CLI i Azure Cloud Shell.

  • Resursdiagramtillägget som du kan installera med hjälp az extension add av kommandot :

    az extension add --name resource-graph
    
  • Verktygetjq, som används för att arbeta med JSON-utdata.

Identifiera potentiella appar som kan migreras

Använd de här stegen för att skapa en lista över de funktionsappar som du behöver migrera. Anteckna deras namn, resursgrupper, platser och körstaplar i den här listan. Du kan sedan upprepa stegen i den här guiden för varje app som du bestämmer dig för att migrera till Flex Consumption-planen.

Hur funktionsappens information underhålls beror på om din app körs på Linux eller Windows.

För Linux-förbrukningsappar använder du det nya az functionapp flex-migration list kommandot för att identifiera appar som är berättigade till migrering:

az functionapp flex-migration list

Det här kommandot söker automatiskt igenom din prenumeration och returnerar två matriser:

  • eligible_apps: Linux-förbrukningsappar som kan migreras till Flex Consumption. Dessa appar är kompatibla med Flex Consumption.
  • ineligible_apps: Appar som inte kan migreras, tillsammans med de specifika orsakerna till varför. Orsakerna till inkompatibiliteten måste ses över och åtgärdas innan du fortsätter.

Utdata innehåller appnamn, resursgrupp, plats och körningsstack för varje app, tillsammans med berättigandestatus och information om migreringsberedskap.

Använd det här az graph query kommandot om du vill visa en lista över alla funktionsappar i din prenumeration som körs i en förbrukningsplan:

az graph query -q "resources | where subscriptionId == '$(az account show --query id -o tsv)' \
   | where type == 'microsoft.web/sites' | where ['kind'] == 'functionapp' | where properties.sku == 'Dynamic' \
   | project name, location, resourceGroup" \
   --query data --output table

Det här kommandot genererar en tabell med appnamnet, platsen och resursgruppen för alla förbrukningsappar som körs i Windows i den aktuella prenumerationen.

Du uppmanas att installera resursdiagramtillägget om det inte redan är installerat.

Utvärdera din befintliga app

Innan du migrerar till planen för Flex Consumption bör du utföra dessa kontroller för att säkerställa att din funktionsapp kan migreras framgångsrikt.

Bekräfta regionkompatibilitet

Bekräfta att Flex Consumption-planen för närvarande stöds i samma region som den förbrukningsplanapp som du tänker migrera.

Bekräftad:az functionapp flex-migration list När kommandoutdata har din app i eligible_apps listan stöds Flex Consumption-planen i samma region som används av din aktuella Linux-förbrukningsapp. I det här fallet kan du fortsätta att verifiera språkstackens kompatibilitet.

Åtgärd krävs:az functionapp flex-migration list När utdata från kommandot har din app i ineligible_apps-listan, visas ett felmeddelande som anger The site '<name>' is not in a region supported in Flex Consumption. Please see the list regions supported in Flex Consumption by running az functionapp list-flexconsumption-locations. I det här fallet stöds inte Flex Consumption-planen ännu i den region som används av din aktuella Linux-förbrukningsapp.

Använd det här az functionapp list-flexconsumption-locations kommandot om du vill visa en lista över alla regioner där Flex Consumption-planen är tillgänglig:

az functionapp list-flexconsumption-locations --query "sort_by(@, &name)[].{Region:name}" -o table

Det här kommandot genererar en tabell med Azure-regioner där Flex Consumption-planen för närvarande stöds.

Om din region inte stöds för närvarande och du fortfarande väljer att migrera din funktionsapp måste appen köras i en annan region där Flex Consumption-planen stöds. Att köra appen i en annan region än andra anslutna tjänster kan dock medföra extra svarstid. Kontrollera att den nya regionen kan uppfylla programmets prestandakrav innan du slutför migreringen.

Verifiera språkstackens kompatibilitet

Flex Consumption-planer har ännu inte stöd för alla Functions-språkstackar. Den här tabellen anger vilka språkstackar som stöds för närvarande:

Stackinställning Stacknamn Understödd
dotnet-isolated .NET (isolerad arbetsmodell) ✅ Ja
node JavaScript/TypeScript ✅ Ja
java Java ✅ Ja
python python ✅ Ja
powershell PowerShell ✅ Ja
dotnet .NET (processmodell) ❌ Nej
custom Anpassade hanterare ❌ Nej

Bekräftad:az functionapp flex-migration list Om kommandot inkluderade din app i eligible_apps listan använder din Linux-förbrukningsapp redan en språkstack som stöds av Flex Consumption och du kan fortsätta att verifiera stackversionens kompatibilitet.

Åtgärd krävs:az functionapp flex-migration list Om kommandot inkluderade din app i ineligible_apps listan med ett felmeddelande om att Runtime '<name>' not supported for function apps on the Flex Consumption plan., kör din Linux-förbrukningsapp inte en körning som stöds av Flex Consumption ännu.

Om din funktionsapp använder en körningsstack som inte stöds:

Verifiera kompatibilitet för stackversioner

Innan du migrerar måste du se till att appens körningsstackversion stöds när den körs i en Flex Consumption-plan i den aktuella regionen.

Bekräftad:az functionapp flex-migration list Om kommandot inkluderade din app i eligible_apps listan använder din Linux-förbrukningsapp redan en språkstackversion som stöds av Flex Consumption och du kan fortsätta att verifiera användningen av distributionsplatser.

Åtgärd krävs:az functionapp flex-migration list Om kommandot inkluderade din app i ineligible_apps listan med ett felmeddelande om att Invalid version {0} for runtime {1} for function apps on the Flex Consumption plan. Supported versions for runtime {1} are {2}., kör din Linux-förbrukningsapp inte en körning som stöds av Flex Consumption ännu.

Använd det här az functionapp list-flexconsumption-runtimes-kommandot för att verifiera Flex Consumption-planens stöd för språkstackens version i en specifik region.

az functionapp list-flexconsumption-runtimes --location <REGION> --runtime <LANGUAGE_STACK> --query '[].{version:version}' -o tsv

I det här exemplet ersätter du <REGION> med din aktuella region och <LANGUAGE_STACK> med något av följande värden:

Språkstacken Värde
C# (isolerad arbetsmodell) dotnet-isolated
Java java
JavaScript node
PowerShell powershell
Python python
TypeScript node

Det här kommandot visar alla versioner av den angivna språkstacken som stöds av Flex Consumption-planen i din region.

Om din funktionsapp använder en språkstackversion som inte stöds måste du först uppgradera appkoden till en version som stöds innan du migrerar till Flex Consumption-planen.

Kontrollera användningen av distributionsplatser

Appar för förbrukningsplaner kan ha ett driftslot definierat. Mer information finns i Distributionsfack för Azure Functions. För närvarande stöder dock inte Flex Consumption-planen distributionsslotar. Innan du migrerar måste du avgöra om din app har ett distributionsfack. I så fall måste du definiera en strategi för hur du hanterar din app utan distributionsplatser när den körs i en Flex Consumption-plan.

Bekräftad: När din aktuella app har distributionsfack aktiverade az functionapp flex-migration list visar kommandot din funktionsapp i eligible_apps listan utan varning. Fortsätt att verifiera användningen av certifikat.

Åtgärd krävs: Din aktuella app har distributionsfack aktiverade, az functionapp flex-migration list kommandot visar funktionsappen eligible_apps i listan men lägger till en varning som anger: The site '<name>' has slots configured. This will not block migration, but please note that slots are not supported in Flex Consumption.

Använd det här az functionapp deployment slot list kommandot om du vill visa en lista över distributionsplatser som definierats i funktionsappen:

az functionapp deployment slot list --name <APP_NAME> --resource-group <RESOURCE_GROUP> --output table

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Om kommandot returnerar en post har din app distributionsplatser aktiverade.

Om din funktionsapp för närvarande använder distributionsplatser kan du för närvarande inte återskapa den här funktionen i Flex Consumption-planen. Innan du migrerar bör du:

  • Överväg att göra om programmet för att använda separata funktionsappar. På så sätt kan du utveckla, testa och distribuera funktionskoden till en andra icke-produktionsapplikation utan att behöva använda utrymmen, eller
  • Migrera ny kod eller funktioner från distributionsplatsen till huvudplatsen (produktion).

Verifiera användningen av certifikat

TLS-certifikat (Transport Layer Security), som tidigare kallades SSL-certifikat (Secure Sockets Layer), används för att skydda Internetanslutningar. TSL-/SSL-certifikat, som omfattar hanterade certifikat, BYOC (Bring Your Own Certificates) eller offentliga nyckelcertifikat, stöds för närvarande inte av Flex Consumption-planen.

Bekräftad:az functionapp flex-migration list Om kommandot inkluderade din app i eligible_apps listan använder din Linux-förbrukningsapp redan inte certifikat och du kan fortsätta att verifiera dina Blob Storage-utlösare.

Åtgärd krävs:az functionapp flex-migration list Om kommandot inkluderade din app i ineligible_apps listan med ett felmeddelande om The site '<name>' is using TSL/SSL certificates. TSL/SSL certificates are not supported in Flex Consumption. eller The site '<name>' has the WEBSITE_LOAD_CERTIFICATES app setting configured. Certificate loading is not supported in Flex Consumption., är din Linux-förbrukningsapp ännu inte kompatibel med Flex Consumption.

az webapp config ssl list Använd kommandot för att visa alla TSL/SSL-certifikat som är tillgängliga för funktionsappen:

az webapp config ssl list --resource-group <RESOURCE_GROUP>  

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn. Om det här kommandot genererar utdata använder din app troligen certifikat.

Om din app för närvarande förlitar sig på TSL/SSL-certifikat bör du inte fortsätta med migreringen förrän stöd för certifikat har lagts till i Flex Consumption-planen.

Verifiera dina Blob Storage-utlösare

För närvarande stöder Flex Consumption-planen endast händelsebaserade utlösare för Azure Blob Storage, som definieras med inställningen SourceEventGrid. Blob Storage-utlösare som använder containeravsökning och använder en Source inställning för LogsAndContainerScan stöds inte i Flex Consumption. Eftersom containeravsökning är standard måste du avgöra om någon av dina Blob Storage-utlösare använder standardinställningen LogsAndContainerScan för källan. Mer information finns i Utlösare för en blobcontainer.

Bekräftad:az functionapp flex-migration list Om kommandot inkluderade din app i eligible_apps listan använder din Linux-förbrukningsapp redan inte en bloblagringsutlösare med EventGrid som källa. Du kan fortsätta att överväga beroende tjänster.

Åtgärd krävs:az functionapp flex-migration list Om kommandot inkluderade din app i ineligible_apps listan med ett felmeddelande om att The site '<name>' has blob storage trigger(s) that don't use Event Grid as the source: <list> Flex Consumption only supports Event Grid-based blob triggers. Please convert these triggers to use Event Grid or replace them with Event Grid triggers before migration.din Linux-förbrukningsapp ännu inte är kompatibel med Flex Consumption.

Använd det här kommandot [az functionapp function list] för att avgöra om din app har bloblagringsutlösare som inte använder Event Grid som källa:

az functionapp function list  --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
  --query "[?config.bindings[0].type=='blobTrigger' && config.bindings[0].source!='EventGrid'].{Function:name,TriggerType:config.bindings[0].type,Source:config.bindings[0].source}" \
  --output table

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Om kommandot returnerar rader finns det minst en trigger som använder container polling i din funktionsapp.

Om din app har bloblagringsutlösare som inte har en Event Grid-källa måste du ändra till en Event Grid-källa innan du migrerar till Flex Consumption-planen.

De grundläggande stegen för att ändra en befintlig Blob Storage-utlösare till en Event Grid-källa är:

  1. Lägg till eller uppdatera source egenskapen i bloblagringsutlösarens definition till EventGrid och distribuera om appen.

  2. Skapa slutpunkts-URL:en i funktionsappen som används av händelseprenumerationen.

  3. Skapa en händelseprenumeration på bloblagringscontainern.

Mer information finns i Självstudie: Utlösa Azure Functions på blobcontainrar med hjälp av en händelseprenumeration.

Överväg beroende tjänster

Eftersom Azure Functions är en beräkningstjänst måste du överväga effekten av migreringen på data och tjänster både uppströms och nedströms i appen.

Dataskyddsstrategier

Här följer några strategier för att skydda både överordnade och underordnade data under migreringen:

  • Idempotens: Se till att dina funktioner på ett säkert sätt kan bearbeta samma meddelande flera gånger utan negativa biverkningar. Mer information finns i Designa Azure Functions för identiska indata.
  • Loggning och övervakning: Aktivera detaljerad loggning i båda apparna under migreringen för att spåra meddelandebearbetning. Mer information finns i Övervaka körningar i Azure Functions.
  • Kontrollpunkter: För direktuppspelningsutlösare, till exempel Event Hubs-utlösaren, implementerar du rätt kontrollpunktsbeteenden för att spåra bearbetningspositionen. Mer information finns i Tillförlitlig händelsebearbetning i Azure Functions.
  • Parallell bearbetning: Överväg att tillfälligt köra båda apparna samtidigt under övergången. Se till att noggrant övervaka och verifiera hur data bearbetas från den överordnade tjänsten. Mer information finns i Aktivt-aktivt mönster för icke-HTTPS-utlösarfunktioner.
  • Gradvis snabbhet: För system med stora volymer bör du överväga att implementera en gradvis snabbhet genom att omdirigera delar av trafiken till den nya appen. Du kan hantera routning av begäranden uppströms från dina appar med hjälp av tjänster som Azure API Management eller Azure Application Gateway.

Åtgärder efter utlösartyp

Du bör planera åtgärder för att skydda data för de specifika funktionsutlösare som du kan ha i din app.

Utlösare Risk för data Strategi
Azure Blob Storage Högt Skapa en separat container för den händelsebaserade utlösaren i den nya appen.
När den nya appen körs växlar du klienter för att använda den nya containern.
Tillåt att den ursprungliga containern bearbetas helt innan den gamla appen stoppas.
Azure Cosmos DB Högt Skapa en dedikerad lånecontainer specifikt för den nya appen.
Ange den här nya lånecontainern som konfiguration i leaseCollectionName den nya appen.
Kräver att dina funktioner är idempotent eller att du måste kunna hantera resultatet av bearbetning av dubbletter av ändringsflöde.
Ange konfigurationen StartFromBeginning till false i den nya appen för att undvika att bearbeta hela feeden.
Azure Event Grid Medel Återskapa samma händelseprenumeration i den nya appen.
Kräver att dina funktioner är idempotent eller att du måste kunna hantera resultatet av duplicerad händelsebearbetning.
Azure Event Hubs Medel Skapa en ny konsumentgrupp som ska användas av den nya appen. Mer information finns i Migreringsstrategier för Event Grid-utlösare.
Azure Service Bus Högt Skapa ett nytt ämne eller en ny kö för användning av den nya appen.
Uppdatera avsändare och klienter för att använda det nya ämnet eller kön.
När det ursprungliga ämnet är tomt stänger du av den gamla appen.
Azure Storage-kö Högt Skapa en ny kö för användning av den nya appen.
Uppdatera avsändare och klienter för att använda den nya kön.
När den ursprungliga kön är tom stänger du av den gamla appen.
HTTP Låg Kom ihåg att byta klienter och andra appar eller tjänster så att de riktar in sig på de nya HTTP-slutpunkterna efter migreringen.
Timer Låg Under övergången måste du justera tidsschemat mellan de två apparna för att undvika samtidiga körningar från båda apparna.
Inaktivera timer-aktiveraren i den gamla appen efter att den nya appen har körts framgångsrikt.

Starta migreringen för Linux

Kommandot az functionapp flex-migration start samlar automatiskt in programkonfigurationsinformation och skapar en ny Flex Consumption-app med samma konfigurationer som källappen. Använd kommandot som du ser i det här exemplet:

az functionapp flex-migration start \
    --source-name <SOURCE_APP_NAME> \
    --source-resource-group <SOURCE_RESOURCE_GROUP> \
    --name <NEW_APP_NAME> \
    --resource-group <RESOURCE_GROUP>

I det här exemplet ersätter du dessa platshållare med de angivna värdena:

Platshållare Värde
<SOURCE_APP_NAME> Namnet på din ursprungliga app.
<SOURCE_RESOURCE_GROUP> Resursgruppen för den ursprungliga appen.
<NEW_APP_NAME> Namnet på den nya appen.
<RESOURCE_GROUP> Resursgruppen för den nya appen.

Kommandot az functionapp flex-migration start utför följande grundläggande uppgifter:

  • Utvärderar källappen för kompatibilitet med Flex Consumption-hostingplanen.
  • Skapar en funktionsapp i Flex Consumption-planen.
  • Migrerar de flesta konfigurationer, inklusive appinställningar, identitetstilldelningar, lagringsmonteringar, CORS-inställningar, anpassade domäner och åtkomstbegränsningar.

Kommandoalternativ

Migreringskommandot stöder flera alternativ för att anpassa migreringen:

Option Beskrivning
--storage-account Ange ett annat lagringskonto för den nya appen
--maximum-instance-count Ange det maximala antalet instanser för skalning
--skip-access-restrictions Hoppa över migrering av IP-åtkomstbegränsningar
--skip-cors Hoppa över migrering av CORS-inställningar
--skip-hostnames Hoppa över migrering av anpassade domäner
--skip-managed-identities Hoppa över migrering av hanterade identitetskonfigurationer
--skip-storage-mount Hoppa över att migrera konfigurationer för lagringsmontering

För fullständiga kommandoalternativ använder du az functionapp flex-migration start --help.

När du framgångsrikt har slutfört att köra az functionapp flex-migration start, fortsätter du till Hämta koddistributionspaketet.

Förberedelser inför migrering

Innan du fortsätter med migreringen måste du samla in viktig information om och resurser som används av din app för förbrukningsplan för att underlätta en smidig övergång till Flex Consumption-planen.

Du bör slutföra dessa uppgifter innan du migrerar din app för att köras i en Flex Consumption-plan:

Samla in appinställningar

Om du planerar att använda samma källor för utlösare och bindningar, och andra inställningar från appinställningar, måste du först anteckna de aktuella appinställningarna i din nuvarande förbrukningsapplikation.

Använd det här az functionapp config appsettings list kommandot för att returnera ett app_settings objekt som innehåller den befintliga appinställningen som JSON:

app_settings=$(az functionapp config appsettings list --name `<APP_NAME>` --resource-group `<RESOURCE_GROUP>`)
echo $app_settings

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet.

Försiktighet

Appinställningar innehåller ofta nycklar och andra delade hemligheter. Lagra alltid programinställningar på ett säkert sätt, helst krypterade. För bättre säkerhet bör du använda Microsoft Entra ID-autentisering med hanterade identiteter i den nya Flex Consumption Plan-appen i stället för delade hemligheter.

Samla in programkonfigurationer

Det finns andra appkonfigurationer som inte finns i appinställningarna. Du bör också samla in dessa konfigurationer från din befintliga app så att du kan vara säker på att återskapa dem korrekt i den nya appen.

Granska de här inställningarna. Om någon av dem finns i den aktuella appen måste du bestämma om de också måste återskapas i den nya Flex Consumption-planappen:

Konfiguration Inställning Kommentar
CORS-inställningar cors Avgör eventuella befintliga CORS-inställningar (cross-origin resource sharing) som dina klienter kan kräva.
Anpassade domäner Om din app för närvarande använder en annan domän än *.azurewebsites.netmåste du ersätta den här anpassade domänmappningen med en mappning till den nya appen.
HTTP-version http20Enabled Avgör om HTTP 2.0 krävs av din app.
Endast HTTPS httpsOnly Avgör om TSL/SSL krävs för att få åtkomst till din app.
Inkommande klientcertifikat clientCertEnabled
clientCertMode
clientCertExclusionPaths
Anger krav för klientbegäranden som använder certifikat för autentisering.
Maximal utskalningsgräns WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT Anger gränsen för skalade ut instanser. Det maximala standardvärdet är 200. Det här värdet finns i appinställningarna, men i en Flex Consumption-planapp läggs det i stället till som en webbplatsinställning (maximumInstanceCount).
Lägsta inkommande TLS-version minTlsVersion Anger en lägsta version av TLS som krävs av din app.
Minsta inkommande TLS-chiffer minTlsCipherSuite Anger ett minsta TLS-chifferkrav för din app.
Monterade Azure Files-delningar azureStorageAccounts Avgör om det finns några uttryckligen monterade filresurser i din applikation (endast Linux).
Autentiseringsuppgifter för grundläggande SCM-autentisering scm.allow Avgör om publiceringswebbplatsenscm är aktiverad. Även om det inte rekommenderas för säkerhet kräver vissa publiceringsmetoder det.

Använd det här skriptet för att hämta relevanta programkonfigurationer för din befintliga app:

# Set the app and resource group names
appName=<APP_NAME>
rgName=<RESOURCE_GROUP>

echo "Getting commonly used site settings..."
az functionapp config show --name $appName --resource-group $rgName \
    --query "{http20Enabled:http20Enabled, httpsOnly:httpsOnly, minTlsVersion:minTlsVersion, \
    minTlsCipherSuite:minTlsCipherSuite, clientCertEnabled:clientCertEnabled, \
    clientCertMode:clientCertMode, clientCertExclusionPaths:clientCertExclusionPaths}"

echo "Checking for SCM basic publishing credentials policies..."
az resource show --resource-group $rgName --name scm --namespace Microsoft.Web \
    --resource-type basicPublishingCredentialsPolicies --parent sites/$appName --query properties

echo "Checking for the maximum scale-out limit configuration..."
az functionapp config appsettings list --name $appName --resource-group $rgName \
    --query "[?name=='WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT'].value" -o tsv

echo "Checking for any file share mount configurations..."
az webapp config storage-account list --name $appName --resource-group $rgName

echo "Checking for any custom domains..."
az functionapp config hostname list --webapp-name $appName --resource-group $rgName --query "[?contains(name, 'azurewebsites.net')==\`false\`]" --output table

echo "Checking for any CORS settings..."
az functionapp cors show --name $appName --resource-group $rgName 

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Om någon av webbplatsinställningarna eller kontrollerna returnerar värden som inte är null ska du anteckna dem.

Identifiera hanterade identiteter och rollbaserad åtkomst

Innan du migrerar bör du dokumentera om din app förlitar sig på den systemtilldelade hanterade identiteten eller användartilldelade hanterade identiteter. Du måste också fastställa de rollbaserade behörigheter för åtkomstkontroll (RBAC) som beviljats dessa identiteter. Du måste återskapa den systemtilldelade hanterade identiteten och eventuella rolltilldelningar i din nya app. Du bör kunna återanvända dina användartilldelade hanterade identiteter i din nya app.

Det här skriptet söker efter både den systemtilldelade hanterade identiteten och eventuella användartilldelade hanterade identiteter som är associerade med din app:

appName=<APP_NAME>
rgName=<RESOURCE_GROUP>

echo "Checking for a system-assigned managed identity..."
systemUserId=$(az functionapp identity show --name $appName --resource-group $rgName --query "principalId" -o tsv) 

if [[ -n "$systemUserId" ]]; then
echo "System-assigned identity principal ID: $systemUserId"
echo "Checking for role assignments..."
az role assignment list --assignee $systemUserId --all
else
  echo "No system-assigned identity found."
fi

echo "Checking for user-assigned managed identities..."
userIdentities=$(az functionapp identity show --name $appName --resource-group $rgName --query 'userAssignedIdentities' -o json)
if [[ "$userIdentities" != "{}" && "$userIdentities" != "null" ]]; then
  echo "$userIdentities" | jq -c 'to_entries[]' | while read -r identity; do
    echo "User-assigned identity name: $(echo "$identity" | jq -r '.key' | sed 's|.*/userAssignedIdentities/||')"
	echo "Checking for role assignments..."
    az role assignment list --assignee $(echo "$identity" | jq -r '.value.principalId') --all --output json
    echo
  done
else
  echo "No user-assigned identities found."
fi

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Anteckna alla identiteter och deras rolltilldelningar.

Identifiera inbyggda autentiseringsinställningar

Innan du migrerar till Flex Consumption bör du samla in information om inbyggda autentiseringskonfigurationer. Om du vill att din app ska använda samma klientautentiseringsbeteenden måste du återskapa dem i den nya appen. Mer information finns i Autentisering och auktorisering i Azure Functions.

Var särskilt uppmärksam på omdirigerings-URI:er, tillåtna externa omdirigeringar och tokeninställningar för att säkerställa en smidig övergång för autentiserade användare.

Använd det här az webapp auth show kommandot för att avgöra om inbyggd autentisering har konfigurerats i funktionsappen:

az webapp auth show --name <APP_NAME> --resource-group <RESOURCE_GROUP>

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Granska utdata för att avgöra om autentisering är aktiverat och vilka identitetsprovidrar som har konfigurerats.

Du bör återskapa den här inställningen i den nya appen efter migreringen så att dina klienter kan behålla åtkomsten med hjälp av den provider som de föredrar.

Granska begränsningar för inkommande åtkomst

Det är möjligt att ange begränsningar för inkommande åtkomst för appar i en förbrukningsplan. Du kanske vill behålla de här begränsningarna i din nya app. För varje definierad begränsning bör du samla in följande egenskaper:

  • IP-adresser eller CIDR-intervall
  • Prioritetsvärden
  • Åtgärdstyp (Tillåt/Neka)
  • Namn på reglerna

Det här az functionapp config access-restriction show kommandot returnerar en lista över befintliga IP-baserade åtkomstbegränsningar:

az functionapp config access-restriction show --name <APP_NAME> --resource-group <RESOURCE_GROUP>

I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet.

När du kör i Flex Consumption-planen kan du återskapa dessa inkommande IP-baserade begränsningar. Du kan skydda din app ytterligare genom att implementera andra nätverksbegränsningar, till exempel integrering av virtuella nätverk och inkommande privata slutpunkter. Mer information finns i Integrering av virtuellt nätverk.

Hämta koddistributionspaketet

För att kunna distribuera om din app måste du ha antingen projektets källfiler eller distributionspaketet. Helst bevaras dina projektfiler i källkontrollen så att du enkelt kan distribuera om funktionskoden till din nya app. Om du har dina källkodsfiler kan du hoppa över det här avsnittet och fortsätta att samla in prestandamått (valfritt).

Om du inte längre har åtkomst till projektkällans filer kan du ladda ned det aktuella distributionspaketet från den befintliga förbrukningsplanappen i Azure. Platsen för distributionspaketet beror på om du kör på Linux eller Windows.

Förbrukningsplanappar i Linux underhåller zip-paketfilen för distribution på någon av dessa platser:

  • En Azure Blob Storage-container med namnet scm-releases i standardvärdens lagringskonto (AzureWebJobsStorage). Den här containern är standarddistributionskällan för en förbrukningsplanapp i Linux.

  • Om din app har en WEBSITE_RUN_FROM_PACKAGE inställning som är en URL finns paketet på en externt tillgänglig plats som du underhåller. Ett externt paket ska finnas i en bloblagringscontainer med begränsad åtkomst. Mer information finns i Url för externt paket.

Tips/Råd

Om ditt lagringskonto endast är begränsat till åtkomst till hanterad identitet kan du behöva ge ditt Azure-konto läsåtkomst till lagringscontainern genom att lägga till det i Storage Blob Data Reader rollen.

Distributionspaketet komprimeras med formatet squashfs . Om du vill se vad som finns i paketet måste du använda verktyg som kan dekomprimera det här formatet.

Följ dessa steg för att ladda ned distributionspaketet från din aktuella app:

  1. Använd det här az functionapp config appsettings list kommandot för att hämta appinställningen om det WEBSITE_RUN_FROM_PACKAGE finns:

    az functionapp config appsettings list --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --query "[?name=='WEBSITE_RUN_FROM_PACKAGE'].value" -o tsv
    

    I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Om det här kommandot returnerar en URL kan du ladda ned distributionspaketfilen från den fjärrplatsen och gå vidare till nästa avsnitt.

  2. Om värdet WEBSITE_RUN_FROM_PACKAGE är 1 eller ingenting använder du det här skriptet för att hämta distributionspaketet för den befintliga appen:

    appName=<APP_NAME>
    rgName=<RESOURCE_GROUP>
    
    echo "Getting the storage account connection string from app settings..."
    storageConnection=$(az functionapp config appsettings list --name $appName --resource-group $rgName \
             --query "[?name=='AzureWebJobsStorage'].value" -o tsv)
    
    echo "Getting the package name..."
    packageName=$(az storage blob list --connection-string $storageConnection --container-name scm-releases \
    --query "[0].name" -o tsv)
    
    echo "Download the package? $packageName? (Y to proceed, any other key to exit)"
    read -r answer
    if [[ "$answer" == "Y" || "$answer" == "y" ]]; then
       echo "Proceeding with download..."
       az storage blob download --connection-string $storageConnection --container-name scm-releases \
    --name $packageName --file $packageName
    else
       echo "Exiting script."
       exit 0
    fi
    

    <RESOURCE_GROUP> Ersätt igen och <APP_NAME> med resursgruppens namn och appnamn. Paketet .zip filen laddas ned till katalogen som du körde kommandot från.

Platsen för projektkällans filer beror på appinställningen WEBSITE_RUN_FROM_PACKAGE enligt följande:

WEBSITE_RUN_FROM_PACKAGE värde Källfilsplats
1 Filerna finns i ett zip-paket som lagras i Azure Files-resursen för lagringskontot som definieras av WEBSITE_CONTENTAZUREFILECONNECTIONSTRING inställningen. Namnet på filresursen definieras av inställningen WEBSITE_CONTENTSHARE.
En slutpunkts-URL Filerna finns i ett zip-paket på en externt tillgänglig plats som du underhåller. Ett externt paket ska finnas i en bloblagringscontainer med begränsad åtkomst. Mer information finns i Url för externt paket.
  1. Använd det här az functionapp config appsettings list kommandot för att hämta appinställningen om det WEBSITE_RUN_FROM_PACKAGE finns:

    az functionapp config appsettings list --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --query "[?name=='WEBSITE_RUN_FROM_PACKAGE'].value" -o tsv
    

    I det här exemplet ersätter du <RESOURCE_GROUP> med resursgruppens namn och <APP_NAME> med appnamnet. Om det här kommandot returnerar en URL kan du ladda ned distributionspaketfilen från den fjärrplatsen och gå vidare till nästa avsnitt.

  2. Om värdet WEBSITE_RUN_FROM_PACKAGE är 1 eller ingenting använder du det här skriptet för att hämta distributionspaketet för den befintliga appen:

    appName=<APP_NAME>
    rgName=<RESOURCE_GROUP>
    
    echo "Getting the storage account connection string and file share from app settings..."
    json=$(az functionapp config appsettings list --name $appName --resource-group $rgName \
        --query "[?name=='WEBSITE_CONTENTAZUREFILECONNECTIONSTRING' || name=='WEBSITE_CONTENTSHARE'].value" -o json)
    
    storageConnection=$(echo "$json" | jq -r '.[0]')
    fileShare=$(echo "$json" | jq -r '.[1]')
    
    echo "Getting the package name..."
    packageName=$(az storage file list --share-name $fileShare --connection-string $storageConnection \
      --path "data/SitePackages" --query "[?ends_with(name, '.zip')] | sort_by(@, &properties.lastModified)[-1].name" \
      -o tsv) 
    
    echo "Download the package? $packageName? (Y to proceed, any other key to exit)"
    read -r answer
    if [[ "$answer" == "Y" || "$answer" == "y" ]]; then
        echo "Proceeding with download..."
        az storage file download --connection-string $storageConnection --share-name $fileShare \
    	--path "data/SitePackages/$packageName"
    else
        echo "Exiting script."
        exit 0
    fi
    

    <RESOURCE_GROUP> Ersätt igen och <APP_NAME> med resursgruppens namn och appnamn. Paketet .zip filen laddas ned till katalogen som du körde kommandot från.

Samla in prestandamått (valfritt)

Om du planerar att validera prestandaförbättringar i din app baserat på migreringen till Flex Consumption-planen bör du (valfritt) samla in prestandamåtten för din aktuella plan. Sedan kan du jämföra dem med samma riktmärken för din app som körs i en Flex Consumption-plan för jämförelse.

Tips/Råd

Jämför alltid prestanda under liknande förhållanden, till exempel tid på dagen, veckodag och klientbelastning. Försök att köra de två prestandatesten så nära varandra som möjligt.

Här följer några riktmärken att tänka på för dina strukturerade prestandatester:

Föreslaget riktmärke Kommentar
Kallstart Mät tiden från den första begäran till det första svaret efter en inaktiv period.
Genomströmning Mät maximalt antal begäranden per sekund med hjälp av verktyg för belastningstestning för att avgöra hur appen hanterar samtidiga begäranden.
Fördröjning Spåra svarstiderna P50, P95och P99 under olika belastningsförhållanden. Du kan övervaka dessa mått i Application Insights.

Du kan använda den här Kusto-frågan för att granska de föreslagna latenssvarstiderna i Application Insights.

requests
| where timestamp > ago(1d)
| summarize percentiles(duration, 50, 95, 99) by bin(timestamp, 1h)
| render timechart

Migreringsanvisningar

Migreringen av dina funktioner från en app för förbrukningsplan till en Flex Consumption Plan-app följer dessa huvudsteg:

Kontrollera att Flex Consumption-appen har skapats och konfigurerats

När du har kört kommandot az functionapp flex-migration start bör du kontrollera att din nya Flex Consumption-app har skapats och konfigurerats korrekt. Här följer några steg för att verifiera migreringsresultatet:

  1. Kontrollera att den nya appen finns och körs:

    az functionapp show --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> \
         --query "{name:name, kind:kind, sku:properties.sku}" --output table
    
  2. Granska migrerade appinställningar:

    az functionapp config appsettings list --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> \
         --output table
    

    Jämför de här inställningarna med källappen för att säkerställa att kritiska konfigurationer har överförts.

  3. Kontrollera konfigurationen av hanterad identitet:

    az functionapp identity show --name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP>
    
  4. Kontrollera att alla anpassade domäner har migrerats:

    az functionapp config hostname list --webapp-name <NEW_APP_NAME> --resource-group <RESOURCE_GROUP> \
         --output table
    

Granska migreringssammanfattning

Det automatiserade migreringskommandot bör ha överfört de flesta konfigurationer. Du bör dock manuellt kontrollera att dessa objekt inte har migrerats och att de kan behöva konfigureras manuellt:

  • Certifikat: TSL/SSL-certifikat stöds inte i Flex Consumption ännu
  • Utplaceringsplatser: Stöds inte i Flex-förbrukning
  • Inbyggda autentiseringsinställningar: Dessa måste konfigureras om manuellt
  • CORS-inställningar: Kan behöva manuell verifiering beroende på din konfiguration

Om kritiska inställningar saknas eller är felaktiga kan du konfigurera dem manuellt med hjälp av stegen som beskrivs i avsnitten i Windows-migreringsprocessen i den här artikeln.

Slutlig översyn av planen

Innan du fortsätter med migreringsprocessen bör du utföra följande sista förberedande steg:

  • Granska all insamlad information: Gå igenom alla anteckningar, konfigurationsinformation och programinställningar som du dokumenterade i föregående utvärderings- och förmigrationsavsnitt. Om något är oklart kör du Azure CLI-kommandona igen eller hämtar informationen från portalen.

  • Definiera din migreringsplan: Baserat på dina resultat skapar du en checklista för migreringen som visar:

    • Alla inställningar som behöver särskild uppmärksamhet
    • Utlösare och bindningar eller andra beroenden som kan påverkas under migreringen
    • Teststrategi för validering efter migrering
    • Tillbakagångsplan vid oväntade problem
  • Planering av stilleståndstid: Överväg när du ska stoppa den ursprungliga funktionsappen för att undvika både dataförlust och duplicerad bearbetning av händelser och hur detta kan påverka dina användare eller underordnade system. I vissa fall kan du behöva inaktivera specifika funktioner innan du stoppar hela appen.

En noggrann slutlig granskning hjälper till att säkerställa en smidigare migreringsprocess och minimerar risken för att förbise viktiga konfigurationer.

Skapa en app i Flex Consumption-planen

Det finns olika sätt att skapa en funktionsapp i Flex Consumption-planen tillsammans med andra nödvändiga Azure-resurser:

Skapa-alternativ Referensartiklar
Azure CLI (kommandoradsgränssnittet för Azure) Skapa en Flex Consumption-app
Azure-portalen Skapa en funktionsapp i Azure-portalen
Infrastruktur som kod ARM-template
azd
Biceps
Terraform
Visual Studio Code Visual Studio Code-driftsättning
Visual Studio Visual Studio-implementering

Tips/Råd

När det är möjligt bör du använda Microsoft Entra-ID för autentisering i stället för anslutningssträngar som innehåller delade nycklar. Att använda hanterade identiteter är en metod som förbättrar säkerheten genom att eliminera behovet av att lagra delade hemligheter direkt i programinställningarna. Om din ursprungliga app använde anslutningssträngar är Flex Consumption-planen utformad för att stödja hanterade identiteter. De flesta av dessa länkar visar hur du aktiverar hanterade identiteter i funktionsappen.

Tillämpa migrerade appinställningar i den nya appen

Innan du distribuerar koden måste du konfigurera den nya appen med relevanta appinställningar för Flex Consumption Plan från din ursprungliga funktionsapp.

Viktigt!

Alla appinställningar för förbrukningsplan stöds inte när de körs i en Flex Consumption-plan. Mer information finns i Utfasningar av flexförbrukningsplan.

Kör det här skriptet som utför följande uppgifter:

  1. Hämtar appinställningar från den gamla appen och ignorerar inställningar som inte gäller i en Flex Consumption-plan eller som redan finns i den nya appen.
  2. Skriver de insamlade inställningarna lokalt till en tillfällig fil.
  3. Tillämpar inställningar från filen på din nya app.
  4. Tar bort den tillfälliga filen.
sourceAppName=<SOURCE_APP_NAME>
destAppName=<DESTINATION_APP_NAME>
rgName=<RESOURCE_GROUP>

echo "Getting app settings from the old app..."
app_settings=$(az functionapp config appsettings list --name $sourceAppName --resource-group $rgName)

# Filter out settings that don't apply to Flex Consumption apps or that will already have been created
filtered_settings=$(echo "$app_settings" | jq 'map(select(
  (.name | ascii_downcase) != "website_use_placeholder_dotnetisolated" and
  (.name | ascii_downcase | startswith("azurewebjobsstorage") | not) and
  (.name | ascii_downcase) != "website_mount_enabled" and
  (.name | ascii_downcase) != "enable_oryx_build" and
  (.name | ascii_downcase) != "functions_extension_version" and
  (.name | ascii_downcase) != "functions_worker_runtime" and
  (.name | ascii_downcase) != "functions_worker_runtime_version" and
  (.name | ascii_downcase) != "functions_max_http_concurrency" and
  (.name | ascii_downcase) != "functions_worker_process_count" and
  (.name | ascii_downcase) != "functions_worker_dynamic_concurrency_enabled" and
  (.name | ascii_downcase) != "scm_do_build_during_deployment" and
  (.name | ascii_downcase) != "website_contentazurefileconnectionstring" and
  (.name | ascii_downcase) != "website_contentovervnet" and
  (.name | ascii_downcase) != "website_contentshare" and
  (.name | ascii_downcase) != "website_dns_server" and
  (.name | ascii_downcase) != "website_max_dynamic_application_scale_out" and
  (.name | ascii_downcase) != "website_node_default_version" and
  (.name | ascii_downcase) != "website_run_from_package" and
  (.name | ascii_downcase) != "website_skip_contentshare_validation" and
  (.name | ascii_downcase) != "website_vnet_route_all" and
  (.name | ascii_downcase) != "applicationinsights_connection_string"
))')

echo "Settings to migrate..."
echo "$filtered_settings"

echo "Writing settings to a local a local file (app_settings_filtered.json)..."
echo "$filtered_settings" > app_settings_filtered.json

echo "Applying settings to the new app..."
output=$(az functionapp config appsettings set --name $destAppName --resource-group $rgName --settings @app_settings_filtered.json)

echo "Deleting the temporary settings file..."
rm -rf app_settings_filtered.json  

echo "Current app settings in the new app..."
az functionapp config appsettings list --name $destAppName --resource-group $rgName 

I det här exemplet ersätter <RESOURCE_GROUP>du , <SOURCE_APP_NAME>och <DEST_APP_NAME> med resursgruppens namn respektive de gamla nya appnamnen. Det här skriptet förutsätter att båda apparna finns i samma resursgrupp.

Tillämpa andra appkonfigurationer

Hitta listan över andra appkonfigurationer från din gamla app som du samlade in under förflyttningen och ange dem även i den nya appen.

I det här skriptet anger du värdet för alla konfigurationsuppsättningar i den ursprungliga appen och kommenterar ut alla kommandon för alla konfigurationer som inte har angetts (null):

appName=<APP_NAME>
rgName=<RESOURCE_GROUP>
http20Setting=<YOUR_HTTP_20_SETTING>
minTlsVersion=<YOUR_TLS_VERSION>
minTlsCipher=<YOUR_TLS_CIPHER>
httpsOnly=<YOUR_HTTPS_ONLY_SETTING>
certEnabled=<CLIENT_CERT_ENABLED>
certMode=<YOUR_CLIENT_CERT_MODE>
certExPaths=<CERT_EXCLUSION_PATHS>
scmAllowBasicAuth=<ALLOW_SCM_BASIC_AUTH>

# Apply HTTP version and minimum TLS settings
az functionapp config set --name $appName --resource-group $rgName --http20-enabled $http20Setting  
az functionapp config set --name $appName --resource-group $rgName --min-tls-version $minTlsVersion

# Apply the HTTPS-only setting
az functionapp update --name $appName --resource-group $rgName --set HttpsOnly=$httpsOnly

# Apply incoming client cert settings
az functionapp update --name $appName --resource-group $rgName --set clientCertEnabled=$certEnabled
az functionapp update --name $appName --resource-group $rgName --set clientCertMode=$certMode
az functionapp update --name $appName --resource-group $rgName --set clientCertExclusionPaths=$certExPaths

# Apply the TLS cipher suite setting
az functionapp update --name $appName --resource-group $rgName --set minTlsCipherSuite=$minTlsCipher

# Apply the allow scm basic auth configuration
az resource update --resource-group $rgName --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
	--parent sites/$appName --set properties.allow=$scmAllowBasicAuth

I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp. Ersätt också platshållarna för alla variabeldefinitioner för befintliga inställningar som du vill återskapa i den nya appen och kommentera ut eventuella null inställningar.

Konfigurera skalnings- och samtidighetsinställningar

Flex Consumption-planen implementerar skalning per funktion, där varje funktion i din app kan skalas separat baserat på dess arbetsbelastning. Skalning är också mer nära relaterat till samtidighetsinställningar, vilka används för att fatta beslut om skalning baserat på nuvarande samtidiga körningar. Mer information finns i Flex Consumption Plan-artikeln under avsnitten Skalning per funktion och Samtidighet.

Överväg att använda samtidighetsinställningar först om du vill att den nya appen ska skalas på samma sätt som den ursprungliga appen. Om du anger högre samtidighetsvärden kan färre instanser skapas för att hantera samma belastning.

Om du har angett en anpassad utskalningsgräns i den ursprungliga appen kan du även tillämpa den på den nya appen. Annars kan du gå vidare till nästa avsnitt.

Det maximala standardantalet för instanser är 100 och det måste anges till ett värde på 40 eller högre.

Använd det här az functionapp scale config set kommandot för att ange maximal utskalning.

az functionapp scale config set --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
    --maximum-instance-count <MAX_SCALE_SETTING>

I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp. Ersätt <MAX_SCALE_SETTING> med det maximala skalningsvärdet som du ställer in.

Konfigurera anpassade domäner och CORS-åtkomst

Om din ursprungliga app hade några bundna anpassade domäner eller cors-inställningar definierade återskapar du dem i den nya appen. Mer information om anpassade domäner finns i Konfigurera en befintlig anpassad domän i Azure App Service.

  1. Använd det här az functionapp config hostname add kommandot för att koppla om anpassade domänmappningar till din app:

    az functionapp config hostname add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --hostname <CUSTOM_DOMAIN>
    

    I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp. Ersätt <CUSTOM_DOMAIN> med ditt anpassade domännamn.

  2. Använd det här az functionapp cors add kommandot för att ersätta alla CORS-inställningar:

    az functionapp cors add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --allowed-origins <ALLOWED_ORIGIN_1> <ALLOWED_ORIGIN_2> <ALLOWED_ORIGIN_N>
    

    I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp. Ersätt <ALLOWED_ORIGIN_*> med ditt tillåtna ursprung.

Konfigurera hanterade identiteter och tilldela roller

Hur du konfigurerar hanterade identiteter i din nya app beror på vilken typ av hanterad identitet:

Hanterad identitetstyp Skapa identitet Rolltilldelningar
Användartilldelad Valfritt Du kan fortsätta att använda samma användartilldelade hanterade identiteter med den nya appen. Du måste omtilldela dessa identiteter till din Flex Consumption-app och kontrollera att de fortfarande har rätt rolltilldelningar i fjärrtjänster. Om du väljer att skapa nya identiteter för den nya appen måste du tilldela samma roller som de befintliga identiteterna.
Systemtilldelad Ja Eftersom varje funktionsapp har en egen systemtilldelad hanterad identitet måste du aktivera den systemtilldelade hanterade identiteten i den nya appen och tilldela om samma roller som i den ursprungliga appen.

Att återskapa rolltilldelningarna på rätt sätt är nyckeln till att säkerställa att funktionsappen har samma åtkomst till Azure-resurser efter migreringen.

Tips/Råd

Om din ursprungliga app använde anslutningssträngar eller andra delade hemligheter för autentisering är detta ett utmärkt tillfälle att förbättra appens säkerhet genom att växla till att använda Microsoft Entra ID-autentisering med hanterade identiteter. Mer information finns i Självstudie: Skapa en funktionsapp som ansluter till Azure-tjänster med identiteter i stället för hemligheter.

  1. Använd det här az functionapp identity assign kommandot för att aktivera den systemtilldelade hanterade identiteten i din nya app:

    az functionapp identity assign --name <APP_NAME> --resource-group <RESOURCE_GROUP>
    

    I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp.

  2. Använd det här skriptet för att hämta huvud-ID:t för den systemtilldelade identiteten och lägga till den i de roller som krävs:

    # Get the principal ID of the system identity
    principalId=$(az functionapp identity show --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
        --query principalId -o tsv)
    
    # Assign a role in a specific resource (scope) to the system identity
    az role assignment create --assignee $principalId --role "<ROLE_NAME>" --scope "<RESOURCE_ID>"
    

    I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp. Ersätt <ROLE_NAME> och <RESOURCE_ID> med rollnamnet och den specifika resurs som du hämtade från den ursprungliga appen.

  3. Upprepa de tidigare kommandona för varje roll som krävs av den nya appen.

Konfigurera begränsningar för nätverksåtkomst

Om din ursprungliga app hade ip-baserade begränsningar för inkommande åtkomst kan du återskapa någon av samma regler för inkommande åtkomst som du vill behålla i den nya appen.

Tips/Råd

Flex Consumption-planen har fullt stöd för integrering av virtuella nätverk. På grund av detta har du också möjlighet att använda inkommande privata slutpunkter efter migreringen. Mer information finns i Privata slutpunkter.

Använd det här az functionapp config access-restriction add kommandot för varje IP-åtkomstbegränsning som du vill replikera i den nya appen:

az functionapp config access-restriction add --name <APP_NAME> --resource-group <RESOURCE_GROUP> \
  --rule-name <RULE_NAME> --action Deny --ip-address <IP_ADDRESS> --priority <PRIORITY>

I det här exemplet ersätter du dessa platshållare med värdena från din ursprungliga app:

Platshållare Värde
<APP_NAME> Namnet på funktionsappen.
<RESOURCE_GROUP> Din resursgrupp.
<RULE_NAME> Eget namn för IP-regeln.
<Priority> Prioritet för uteslutningen.
<IP_Address> IP-adressen som ska undantas.

Kör det här kommandot för varje dokumenterad IP-begränsning från den ursprungliga appen.

Aktivera övervakning

Innan du startar din nya app i Flex Consumption-planen kontrollerar du att Application Insights är aktiverat. Att ha Application Insights konfigurerat hjälper dig att felsöka eventuella problem som kan uppstå under koddistribution och start.

Implementera en omfattande övervakningsstrategi som omfattar appmått, loggar och kostnader. Genom att använda en sådan strategi kan du verifiera migreringens framgång, identifiera eventuella problem snabbt och optimera prestanda och kostnader för din nya app.

Om du planerar att jämföra den här nya appen med din aktuella app ska du se till att ditt schema även samlar in de prestandamått som krävs för jämförelse. Mer information finns i Konfigurera övervakning.

Konfigurera inbyggd autentisering

Om din ursprungliga app använde inbyggd klientautentisering (kallas ibland Easy Auth) bör du återskapa den i den nya appen. Om du planerar att återanvända samma klientregistrering måste du ange den nya appens autentiserade slutpunkter i autentiseringsprovidern.

Baserat på den information du samlade in tidigare använder az webapp auth update du kommandot för att återskapa varje inbyggd autentiseringsregistrering som krävs av din app.

Distribuera din appkod till den nya Flex Consumption-appen

När din nya Flex Consumption-planapp är helt konfigurerad baserat på inställningarna från den ursprungliga appen är det dags att distribuera koden till de nya appresurserna i Azure.

Försiktighet

Efter distributionen börjar utlösare i din nya app omedelbart bearbeta data från anslutna tjänster. För att minimera duplicerade data och förhindra dataförlust vid start av den nya appen och stänga av den ursprungliga appen bör du granska de strategier som du definierade i åtgärder efter utlösartyp.

Functions tillhandahåller flera sätt att distribuera din kod, antingen från kodprojektet eller som ett färdigt distributionspaket.

Tips/Råd

Om din projektkod underhålls på en källkodslagringsplats är det dags att konfigurera en pipeline för kontinuerlig distribution. Med kontinuerlig distribution kan du automatiskt distribuera programuppdateringar baserat på ändringar i en ansluten lagringsplats.

Du bör uppdatera dina befintliga distributionsarbetsflöden för att distribuera källkoden till din nya app:

Du kan också skapa ett nytt arbetsflöde för kontinuerlig distribution för din nya app. Mer information finns i Kontinuerlig distribution för Azure Functions

Åtgärder efter migreringen

Efter en lyckad migrering bör du utföra följande uppföljningsuppgifter:

Verifiera grundläggande funktioner

  1. Kontrollera att den nya appen körs i en Flex Consumption-plan:

    Använd det här az functionapp show kommandot för att visa detaljer om värdplanen:

    az functionapp show --name <APP_NAME> --resource-group <RESOURCE_GROUP> --query "serverFarmId"
    

    I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp.

  2. Använd en HTTP-klient för att anropa minst en HTTP-utlösarslutpunkt i din nya app för att se till att den svarar som förväntat.

Samla in prestandamått

När din nya app körs kan du köra samma prestandamått som du samlade in från din ursprungliga app, till exempel:

Föreslaget riktmärke Kommentar
Kallstart Mät tiden från den första begäran till det första svaret efter en inaktiv period.
Genomströmning Mät maximalt antal begäranden per sekund med hjälp av verktyg för belastningstestning för att avgöra hur appen hanterar samtidiga begäranden.
Fördröjning Spåra svarstiderna P50, P95och P99 under olika belastningsförhållanden. Du kan övervaka dessa mått i Application Insights.

Du kan använda den här Kusto-frågan för att granska de föreslagna latenssvarstiderna i Application Insights.

requests
| where timestamp > ago(1d)
| summarize percentiles(duration, 50, 95, 99) by bin(timestamp, 1h)
| render timechart

Anmärkning

Mått för flexförbrukningsplan skiljer sig från mått för förbrukningsplan. När du jämför prestanda före och efter migreringen bör du tänka på att du måste använda olika mått för att spåra liknande prestandaegenskaper. Mer information finns i Konfigurera övervakning.

Skapa anpassade instrumentpaneler

Med Azure Monitor-mått och Application Insights kan du skapa instrumentpaneler i Azure-portalen som visar diagram från både plattformsmått och körningsloggar och analys.

Överväg att konfigurera instrumentpaneler och aviseringar för dina nyckelmått i Azure-portalen. Mer information finns i Övervaka din app i Azure.

Förfina planinställningar

Faktiska prestandaförbättringar och kostnadskonsekvenser för migreringen kan variera beroende på dina appspecifika arbetsbelastningar och konfiguration. Flex Consumption-planen innehåller flera inställningar som du kan justera för att förfina appens prestanda. Du kanske vill göra justeringar för att bättre matcha beteendet för den ursprungliga appen eller för att balansera kostnader jämfört med prestanda. För mer information, se Finjustera din app i Flex Consumption-artikeln.

Ta bort den ursprungliga appen (valfritt)

När du har testat din nya Funktionsapp för Flex Consumption noggrant och verifierat att allt fungerar som förväntat kanske du vill rensa resurser för att undvika onödiga kostnader. Även om utlösare i den ursprungliga appen förmodligen redan är inaktiverade kan du vänta några dagar eller till och med veckor innan du tar bort den ursprungliga appen helt. Den här fördröjningen, som beror på programmets användningsmönster, ser till att alla scenarier, inklusive ovanliga sådana, testas korrekt. Först när du är nöjd med migreringsresultatet bör du fortsätta att ta bort den ursprungliga funktionsappen.

Viktigt!

Den här åtgärden tar bort den ursprungliga funktionsappen. Förbrukningsplanen förblir intakt om andra appar använder den. Innan du fortsätter kontrollerar du att du har migrerat alla funktioner till den nya Flex Consumption-appen, verifierat att ingen trafik dirigeras till den ursprungliga appen och säkerhetskopierat alla relevanta loggar, konfigurationer eller data som kan behövas för referens.

az functionapp delete Använd kommandot för att ta bort den ursprungliga funktionsappen:

az functionapp delete --name <ORIGINAL_APP_NAME> --resource-group <RESOURCE_GROUP>

I det här exemplet ersätter du <RESOURCE_GROUP> och <APP_NAME> med namnen på din resursgrupp respektive funktionsapp.

Felsöknings- och återställningsstrategier

Trots noggrann planering kan migreringsproblem uppstå. Så här hanterar du potentiella problem under migreringen:

Problematik Lösning
Problem med kallstartsprestanda • Granska samtidighetsinställningar
• Sök efter saknade beroenden
Bindningar saknas • Verifiera tilläggspaket
• Uppdatera bindningskonfigurationer
Behörighetsfel • Kontrollera identitetstilldelningar och rollbehörigheter
Problem med nätverksanslutning • Verifiera åtkomstbegränsningar och nätverksinställningar
Saknade programinsikter • Återskapa Application Insights-anslutningen
Det går inte att starta appen Se Allmänna felsökningssteg
Utlösare bearbetar inte händelser Se Allmänna felsökningssteg

Om du har problem med att migrera en produktionsapp kanske du vill återställa migreringen till den ursprungliga appen medan du felsöker.

Allmänna felsökningssteg

Använd de här stegen för fall där den nya appen inte startar eller funktionsutlösare inte bearbetar händelser:

  1. På den nya appsidan i Azure-portalen väljer du Diagnostisera och lösa problem i den vänstra rutan på appsidan. Välj Tillgänglighet och prestanda och granska detektorn för Function App nedetid eller rapporterade fel. Mer information finns i Översikt över Azure Functions-diagnostik.

  2. På appsidan väljer du Övervaka>Application Insights>Visa Application Insights-data och sedan Undersök>fel och sök efter eventuella felhändelser.

  3. VäljÖvervakningsloggar> och kör den här Kusto-frågan för att kontrollera om det finns fel i tabellerna:

    traces
        | where severityLevel == 3
        | where cloud_RoleName == "<APP_NAME>"
        | where timestamp > ago(1d)
        | project timestamp, message, operation_Name, customDimensions
        | order by timestamp desc
    

    Ersätt med namnet på den nya appen i de här frågorna <APP_NAME> . De här frågorna söker efter fel under den senaste dagen (where timestamp > ago(1d)).

  4. På appsidan väljer du Inställningar>Miljövariabler och kontrollerar att alla viktiga programinställningar har överförts korrekt. Leta efter inaktuella inställningar som kan ha migrerats felaktigt eller stavfel eller felaktiga anslutningssträngar. Kontrollera standardanslutningen för värdlagring.

  5. Välj Inställningar>Identitet och dubbelkolla att de förväntade identiteterna finns och att de har tilldelats till rätt roller.

  6. I koden kontrollerar du att alla bindningskonfigurationer är korrekta, med särskild uppmärksamhet på namn på anslutningssträngar, lagringskö och containernamn samt inställningar för konsumentgrupper i Händelsehubbar-utlösare.

Tillbakarullningssteg för kritiska produktionsappar

Om du inte kan felsöka framgångsrikt kanske du vill återgå till att använda din ursprungliga app medan du fortsätter att felsöka.

  1. Om den ursprungliga appen stoppades startar du om den:

    Använd det här az functionapp start kommandot för att starta om den ursprungliga funktionsappen:

    az functionapp delete --name <ORIGINAL_APP_NAME> --resource-group <RESOURCE_GROUP>
    
  2. Om du har skapat nya köer/ämnen/containrar kontrollerar du att klienter omdirigeras tillbaka till de ursprungliga resurserna.

  3. Om du har ändrat DNS eller anpassade domäner återställer du ändringarna så att de pekar på den ursprungliga appen.

Att ge återkoppling

Om du stöter på problem med migreringen med hjälp av den här artikeln eller vill ge annan feedback om den här vägledningen kan du använda någon av dessa metoder för att få hjälp eller ge din feedback:

- Få hjälp på Microsoft Q&A
-Skapa ett problem på Azure Functions-lagringsplatsen
- Ge produktfeedback
- Skapa ett supportärende