Strategie di aggiornamento del sito in Flex Consumption

Quando si ospita l'app con Funzioni di Azure nel piano a consumo Flex Consumption plan, è possibile controllare la modalità di distribuzione degli aggiornamenti nelle istanze in esecuzione. Un aggiornamento del sito si verifica ogni volta che si distribuisce il codice, si modificano le impostazioni dell'applicazione o si modificano altre proprietà di configurazione. Il piano Flex Consumption fornisce un'impostazione di configurazione (SiteUpdateStrategy) che è possibile usare per controllare se l'app per le funzioni riscontra tempi di inattività durante questi aggiornamenti e come vengono gestite le esecuzioni in corso.

Il piano Flex Consumption supporta attualmente queste strategie di aggiornamento:

• Ricrea: riavvia tutte le istanze in esecuzione dopo l'aggiornamento dell'app con le modifiche più recenti. Questo approccio può causare brevi tempi di inattività mentre le istanze vengono riciclate e mantiene il comportamento predefinito da altri piani di hosting Funzioni di Azure.
• Aggiornamento progressivo: consente rilasci senza interruzioni mettendo fuori servizio e sostituendo le istanze in batch. Le esecuzioni in corso sono completate naturalmente senza terminazione forzata.

Confronto tra strategie

Questa tabella confronta le due strategie di aggiornamento del sito:

Comportamenti strategici di aggiornamento

Questa tabella confronta il processo di aggiornamento delle due strategie:

Questa tabella confronta le caratteristiche principali delle due strategie:

Considerazioni sulla strategia di aggiornamento in sequenza

Tenere presenti questi comportamenti e limitazioni correnti quando si usa la strategia di aggiornamento in sequenza.

• Parametri gestiti dalla piattaforma: la piattaforma controlla i parametri (ad esempio conteggio batch, istanze per batch, numero di batch e intervalli di svuotamento) che determinano i comportamenti di aggiornamento in sequenza. Questi parametri possono cambiare per ottimizzare le prestazioni e l'affidabilità.
• La modifica della strategia è un no-op nelle aree di disponibilità generali: nelle aree in cui gli aggiornamenti in sequenza sono disponibili a livello generale, la modifica siteUpdateStrategy.type non attiva un aggiornamento del sito. È possibile aggiornare la strategia in anticipo e applicarla al codice o alla distribuzione di configurazione successiva. Nelle aree in cui gli aggiornamenti in sequenza vengono ancora implementati, la modifica della strategia viene considerata come qualsiasi altra modifica della configurazione e attiva un aggiornamento del sito che usa la strategia precedente ; la nuova strategia si applica a partire dalla successiva distribuzione.
• Nessun monitoraggio in tempo reale: attualmente non è disponibile alcuna visibilità sul numero di istanze in fase di svuotamento, sul numero di batch rimasti o sulle percentuali di avanzamento correnti.
• Nessun segnale di completamento: tuttavia, è possibile monitorare i log delle istanze per stimare il completamento di un aggiornamento.
• Scenari a istanza singola: le app in esecuzione su un'istanza sperimentano un breve tempo di inattività simile a quello di una creazione, anche se le esecuzioni in corso vengono comunque completate integralmente.
• Durable Functions: poiché la combinazione di versioni durante gli aggiornamenti può causare un comportamento imprevisto in un'orchestrazione Durable, usare una strategia di corrispondenza delle versioni di orchestrazione esplicita.
• Infrastruttura come codice: la distribuzione di modifiche di codice e configurazione insieme attiva più aggiornamenti in sequenza che potrebbero sovrapporsi.
• Compatibilità con le versioni precedenti: assicurarsi che le modifiche funzionino con la versione precedente durante il periodo di transizione dell'aggiornamento in sequenza.

Configurare la strategia di aggiornamento

È possibile impostare la strategia di aggiornamento per l'app usando l'impostazione del SiteUpdateStrategy sito, che è un elemento figlio di functionAppConfig. Per impostazione predefinita, SiteUpdateStrategy.type è impostato su Recreate. È possibile configurare questa impostazione usando interfaccia della riga di comando di Azure 2.87.0 o versioni successive, Bicep o modelli arm con versione API 2023-12-01 o versione successiva.

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

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

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

Monitoraggio degli aggiornamenti del sito

Non è disponibile alcun segnale di completamento predefinito per gli aggiornamenti del sito. È possibile usare query KQL in Application Insights come approccio ottimale per stimare lo stato di avanzamento dell'aggiornamento in sequenza.

Monitoraggio dello stato di avanzamento dell'aggiornamento in sequenza

Queste query KQL forniscono una stima best-effort dello stato di avanzamento dell'aggiornamento progressivo, rilevando il turnover delle istanze nei log di Application Insights. Questo approccio presenta limitazioni significative e non deve essere basato sull'automazione di produzione:

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

Come usare questa query per la stima:

1. Incolla questa query nella sezione Logs della risorsa di Application Insights associata alla tua app di funzioni.
2. Impostare deploymentStart sul timestamp quando l'aggiornamento del sito restituisce l'esito positivo.
3. Eseguire periodicamente la query per stimare lo stato di avanzamento. Impostare l'intervallo di polling almeno pari al tempo medio di esecuzione della funzione e assicurarsi che la variabile checkInterval nella query sia conforme a questa frequenza di polling.
4. La query restituisce valori approssimativi:

RollingUpdateComplete: stima migliore dell'eventuale sostituzionePercentComplete di tutte le istanze originali: percentuale stimata di istanze originali sostituiteOriginalStillActiveCount: Numero stimato di istanze originali ancora in esecuzioneNewCount: Numero di nuove istanze attualmente attive

Tenere presenti queste limitazioni quando si usano queste query:

1. Intervallo di tempo: il deploymentStart tempo indica quando l'aggiornamento del sito restituisce esito positivo, ma l'aggiornamento in sequenza effettivo potrebbe non essere avviato immediatamente. Durante questo intervallo, tutte le istanze di provisioning di eventi di scale-out eseguono la versione originale. Poiché la query tiene traccia solo delle istanze attive in deploymentStart, non monitora queste nuove istanze della versione originale, causando potenzialmente falsi segnali di completamento.
2. Rilevamento basato su log: questo approccio si basa sui log applicazioni per dedurre lo stato dell'istanza anziché eseguire direttamente query sullo stato dell'istanza. Le istanze potrebbero essere in esecuzione ma non registrano attivamente, causando falsi segnali di completamento quando le istanze originali sono ancora attive, ma non hanno generato log all'interno della checkInterval finestra.

Raccomandazione per la produzione: usare gli aggiornamenti in sequenza quando le distribuzioni senza tempi di inattività sono critiche. Assicurarsi che le pipeline di distribuzione non richiedano l'attesa del completamento dell'aggiornamento prima di procedere con i passaggi successivi. Usa 'ricrea' quando hai bisogno di aggiornamenti più veloci e prevedibili e puoi tollerare un breve periodo di inattività.

Domande frequenti

Usato per gli slot di distribuzione per la distribuzione senza tempi di inattività. Come differiscono gli aggiornamenti in sequenza?

• A differenza degli slot di distribuzione, gli aggiornamenti progressivi non richiedono un'infrastruttura aggiuntiva. Impostare siteUpdateStrategy.type su "RollingUpdate" per implementazioni a zero tempi di inattività.
• Gli aggiornamenti progressivi mantengono le esecuzioni in corso, mentre gli slot di distribuzione le terminano durante gli scambi. Determinate proprietà del sito e impostazioni permanenti non possono essere scambiate e richiedono la modifica diretta dello slot di produzione.
• A differenza degli slot di distribuzione, gli aggiornamenti progressivi non forniscono un ambiente separato per testare le modifiche canary o instradare una percentuale del traffico live. Se sono necessarie queste funzionalità, usare un piano che supporti per gli slot di distribuzione, come Elastic Premium, oppure gestire app a consumo flessibile dietro un gestore del traffico.

Come si esegue il rollback di un aggiornamento del sito?

• Attualmente non è disponibile alcuna funzionalità per eseguire il rollback di un aggiornamento del sito. Se è necessario un rollback, avviare un altro aggiornamento del sito con lo stato precedente del codice o della configurazione.

Come vengono gestiti i trigger timer?

• I trigger del timer mantengono la loro natura singleton. Dopo che un'app per le funzioni attivata dal timer è contrassegnata per lo svuotamento, le nuove funzioni timer vengono eseguite nell'ultima versione.

Durante l'aggiornamento in sequenza vengono visualizzati errori di runtime... cosa è andato storto?

• Se le nuove istanze non vengono avviate o si verificano errori di runtime, è probabile che il problema si verifichi nel codice dell'applicazione, nelle dipendenze, nelle impostazioni di configurazione o nelle variabili di ambiente modificate.
• Per risolvere il problema, reimplementare l'ultima versione funzionante conosciuta per ripristinare il runtime. Testare quindi le modifiche proposte in un ambiente di sviluppo o di gestione temporanea prima di ripetere la procedura. Esaminare i log degli errori per identificare la modifica specifica che ha causato il problema.

Passaggi successivi

• Altre informazioni sul piano Flex Consumption
• Altre informazioni su come le distribuzioni differiscono in Flex Consumption
• Informazioni su come scrivere modelli di infrastruttura come codice