Distribuzione senza tempi di inattività per Durable Functions

Il modello di esecuzione affidabile di Durable Functions richiede che le orchestrazioni siano deterministiche, il che crea una sfida aggiuntiva da considerare quando si distribuiscono gli aggiornamenti. Quando una distribuzione contiene modifiche alle firme della funzione di attività o alla logica dell'agente di orchestrazione, le istanze di orchestrazione in anteprima hanno esito negativo. Questa situazione è particolarmente un problema per le istanze di orchestrazioni a esecuzione prolungata, che potrebbero rappresentare ore o giorni di lavoro.

Per evitare che si verifichino questi errori, sono disponibili due opzioni:

• Ritardare la distribuzione fino al completamento di tutte le istanze di orchestrazione in esecuzione.
• Assicurarsi che tutte le istanze di orchestrazione in esecuzione usino le versioni esistenti delle funzioni.

Il grafico seguente confronta le tre strategie principali per ottenere una distribuzione senza tempi di inattività per Durable Functions:

Strategia	Utilizzo	Vantaggi	Svantaggi
Versioning	Applicazioni che non riscontrano frequenti modifiche che causano interruzioni.	Facile da implementare.	Aumento delle dimensioni dell'app per le funzioni in memoria e numero di funzioni. Duplicazione del codice.
Controllo dello stato con slot	Un sistema che non ha orchestrazioni a esecuzione prolungata che durano più di 24 ore o orchestrazioni spesso sovrapposte.	Codebase semplice. Non richiede una gestione aggiuntiva delle app per le funzioni.	Richiede un account di archiviazione aggiuntivo o una gestione dell'hub attività. Richiede periodi di tempo in cui non sono in esecuzione orchestrazioni.
Routing delle applicazioni	Un sistema che non ha periodi di tempo in cui le orchestrazioni non sono in esecuzione, ad esempio i periodi di tempo con orchestrazioni che durano più di 24 ore o con orchestrazioni spesso sovrapposte.	Gestisce le nuove versioni dei sistemi con orchestrazioni che eseguono continuamente modifiche che causano interruzioni.	Richiede un router applicazione intelligente. Potrebbe essere massimo il numero di app per le funzioni consentite dalla sottoscrizione. Il valore predefinito è 100.

Nella parte restante di questo documento vengono descritte in modo più dettagliato queste strategie.

Nota

Le descrizioni di queste strategie di distribuzione senza tempi di inattività presuppongono l'uso del provider di archiviazione di Azure predefinito per Durable Functions. Le indicazioni potrebbero non essere appropriate se si usa un provider di archiviazione diverso dal provider di archiviazione di Azure predefinito. Per altre informazioni sulle varie opzioni del provider di archiviazione e sul relativo confronto, vedere la documentazione dei provider di archiviazione Durable Functions.

Controllo delle versioni

Definire nuove versioni delle funzioni e lasciare le versioni precedenti nell'app per le funzioni. Come si può notare nel diagramma, la versione di una funzione diventa parte del nome. Poiché le versioni precedenti delle funzioni vengono mantenute, le istanze di orchestrazione in anteprima possono continuare a farvi riferimento. Nel frattempo, le richieste di nuove istanze di orchestrazione chiamano la versione più recente, a cui la funzione client di orchestrazione può fare riferimento da un'impostazione dell'app.

In questa strategia, ogni funzione deve essere copiata e i relativi riferimenti ad altre funzioni devono essere aggiornati. È possibile semplificare la scrittura di uno script. Ecco un progetto di esempio con uno script di migrazione.

Nota

Questa strategia usa gli slot di distribuzione per evitare tempi di inattività durante la distribuzione. Per informazioni più dettagliate su come creare e usare nuovi slot di distribuzione, vedere Funzioni di Azure slot di distribuzione.

Controllo dello stato con slot

Mentre la versione corrente dell'app per le funzioni è in esecuzione nello slot di produzione, distribuire la nuova versione dell'app per le funzioni nello slot di staging. Prima di scambiare gli slot di produzione e di staging, verificare se sono presenti istanze di orchestrazione in esecuzione. Al termine di tutte le istanze di orchestrazione, è possibile eseguire lo scambio. Questa strategia funziona quando si hanno periodi prevedibili quando non sono in esecuzione istanze di orchestrazione. Questo è l'approccio migliore quando le orchestrazioni non sono a esecuzione prolungata e quando le esecuzioni di orchestrazione non si sovrappongono di frequente.

Configurazione dell'app per le funzioni

Utilizzare la procedura seguente per configurare questo scenario.

1. Aggiungere slot di distribuzione all'app per le funzioni per la gestione temporanea e l'ambiente di produzione.

2. Per ogni slot, impostare l'impostazione dell'applicazione AzureWebJobsStorage sulla stringa di connessione di un account di archiviazione condiviso. Questa stringa di connessione dell'account di archiviazione viene usata dal runtime Funzioni di Azure per archiviare in modo sicuro le chiavi di accesso delle funzioni.

3. Per ogni slot, creare una nuova impostazione dell'app, ad esempio DurableManagementStorage. Impostarne il valore sulla stringa di connessione di account di archiviazione diversi. Questi account di archiviazione vengono usati dall'estensione Durable Functions per l'esecuzione affidabile. Usare un account di archiviazione separato per ogni slot. Non contrassegnare questa impostazione come impostazione dello slot di distribuzione.

4. Nella sezione durableTask del file host.json dell'app per le funzioni specificare connectionStringName (Durable 2.x) o azureStorageConnectionStringName (Durable 1.x) come nome dell'impostazione dell'app creata nel passaggio 3.

Il diagramma seguente illustra la configurazione descritta degli slot di distribuzione e degli account di archiviazione. In questo potenziale scenario di pre-distribuzione, la versione 2 di un'app per le funzioni è in esecuzione nello slot di produzione, mentre la versione 1 rimane nello slot di staging.

Esempi di host.json

I frammenti JSON seguenti sono esempi dell'impostazione della stringa di connessione nel file host.json .

Funzioni 2.0

{
  "version": 2.0,
  "extensions": {
    "durableTask": {
      "hubName": "MyTaskHub",
      "storageProvider": {
        "connectionStringName": "DurableManagementStorage"
      }
    }
  }
}

Funzioni 1.x

{
  "durableTask": {
    "azureStorageConnectionStringName": "DurableManagementStorage"
  }
}

Configurazione della pipeline CI/CD

Configurare la pipeline CI/CD per la distribuzione solo quando l'app per le funzioni non ha istanze di orchestrazione in sospeso o in esecuzione. Quando si usa Azure Pipelines, è possibile creare una funzione che verifica la presenza di queste condizioni, come nell'esempio seguente:

[FunctionName("StatusCheck")]
public static async Task<IActionResult> StatusCheck(
    [HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestMessage req,
    [DurableClient] IDurableOrchestrationClient client,
    ILogger log)
{
    var runtimeStatus = new List<OrchestrationRuntimeStatus>();

    runtimeStatus.Add(OrchestrationRuntimeStatus.Pending);
    runtimeStatus.Add(OrchestrationRuntimeStatus.Running);

    var result = await client.ListInstancesAsync(new OrchestrationStatusQueryCondition() { RuntimeStatus = runtimeStatus }, CancellationToken.None);
    return (ActionResult)new OkObjectResult(new { HasRunning = result.DurableOrchestrationState.Any() });
}

Configurare quindi il controllo di gestione temporanea per attendere che non siano in esecuzione orchestrazioni. Per altre informazioni, vedere Release deployment control using gates (Rilasciare il controllo della distribuzione tramite gate)

Azure Pipelines controlla l'app per le funzioni per l'esecuzione di istanze di orchestrazione prima dell'avvio della distribuzione.

Ora la nuova versione dell'app per le funzioni deve essere distribuita nello slot di staging.

Infine, scambiare gli slot.

Anche le impostazioni dell'applicazione non contrassegnate come impostazioni dello slot di distribuzione vengono scambiate, quindi l'app versione 2 mantiene il riferimento all'account di archiviazione A. Poiché lo stato dell'orchestrazione viene rilevato nell'account di archiviazione, tutte le orchestrazioni in esecuzione nell'app versione 2 continuano a essere eseguite nel nuovo slot senza interruzioni.

Per usare lo stesso account di archiviazione per entrambi gli slot, è possibile modificare i nomi degli hub attività. In questo caso, è necessario gestire lo stato degli slot e le impostazioni HubName dell'app. Per altre informazioni, vedere Hub attività in Durable Functions.

Routing delle applicazioni

Questa strategia è la più complessa. Tuttavia, può essere usato per le app per le funzioni che non hanno tempo tra l'esecuzione di orchestrazioni.

Per questa strategia, è necessario creare un router applicazione davanti al Durable Functions. Questo router può essere implementato con Durable Functions. Il router ha la responsabilità di:

• Distribuire l'app per le funzioni.
• Gestire la versione di Durable Functions.
• Instradare le richieste di orchestrazione alle app per le funzioni.

La prima volta che viene ricevuta una richiesta di orchestrazione, il router esegue le attività seguenti:

1. Crea una nuova app per le funzioni in Azure.
2. Distribuisce il codice dell'app per le funzioni nella nuova app per le funzioni in Azure.
3. Inoltra la richiesta di orchestrazione alla nuova app.

Il router gestisce lo stato di cui viene distribuita la versione del codice dell'app per le funzioni in Azure.

Il router indirizza le richieste di distribuzione e orchestrazione all'app per le funzioni appropriate in base alla versione inviata con la richiesta. Ignora la versione della patch.

Quando si distribuisce una nuova versione dell'app senza una modifica di rilievo, è possibile incrementare la versione della patch. Il router viene distribuito nell'app per le funzioni esistente e invia richieste per le versioni precedenti e nuove del codice, indirizzate alla stessa app per le funzioni.

Quando si distribuisce una nuova versione dell'app con una modifica di rilievo, è possibile incrementare la versione principale o secondaria. Il router dell'applicazione crea quindi una nuova app per le funzioni in Azure, la distribuisce e instrada le richieste per la nuova versione dell'app. Nel diagramma seguente, l'esecuzione di orchestrazioni nella versione 1.0.1 dell'app mantiene in esecuzione, ma le richieste per la versione 1.1.0 vengono indirizzate alla nuova app per le funzioni.

Il router monitora lo stato delle orchestrazioni nella versione 1.0.1 e rimuove le app dopo il completamento di tutte le orchestrazioni.

Impostazioni dell'archivio di rilevamento

Ogni app per le funzioni deve usare code di pianificazione separate, possibilmente in account di archiviazione separati. Se si desidera eseguire query su tutte le istanze di orchestrazione in tutte le versioni dell'applicazione, è possibile condividere tabelle di istanza e cronologia nelle app per le funzioni. È possibile condividere le tabelle configurando le trackingStoreConnectionStringName impostazioni e trackingStoreNamePrefix nel file di impostazioni host.json in modo che usino tutti gli stessi valori.

Per altre informazioni, vedere Gestire le istanze in Durable Functions in Azure.

Passaggi successivi

Controllo delle versioni Durable Functions