Stratégies de mise à jour de site dans Flex Consumption

Lorsque vous hébergez votre application avec Azure Functions dans le plan Flex Consumption, vous pouvez contrôler la façon dont les mises à jour sont déployées sur des instances en cours d’exécution. Une mise à jour de site se produit chaque fois que vous déployez du code, modifiez les paramètres de l’application ou modifiez d’autres propriétés de configuration. Le plan Flex Consumption fournit un paramètre de configuration de site (SiteUpdateStrategy) que vous pouvez utiliser pour contrôler si votre application de fonction subit un temps d’arrêt pendant ces mises à jour et comment les exécutions en cours sont gérées.

Le plan Flex Consumption prend actuellement en charge ces stratégies de mise à jour :

• Recréer : Functions redémarre toutes les instances en cours d’exécution après avoir remplacé votre code par la dernière version. Cette approche peut entraîner un bref temps d’arrêt pendant que les instances sont recyclées et conserve le comportement par défaut d’autres plans d’hébergement Azure Functions.
• Mise à jour continue (préversion) : permet des déploiements sans interruption en désactivant progressivement et en remplaçant les instances par lots. Les exécutions en cours se terminent naturellement sans arrêt forcé.

Comparaison de stratégies

Ce tableau compare les deux stratégies de mise à jour de site :

Mettre à jour les comportements de stratégie

Ce tableau compare le processus de mise à jour des deux stratégies :

Ce tableau compare les principales caractéristiques des deux stratégies :

Considérations relatives à la stratégie de mise à jour progressive

Gardez à l’esprit ces comportements et limitations actuels lors de l’utilisation de la stratégie de mise à jour propagée. Cette liste est conservée pendant la période d’évaluation et peut changer à mesure que la fonctionnalité approche de la disponibilité générale (GA).

• Paramètres gérés par la plateforme : la plateforme contrôle les paramètres (tels que le nombre de lots, les instances par lot, le nombre de lots et les intervalles de drainage) qui déterminent les comportements de mise à jour propagés. Ces paramètres peuvent changer avant la disponibilité générale pour optimiser la performance et la fiabilité.
• Aucune surveillance en temps réel : il n’existe actuellement aucune visibilité sur le nombre d’instances qui se vident, le nombre de lots restant ou les pourcentages de progression actuels.
• Aucun signal d’achèvement : toutefois, vous pouvez surveiller les journaux d’activité d’instance pour estimer quand une mise à jour se termine.
• Scénarios à instance unique : les applications s’exécutant sur une instance subissent un bref temps d’arrêt similaire à la recréation, bien que les exécutions en cours soient toujours terminées.
• Durable Functions : étant donné que le mélange de versions pendant les mises à jour peut entraîner un comportement inattendu dans une orchestration durable, utilisez une stratégie de correspondance de version d’orchestration explicite.
• Infrastructure en tant que code : le déploiement de modifications de code et de configuration déclenche plusieurs mises à jour propagées qui peuvent se chevaucher.
• Compatibilité descendante : assurez-vous que vos modifications fonctionnent avec la version précédente pendant la période de transition de mise à jour continue.

Configurer votre stratégie de mise à jour

Vous pouvez définir la stratégie de mise à jour pour votre application à l’aide du paramètre de SiteUpdateStrategy site, qui est un enfant de functionAppConfig. Par défaut, SiteUpdateStrategy.type est définie sur Recreate. Actuellement, seuls les modèles Bicep et ARM avec une version de l’API 2023-12-01 ou ultérieure prennent en charge la modification de cette propriété.

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

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

Les modifications apportées à la stratégie de mise à jour du site prennent effet lors de la prochaine mise à jour du site. Par exemple, passer de type à Recreate pour RollingUpdate utilise la stratégie de recréation pour cette mise à jour. Toutes les mises à jour de site suivantes utilisent ensuite les mises à jour progressives.

Surveillance des mises à jour du site

Pendant la préversion publique, il n’existe aucun signal d’achèvement intégré pour les mises à jour de site. Vous pouvez utiliser des requêtes KQL dans Application Insights comme une approche basée sur le meilleur effort pour estimer la progression des mises à jour en cours.

Surveillance de la progression de la mise à jour progressive

Ces requêtes KQL fournissent une estimation de la progression de la mise à jour par étapes en suivant le renouvellement des instances dans les journaux Application Insights. Cette approche présente des limitations importantes et ne doit pas être prise en compte pour l’automatisation de la production :

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

Comment utiliser cette requête pour l’estimation :

1. Collez cette requête dans le panneau des journaux de la ressource Application Insights associée à votre application de fonction.
2. Définissez deploymentStart à l’horodatage lorsque la mise à jour de votre site indique un succès.
3. Exécutez la requête régulièrement pour estimer la progression. Définissez l’intervalle d’interrogation sur au moins tant que votre temps d’exécution de fonction moyen et vérifiez que la checkInterval variable dans la requête correspond à cette fréquence d’interrogation.
4. La requête retourne des valeurs approximatives :
   • RollingUpdateComplete: Estimation optimale de la façon dont toutes les instances d’origine sont remplacées
   • PercentComplete: pourcentage estimé d’instances d’origine remplacées
   • OriginalStillActiveCount: Nombre estimé d’instances d’origine toujours en cours d’exécution
   • NewCount: nombre de nouvelles instances actuellement actives

Gardez ces limitations à l’esprit lors de l’utilisation de ces requêtes :

1. Écart de synchronisation : le temps deploymentStart représente le moment où la mise à jour de votre site renvoie un succès, mais la mise à jour déployée réelle peut ne pas démarrer immédiatement. Pendant cet intervalle, les événements de scale-out approvisionnent des instances exécutant la version d’origine. Étant donné que la requête effectue uniquement le suivi des instances actives à deploymentStart, elle ne surveille pas ces nouvelles instances de la version d'origine, ce qui peut entraîner de faux signaux d'achèvement.

2. Détection basée sur les journaux : cette approche s’appuie sur les journaux d’application pour déduire l’état de l’instance plutôt que d’interroger directement l’état de l’instance. Les instances peuvent être en cours d’exécution, mais ne journalisent pas activement, ce qui entraîne de faux signaux d’achèvement lorsque les instances d’origine sont toujours actives, mais n’ont pas émis de journaux dans la fenêtre de temps checkInterval.

Recommandation pour la production : utilisez les mises à jour propagées lorsque les déploiements sans temps d’arrêt sont essentiels. Vérifiez que vos pipelines de déploiement ne nécessitent pas d’attendre la fin de la mise à jour avant de passer aux étapes suivantes. Utilisez la recréation lorsque vous avez besoin d’un délai de mise à jour plus rapide et plus prévisible et que vous pouvez tolérer un bref temps d'arrêt.

Questions fréquentes (FAQ)

Je suis habitué aux slots de déploiement pour les déploiements sans interruption. Comment les mises à jour progressives diffèrent-elles ?

• Contrairement aux emplacements de déploiement, les mises à jour continues ne nécessitent aucune infrastructure supplémentaire. Réglez siteUpdateStrategy.type à "RollingUpdate" pour les déploiements sans interruption.
• Les mises à jour propagées conservent les exécutions en cours, tandis que les emplacements de déploiement les terminent pendant les échanges. Certaines propriétés de site et paramètres persistants ne peuvent pas être échangés et nécessitent la modification directe de l’emplacement de production.
• Contrairement aux emplacements de déploiement, les mises à jour propagées ne fournissent pas d’environnement distinct pour vous permettre de tester les modifications ou d’acheminer un pourcentage de trafic actif vers. Si vous avez besoin de ces fonctionnalités, utilisez un plan qui prend en charge les emplacements de déploiement, comme Elastic Premium, ou gérez des applications Flex Consumption distinctes derrière un gestionnaire de trafic.

Comment restaurer une mise à jour de site ?

• Il n’existe actuellement aucune fonctionnalité permettant de restaurer une mise à jour de site. Si une restauration s’avère nécessaire, lancez une nouvelle mise à jour du site avec l’état précédent du code ou de la configuration.

Comment les déclencheurs du minuteur sont-ils gérés ?

• Les déclencheurs du minuteur conservent leur nature singleton. Une fois qu’une application de fonction déclenchée par un minuteur est marquée pour drainer, les nouvelles fonctions du minuteur s’exécutent sur la dernière version.

Je vois des erreurs d’exécution pendant la mise à jour propagée... qu’est-ce qui s’est passé ?

• Si de nouvelles instances ne parviennent pas à démarrer ou à rencontrer des erreurs d’exécution, le problème est probablement lié au code de l’application, aux dépendances, aux paramètres de configuration ou aux variables d’environnement que vous avez modifiées.
• Pour résoudre le problème, redéployez votre dernière version saine connue pour restaurer le runtime. Testez ensuite vos modifications proposées dans un environnement de développement ou de préproduction avant de réessayer. Passez en revue les journaux d’erreurs pour identifier quelle modification spécifique a provoqué le problème.

Étapes suivantes

• En savoir plus sur le plan Flex Consumption
• En savoir plus sur la façon dont les déploiements diffèrent dans Flex Consumption
• Découvrez comment écrire des modèles infrastructure-as-code