Strategieën voor site-updates in Flex Consumption

Wanneer u uw app host met Azure Functions in het Flex Consumption-abonnement, kunt u bepalen hoe updates worden geïmplementeerd voor actieve exemplaren. Er wordt een site-update uitgevoerd wanneer u code implementeert, toepassingsinstellingen wijzigt of andere configuratie-eigenschappen wijzigt. Het Flex Consumption-plan biedt een configuratie-instelling (SiteUpdateStrategy) waarmee u kunt bepalen of uw functie-app tijdens deze updates uitvaltijd ondervindt en hoe lopende uitvoeringen worden afgehandeld.

Het Flex Consumption-abonnement ondersteunt momenteel deze updatestrategieën:

• Opnieuw maken: start alle actieve exemplaren opnieuw nadat u de app hebt bijgewerkt met de meest recente wijzigingen. Deze aanpak kan korte downtime veroorzaken terwijl exemplaren worden gerecycled en het standaardgedrag van andere Azure Functions hostingabonnementen behouden blijft.
• Rolling update: biedt implementaties zonder downtime door exemplaren in batches leeg te maken en te vervangen. Uitvoeringen die worden uitgevoerd, worden op natuurlijke wijze voltooid zonder geforceerde beëindiging.

Strategievergelijking

In deze tabel worden de twee strategieën voor site-updates vergeleken:

Strategiegedragingen bijwerken

In deze tabel wordt het updateproces van de twee strategieën vergeleken:

In deze tabel worden de belangrijkste kenmerken van de twee strategieën vergeleken:

Overwegingen voor een rolling update-strategie

Houd rekening met dit huidige gedrag en deze beperkingen bij het gebruik van de strategie voor rolling updates.

• Platform-beheerde parameters: Het platform bepaalt de parameters (zoals het aantal batches, instanties per batch, het aantal batches en drain-intervallen) die het gedrag van rolling updates bepalen. Deze parameters kunnen veranderen om de prestaties en betrouwbaarheid te optimaliseren.
• Het wijzigen van de strategie is een no-op in GA-regio's: In regio's waar rolling updates algemeen beschikbaar zijn, wordt door het wijzigen siteUpdateStrategy.type niet zelf een site-update geactiveerd. U kunt de strategie van tevoren veilig bijwerken en deze toepassen op uw volgende code- of configuratie-implementatie. In regio's waar rolling updates nog steeds worden geïmplementeerd, wordt het wijzigen van de strategie behandeld als elke andere configuratiewijziging en wordt een site-update geactiveerd die gebruikmaakt van de vorige strategie; de nieuwe strategie is van toepassing vanaf de volgende implementatie.
• Geen realtime-bewaking: er is momenteel geen inzicht in het aantal exemplaren dat leegloopt, hoeveel batches er blijven of de huidige voortgangspercentages.
• Geen voltooiingssignaal: u kunt echter exemplaarlogboeken bewaken om een schatting te maken wanneer een update is voltooid.
• Scenario's met één instantie: apps die op één instantie worden uitgevoerd, hebben een korte downtime die vergelijkbaar is met recreatie, hoewel uitvoeringen die aan de gang zijn nog steeds zullen worden voltooid.
• Durable Functions: Omdat het combineren van versies tijdens updates onverwacht gedrag in een Durable-orchestratie kan veroorzaken, dient u een expliciete orchestratieversie-overeenstemmingsstrategie te gebruiken.
• Infrastructuur als code: als u code- en configuratiewijzigingen implementeert, worden meerdere rolling updates geactiveerd die elkaar kunnen overlappen.
• Compatibiliteit met eerdere versies: zorg ervoor dat uw wijzigingen werken met de vorige versie tijdens de overgangsperiode van de rolling update.

Uw updatestrategie configureren

U kunt de updatestrategie voor uw app instellen met behulp van de SiteUpdateStrategy site-instelling, een onderliggend element van functionAppConfig. Standaard is SiteUpdateStrategy.type ingesteld op Recreate. U kunt deze instelling configureren met behulp van Azure CLI 2.87.0 of hoger, Bicep of ARM-sjablonen met API-versie 2023-12-01 of hoger.

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

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

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

Updates van de site monitoren

Er is geen ingebouwd voltooiingssignaal voor site-updates. U kunt KQL-query's in Application Insights gebruiken als best effort-benadering om de voortgang van rolling updates te schatten.

Voortgang van rolling updates bewaken

Deze KQL-query's bieden een beste poging schatting van de voortgang van golfgewijze updates door het verloop van instanties in de logboeken van Application Insights bij te houden. Deze benadering heeft aanzienlijke beperkingen en mag niet worden gebruikt voor productieautomatisering:

// 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

Deze query gebruiken voor schatting:

1. Plak deze query in het blad Logboeken van de Application Insights-resource die is gekoppeld aan uw functieapp.
2. Stel deploymentStart de tijdstempel in op wanneer de site-update succesvol is.
3. Voer de query periodiek uit om de voortgang te schatten. Stel het polling-interval in op ten minste zolang de gemiddelde uitvoeringstijd van de functie is en zorg ervoor dat de checkInterval variabele in de query overeenkomt met deze pollingfrequentie.
4. De query retourneert geschatte waarden:

RollingUpdateComplete: Beste schatting van of alle oorspronkelijke exemplaren worden vervangenPercentComplete: Geschat percentage van oorspronkelijke exemplaren die worden vervangenOriginalStillActiveCount: Geschat aantal oorspronkelijke exemplaren dat nog steeds wordt uitgevoerdNewCount: Aantal nieuwe exemplaren dat momenteel actief is

Houd rekening met deze beperkingen bij het gebruik van deze query's:

1. Tijdsverschil: de deploymentStart tijd geeft aan wanneer uw site-update een succes retourneert, maar de werkelijke rolling update wordt mogelijk niet onmiddellijk gestart. Tijdens deze periode voorzien scale-out gebeurtenissen instanties waarop de oorspronkelijke versie wordt uitgevoerd. Omdat de query alleen instanties bij deploymentStart bijhoudt die actief zijn, worden deze nieuwe instanties van de oorspronkelijke versie niet bewaakt, wat mogelijk leidt tot valse voltooiingssignalen.
2. Detectie op basis van logboeken: deze benadering is afhankelijk van toepassingslogboeken om de exemplaarstatus af te stellen in plaats van de exemplaarstatus rechtstreeks op te vragen. Exemplaren worden mogelijk uitgevoerd, maar niet actief logboeken registreren, wat tot valse voltooiingssignalen leidt wanneer originele exemplaren nog steeds actief zijn, maar geen logboeken binnen het checkInterval venster hebben verzonden.

Aanbeveling voor productie: gebruik rolling updates wanneer implementaties zonder downtime essentieel zijn. Zorg ervoor dat uw implementatiepijplijnen niet hoeven te wachten op voltooiing van de update voordat u doorgaat met de volgende stappen. Gebruik opnieuw maken wanneer u snellere, voorspelbarere tijdsinstellingen voor updates nodig hebt en korte downtime kan verdragen.

Veelgestelde vragen

Hier volgen enkele veelgestelde vragen over site-updatestrategieën.

Hoe verschillen rolling updates van implementatiesleuven?

In tegenstelling tot deployment slots vereisen rolling updates geen extra infrastructuur. Stel siteUpdateStrategy.type in op "RollingUpdate" voor implementaties zonder downtime.

Rollende updates behouden lopende uitvoeringen, terwijl implementatieslots deze tijdens omwisselingen beëindigen. Bepaalde site-eigenschappen en permanente instellingen kunnen niet worden gewisseld en moeten rechtstreeks in de productiesleuf worden gewijzigd.

In tegenstelling tot implementatieslots bieden rolling updates geen afzonderlijke omgeving voor canary-testwijzigingen of voor het routeren van een percentage van het live verkeer. Als u deze functies nodig hebt, gebruikt u een plan dat ondersteuning biedt voor implementatieslots, zoals Elastic Premium, of beheert u aparte Flex Consumption-apps achter een traffic manager.

Hoe kan ik een site-update terugdraaien?

Er is momenteel geen functie om een site-update terug te draaien. Als een terugdraaiactie nodig is, start u een andere site-update met de vorige status van de code of configuratie. Zie Herstellen na een slechte implementatie van een Flex Consumption-abonnement voor een volledige handleiding.

Hoe worden timertriggers verwerkt?

Timertriggers behouden hun singleton-aard. Zodra een door een timer geactiveerde functie-app is gemarkeerd voor leegmaken, worden nieuwe timerfuncties uitgevoerd op de nieuwste versie.

Ik zie runtimefouten tijdens de gefaseerde update

Als nieuwe exemplaren niet kunnen worden gestart of runtimefouten optreden, is het probleem waarschijnlijk in de toepassingscode, afhankelijkheden, configuratie-instellingen of omgevingsvariabelen die u hebt gewijzigd.

Om het probleem op te lossen, rolt u de meest recente versie waarvan bekend is dat deze goed werkt opnieuw uit om de runtime te herstellen. Test vervolgens uw voorgestelde wijzigingen in een ontwikkel- of faseringsomgeving voordat u deze opnieuw uitvoert. Bekijk foutenlogboeken om te bepalen welke specifieke wijziging het probleem heeft veroorzaakt.

Volgende stappen

• Meer informatie over het Flex Consumption-abonnement
• Meer informatie over hoe implementaties verschillen in Flex Consumption
• Meer informatie over het schrijven van sjablonen voor infrastructuur als code