Strategier för webbplatsuppdatering i Flex Consumption

När du är värd för din app med Azure Functions i Flex Consumption-planen kan du styra hur uppdateringar distribueras till instanser som körs. En platsuppdatering sker när du distribuerar kod, ändrar programinställningar eller ändrar andra konfigurationsegenskaper. Flex Consumption-planen innehåller en platskonfigurationsinställning (SiteUpdateStrategy) som du kan använda för att styra om funktionsappen upplever driftstopp under dessa uppdateringar och hur pågående körningar hanteras.

Flex Consumption-planen stöder för närvarande dessa uppdateringsstrategier:

• Återskapa: Funktioner startar om alla instanser som körs när koden har ersatts med den senaste versionen. Den här metoden kan orsaka korta driftstopp medan instanser återvinns och bevarar standardbeteendet från andra Azure Functions-värdplaner.
• Löpande uppdatering (förhandsversion): Ger distributioner med noll driftstopp genom att tömma och ersätta instanser i batchar. Pågående exekveringar slutförs naturligt utan tvingat avslut.

Jämförelse av strategi

I den här tabellen jämförs de två strategierna för webbplatsuppdatering:

Uppdatera strategibeteenden

I den här tabellen jämförs uppdateringsprocessen för de två strategierna:

I den här tabellen jämförs de viktigaste egenskaperna för de två strategierna:

Överväganden för löpande uppdateringsstrategi

Tänk på dessa aktuella beteenden och begränsningar när du använder den löpande uppdateringsstrategin. Den här listan underhålls under förhandsgranskningsperioden och kan ändras när funktionen närmar sig allmän tillgänglighet (GA).

• Plattformshanterade parametrar: Plattformen styr parametrarna (till exempel batchantal, instanser per batch, antal batchar och avloppsintervall) som avgör löpande uppdateringsbeteenden. Dessa parametrar kan ändras före ga för att optimera prestanda och tillförlitlighet.
• Ingen realtidsövervakning: Det finns för närvarande ingen insyn i hur många instanser som töms, hur många batchar som återstår eller aktuella förloppsprocent.
• Ingen slutförandesignal: Du kan dock övervaka instansloggar för att uppskatta när en uppdatering har slutförts.
• Scenarier med en instans: Appar som körs på en instans upplever kortvarigt stopp som liknar omstart, men pågående körningar slutförs fortfarande.
• Durable Functions: Eftersom blandning av versioner under uppdateringar kan orsaka oväntat beteende i en varaktig orkestrering använder du en explicit orkestreringsversionsmatchningsstrategi.
• Infrastruktur som kod: Distribution av kod- och konfigurationsändringar tillsammans utlöser flera löpande uppdateringar som kan överlappa varandra.
• Bakåtkompatibilitet: Kontrollera att ändringarna fungerar med den tidigare versionen under övergångsperioden för löpande uppdatering.

Konfigurera din uppdateringsstrategi

Du kan ange uppdateringsstrategin för din app med hjälp av SiteUpdateStrategywebbplatsinställningen, som är underordnad functionAppConfig . Som standard är SiteUpdateStrategy.type inställt på Recreate. För närvarande stöder endast Bicep- och ARM-mallar med API-version 2023-12-01 eller senare ändring av den här egenskapen.

functionAppConfig: {
  ...
  siteUpdateStrategy: {
    type: 'RollingUpdate'
  }
  ...
}

"functionAppConfig": {
  ...
  "siteUpdateStrategy": {
    "type": "RollingUpdate"
  }
  ...
}

Ändringar i platsuppdateringsstrategin börjar gälla vid nästa webbplatsuppdatering. Du kan till exempel ändra från till och använda återskapningsstrategin för denna uppdatering. Alla efterföljande webbplatsuppdateringar använder sedan löpande uppdateringar.

Övervaka webbplatsuppdateringar

Under den offentliga förhandsversionen finns det ingen inbyggd slutförandesignal för platsuppdateringar. Du kan använda KQL-frågor i Application Insights som ett metodtips för att uppskatta löpande uppdateringsförlopp.

Övervaka löpande uppdateringsstatus

Dessa KQL-frågor ger en bästa möjliga uppskattning av löpande uppdateringsförlopp genom att spåra instansomsättningen i Application Insights-loggar. Den här metoden har betydande begränsningar och bör inte användas för produktionsautomatisering:

// Rolling update completion check
let deploymentStart = datetime('2025-10-30T19:00:00Z'); // Set to your deployment start time
let checkInterval = 10s; // How often you run this query
let buffer = 30s; // Safety buffer for instance detection
//
// Get original instances (active before deployment)
let originalInstances = 
    traces
    | where timestamp between ((deploymentStart - buffer) .. deploymentStart)
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Get currently active instances
let currentInstances = 
    traces
    | where timestamp >= now() - checkInterval
    | where cloud_RoleInstance != ""
    | summarize by InstanceId = cloud_RoleInstance;
//
// Check completion status
currentInstances
| join kind=leftouter (originalInstances | extend IsOriginal = true) on InstanceId
| extend IsOriginal = isnotnull(IsOriginal)
| summarize 
    OriginalStillActiveInstances = make_set_if(InstanceId, IsOriginal),
    NewInstances = make_set_if(InstanceId, not(IsOriginal)),
    OriginalStillActiveCount = countif(IsOriginal),
    NewCount = countif(not(IsOriginal)),
    TotalOriginal = toscalar(originalInstances | count)
| extend 
    RollingUpdateComplete = iff(OriginalStillActiveCount == 0, "YES", "NO"),
    PercentComplete = round(100.0 * (1.0 - todouble(OriginalStillActiveCount) / todouble(TotalOriginal)), 1)
| project RollingUpdateComplete, PercentComplete, OriginalStillActiveCount, NewCount

Så här använder du den här frågan för uppskattning:

1. Klistra in den här frågan i loggbilden för den Application Insights-resurs som är associerad med din funktionsapp.
2. Ange deploymentStart tidsstämpeln när webbplatsuppdateringen returnerar lyckade resultat.
3. Kör frågan med jämna mellanrum för att uppskatta förloppet. Ange att avsökningsintervallet ska vara minst så länge som den genomsnittliga körningstiden för funktionen och se till att variabeln checkInterval i frågan matchar den här avsökningsfrekvensen.
4. Frågan returnerar ungefärliga värden:
   • RollingUpdateComplete: Bästa uppskattning av om alla ursprungliga instanser ersätts
   • PercentComplete: Uppskattad procentandel av de ursprungliga instanserna som ersätts
   • OriginalStillActiveCount: Uppskattat antal ursprungliga instanser som fortfarande körs
   • NewCount: Antal nya instanser som för närvarande är aktiva

Tänk på dessa begränsningar när du använder följande frågor:

1. Tidslucka: Tiden deploymentStart representerar när webbplatsuppdateringen returnerar framgång, men den faktiska löpande uppdateringen kanske inte startar omedelbart. Under det här gapet etablerar alla utskalningshändelser instanser som kör den ursprungliga versionen. Eftersom frågan endast spårar instanser som är aktiva på deploymentStartövervakar den inte dessa nya ursprungliga versionsinstanser, vilket kan orsaka falska slutförandesignaler.

2. Loggbaserad identifiering: Den här metoden förlitar sig på programloggar för att härleda instanstillstånd i stället för att fråga instansstatus direkt. Instanser kan köras men inte aktivt loggas, vilket leder till falska slutförandesignaler när ursprungliga instanser fortfarande är aktiva men inte avger loggar i fönstret checkInterval .

Rekommendation för produktion: Använd löpande uppdateringar när distributioner utan stilleståndstid är kritiska. Se till att dina distributionspipelines inte behöver vänta på att uppdateringen ska slutföras innan du fortsätter till efterföljande steg. Använd återskapa när du behöver snabbare, mer förutsägbar uppdateringstid och kan tolerera kort stilleståndstid.

Vanliga frågor

Jag är van vid deploymentsplatser för implementation utan driftstopp. Hur skiljer sig löpande uppdateringar åt?

• Till skillnad från distributionsplatser kräver löpande uppdateringar ingen ytterligare infrastruktur. Ange siteUpdateStrategy.type till "RollingUpdate" för distributioner med noll stilleståndstid.
• Löpande uppdateringar bevarar pågående exekveringar, medan distributionsslottar avslutar dem under växlingar. Vissa webbplatsegenskaper och klibbiga inställningar kan inte växlas och kräver att produktionsplatsen ändras direkt.
• Till skillnad från distributionsplatser ger löpande uppdateringar inte en separat miljö där du kan utföra kanariteständringar eller dirigera en procentandel av direkttrafiken till. Om du behöver de här funktionerna kan du använda en plan som stöder distributionsplatser, som Elastic Premium, eller hantera Flex Consumption-appar bakom en trafikhanterare.

Hur återställer jag en webbplatsuppdatering?

• Det finns för närvarande ingen funktion för att återställa en webbplatsuppdatering. Om en återställning krävs initierar du en ny uppdatering av webbplatsen med det tidigare läget för koden eller konfigurationen.

Hur hanteras timerutlösare?

• Timerutlösare behåller sin singleton-natur. När en timerutlöst funktionsapp har markerats för avstängning körs nya timerfunktioner på den senaste versionen.

Jag ser körningsfel under den löpande uppdateringen... vad gick fel?

• Om nya instanser inte startar eller stöter på körningsfel finns problemet troligen i programkoden, beroenden, konfigurationsinställningar eller miljövariabler som du har ändrat.
• Lös problemet genom att återdistribuera den senast kända felfria versionen för att återställa körtiden. Testa sedan de föreslagna ändringarna i en utvecklings- eller mellanlagringsmiljö innan du försöker igen. Granska felloggarna för att identifiera vilken specifik ändring som orsakade problemet.

Nästa steg

• Läs mer om flexförbrukningsplanen
• Läs mer om hur distributioner skiljer sig åt i Flex Consumption
• Lär dig hur du skriver mallar för infrastruktur som kod