Strategier för webbplatsuppdatering i Flex Consumption

När du är värd för din app med Azure Functions i planen Flex Consumption 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 konfigurationsinställning (SiteUpdateStrategy) som du kan använda för att styra om funktionsappen upplever stilleståndstid under dessa uppdateringar och hur pågående körningar hanteras.

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

• Återskapa: Startar om alla instanser som körs när du har uppdaterat appen med de senaste ändringarna. Den här metoden kan orsaka korta driftstopp medan instanser återvinns och bevarar standardbeteendet från andra Azure Functions värdplaner.
• Rullande uppdatering: Möjliggör driftsättningar utan driftstopp genom att avveckla och ersätta instanser i omgångar. 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.

• 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ör att optimera prestanda och tillförlitlighet.
• Att ändra strategin är en no-op i GA-regioner: I regioner där löpande uppdateringar är allmänt tillgängliga utlöser inte själva ändringen siteUpdateStrategy.type en webbplatsuppdatering. Du kan uppdatera strategin i förväg på ett säkert sätt och få den att gälla för nästa kod eller konfigurationsdistribution. I regioner där löpande uppdateringar fortfarande lanseras behandlas ändring av strategin som andra konfigurationsändringar och utlöser en platsuppdatering som använder den tidigare strategin. den nya strategin gäller från och med nästa distribution.
• 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 Durable 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. Du kan konfigurera den här inställningen med hjälp av Azure CLI 2.87.0 eller senare, Bicep eller ARM-mallar med API-version 2023-12-01 eller senare.

az functionapp update-strategy config set \
  --name MyFunctionApp \
  --resource-group MyResourceGroup \
  --type RollingUpdate

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

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

Övervaka webbplatsuppdateringar

Det finns ingen inbyggd signal för när uppdateringar av webbplatsen är slutförda. 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: UppskattadPercentComplete procentandel av de ursprungliga instanserna som ersättsOriginalStillActiveCount: Uppskattat antal ursprungliga instanser som fortfarande körsNewCount: 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

Här följer några vanliga frågor om strategier för webbplatsuppdatering.

Hur skiljer sig löpande uppdateringar från distributionsplatser?

Till skillnad från distributionsplatser kräver löpande uppdateringar inte extra 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. En fullständig guide finns i Återställ efter en felaktig driftsättning av Flex Consumption-planen.

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 får körningsfel under den rullande uppdateringen

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 omdistribuera den senaste kända fungerande versionen för att återställa körmiljön. 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