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-abonnement biedt een siteconfiguratie-instelling (SiteUpdateStrategy) die u kunt gebruiken om te bepalen of uw function app uitvaltijd heeft tijdens deze updates en hoe in-progressuitvoeringen worden afgehandeld.

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

• Opnieuw maken: Met Functions worden alle actieve exemplaren opnieuw opgestart nadat u de code hebt vervangen door de nieuwste versie. Deze aanpak kan korte downtime veroorzaken terwijl exemplaren worden gerecycled en het standaardgedrag van andere Azure Functions-hostingplannen behouden blijven.
• Rolling update (preview): 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. Deze lijst wordt onderhouden tijdens de preview-periode en kan veranderen naarmate de functie algemene beschikbaarheid nadert.

• 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 vóór GA om prestaties en betrouwbaarheid te optimaliseren.
• 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 orkestratie kan veroorzaken, gebruik een expliciete orkestratieversiematchstrategie.
• 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. Momenteel ondersteunen alleen Bicep- en ARM-sjablonen met API-versie 2023-12-01 of hoger het wijzigen van deze eigenschap.

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

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

Wijzigingen in de strategie voor site-updates worden van kracht bij de volgende site-update. Als u bijvoorbeeld type wijzigt van Recreate naar RollingUpdate, gebruikt u de hercreëerstrategie voor die update. Alle volgende site-updates maken vervolgens gebruik van rolling updates.

Updates van de site monitoren

Tijdens de openbare preview is er 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 vervangen
   • PercentComplete: Geschat percentage van oorspronkelijke exemplaren die worden vervangen
   • OriginalStillActiveCount: Geschat aantal oorspronkelijke exemplaren dat nog steeds actief is
   • NewCount: Aantal nieuwe instanties die momenteel actief zijn

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

Ik ben gewend aan implementatieslots voor implementaties zonder downtime. Hoe verschillen de rolling updates?

• In tegenstelling tot implementatieslots is voor rolling updates geen extra infrastructuur vereist. 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.

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 rolling update... Wat is er misgegaan?

• 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.
• Als u het probleem wilt oplossen, herplaatst u uw laatst bekende gezonde versie om de runtime te herstellen. Test vervolgens uw voorgestelde wijzigingen in een ontwikkel- of faseringsomgeving voordat u deze opnieuw uitvoert. Bekijk de 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