Implementatie zonder downtime voor Durable Functions

Het betrouwbare uitvoeringsmodel van Durable Functions vereist dat indelingen deterministisch zijn, waardoor een extra uitdaging ontstaat om rekening mee te houden wanneer u updates implementeert. Wanneer een implementatie wijzigingen bevat in handtekeningen van activiteitsfuncties of orchestratorlogica, mislukken in-flight indelingsexemplaren. Deze situatie is vooral een probleem voor exemplaren van langlopende indelingen, die uren of dagen werk kunnen vertegenwoordigen.

Als u wilt voorkomen dat deze fouten optreden, hebt u twee opties:

• Stel de implementatie uit totdat alle actieve indelingsexemplaren zijn voltooid.
• Zorg ervoor dat alle actieve indelingsexemplaren gebruikmaken van de bestaande versies van uw functies.

In de volgende grafiek worden de drie belangrijkste strategieën vergeleken om een implementatie zonder downtime voor Durable Functions te realiseren:

Strategie	Wanneer gebruiken	Voordelen	Nadelen
Versiebeheer	Toepassingen die geen frequente wijzigingen ondervinden die fouten veroorzaken.	Eenvoudig te implementeren.	Grotere grootte van functie-apps in het geheugen en het aantal functies. Codeduplicatie.
Statuscontrole met site	Een systeem dat niet langer dan 24 uur of vaak overlappende indelingen heeft.	Eenvoudige codebasis. Hiervoor is geen extra beheer van functie-apps vereist.	Hiervoor is extra opslagaccount- of taakhubbeheer vereist. Vereist perioden waarin geen indelingen worden uitgevoerd.
Toepassingsroutering	Een systeem dat geen tijdsperioden heeft waarop indelingen niet worden uitgevoerd, zoals die tijdsperioden met indelingen die langer dan 24 uur duren of met vaak overlappende indelingen.	Verwerkt nieuwe versies van systemen met voortdurend actieve indelingen die wijzigingen veroorzaken.	Vereist een intelligente toepassingsrouter. Het maximum aantal functie-apps dat is toegestaan door uw abonnement, kan worden overschreden. De standaard is 100.

In de rest van dit document worden deze strategieën gedetailleerder beschreven.

Notitie

In de beschrijvingen voor deze strategieën voor implementatie zonder downtime wordt ervan uitgegaan dat u de standaard Azure Storage-provider voor Durable Functions gebruikt. De richtlijnen zijn mogelijk niet geschikt als u een andere opslagprovider gebruikt dan de standaard Azure Storage-provider. Zie de documentatie van de Durable Functions-opslagproviders voor meer informatie over de verschillende opties voor opslagproviders en hoe deze zich verhouden.

Versiebeheer

Definieer nieuwe versies van uw functies en laat de oude versies in uw functie-app staan. Zoals u in het diagram kunt zien, wordt de versie van een functie onderdeel van de naam. Omdat eerdere versies van functies behouden blijven, kunnen in-flight indelingsexemplaren ernaar blijven verwijzen. Ondertussen worden aanvragen voor nieuwe indelingsexemplaren aangeroepen voor de nieuwste versie, waarnaar uw orchestration-clientfunctie kan verwijzen vanuit een app-instelling.

In deze strategie moet elke functie worden gekopieerd en moeten de verwijzingen naar andere functies worden bijgewerkt. U kunt het eenvoudiger maken door een script te schrijven. Hier volgt een voorbeeldproject met een migratiescript.

Notitie

Deze strategie maakt gebruik van implementatiesites om downtime tijdens de implementatie te voorkomen. Zie Azure Functions-implementatiesites voor meer informatie over het maken en gebruiken van nieuwe implementatiesites.

Statuscontrole met site

Terwijl de huidige versie van uw functie-app wordt uitgevoerd in uw productiesite, implementeert u de nieuwe versie van uw functie-app in uw staging-site. Voordat u uw productie- en faseringssites verwisselt, controleert u of er actieve orchestration-exemplaren zijn. Nadat alle indelingsexemplaren zijn voltooid, kunt u de wissel uitvoeren. Deze strategie werkt wanneer u voorspelbare perioden hebt wanneer er geen indelingsexemplaren worden uitgevoerd. Dit is de beste aanpak wanneer uw indelingen niet lang lopen en wanneer uw indelingsuitvoeringen niet vaak overlappen.

Configuratie van functie-app

Gebruik de volgende procedure om dit scenario in te stellen.

1. Voeg implementatiesites toe aan uw functie-app voor fasering en productie.

2. Stel voor elke site de toepassingsinstelling AzureWebJobsStorage in op de verbinding van een gedeeld opslagaccount. Deze verbinding met het opslagaccount wordt gebruikt door de Azure Functions-runtime om de toegangssleutels van de functies veilig op te slaan. Voor het hoogste beveiligingsniveau moet u een beheerde identiteitverbinding met uw opslagaccount gebruiken.

3. Maak voor elke site een nieuwe app-instelling, bijvoorbeeld DurableManagementStorage. Stel de waarde ervan in op de verbindingsreeks van verschillende opslagaccounts. Deze opslagaccounts worden gebruikt door de Durable Functions-extensie voor betrouwbare uitvoering. Gebruik een afzonderlijk opslagaccount voor elke site. Markeer deze instelling niet als een implementatiesite-instelling. Ook hier zijn verbindingen op basis van beheerde identiteiten het veiligst.

4. Geef connectionStringName in de sectie durableTask van uw functie-app host.json (Durable 2.x) of azureStorageConnectionStringName (Durable 1.x) op als de naam van de app-instelling die u in stap 3 hebt gemaakt.

In het volgende diagram ziet u de beschreven configuratie van implementatiesites en opslagaccounts. In dit potentiële predeploymentscenario wordt versie 2 van een functie-app uitgevoerd in de productiesite, terwijl versie 1 in de staging-site blijft.

voorbeelden van host.json

De volgende JSON-fragmenten zijn voorbeelden van de verbindingsreeks-instelling in het host.json-bestand.

Functions 2.0

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

Functions 1.x

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

CONFIGURATIE van CI/CD-pijplijn

Configureer uw CI/CD-pijplijn zodanig dat deze alleen wordt geïmplementeerd wanneer uw functie-app geen in behandeling zijnde of actieve indelingsexemplaren heeft. Wanneer u Azure Pipelines gebruikt, kunt u een functie maken die op deze voorwaarden controleert, zoals in het volgende voorbeeld:

[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() });
}

Configureer vervolgens de faseringspoort om te wachten totdat er geen indelingen worden uitgevoerd. Zie Release-implementatiebeheer met behulp van poorten voor meer informatie

Azure Pipelines controleert uw functie-app op het uitvoeren van orchestration-exemplaren voordat uw implementatie wordt gestart.

Nu moet de nieuwe versie van uw functie-app worden geïmplementeerd in de staging-site.

Wisselsites ten slotte.

Toepassingsinstellingen die niet zijn gemarkeerd als implementatiesite-instellingen, worden ook gewisseld, zodat de versie 2-app de verwijzing naar opslagaccount A behoudt. Omdat de indelingsstatus wordt bijgehouden in het opslagaccount, blijven alle orchestrations die worden uitgevoerd op de app versie 2, zonder onderbreking in de nieuwe site worden uitgevoerd.

Als u hetzelfde opslagaccount voor beide sites wilt gebruiken, kunt u de namen van uw taakhubs wijzigen. In dit geval moet u de status van uw sites en de HubName-instellingen van uw app beheren. Zie Taakhubs in Durable Functions voor meer informatie.

Sollicitatieroutering

Deze strategie is het meest complex. Het kan echter worden gebruikt voor functie-apps die geen tijd hebben tussen actieve indelingen.

Voor deze strategie moet u een toepassingsrouter maken vóór uw Durable Functions. Deze router kan worden geïmplementeerd met Durable Functions. De router heeft de verantwoordelijkheid om:

• Implementeer de functie-app.
• Beheer de versie van Durable Functions.
• Routeer indelingsaanvragen naar functie-apps.

De eerste keer dat een indelingsaanvraag wordt ontvangen, voert de router de volgende taken uit:

1. Hiermee maakt u een nieuwe functie-app in Azure.
2. Implementeert de code van uw functie-app in de nieuwe functie-app in Azure.
3. Stuurt de indelingsaanvraag door naar de nieuwe app.

De router beheert de status van welke versie van de code van uw app wordt geïmplementeerd in welke functie-app in Azure.

De router stuurt implementatie- en indelingsaanvragen naar de juiste functie-app op basis van de versie die met de aanvraag is verzonden. De patchversie wordt genegeerd.

Wanneer u een nieuwe versie van uw app implementeert zonder een belangrijke wijziging, kunt u de patchversie verhogen. De router wordt geïmplementeerd in uw bestaande functie-app en verzendt aanvragen voor de oude en nieuwe versies van de code, die worden gerouteerd naar dezelfde functie-app.

Wanneer u een nieuwe versie van uw app implementeert met een belangrijke wijziging, kunt u de primaire of secundaire versie verhogen. Vervolgens maakt de toepassingsrouter een nieuwe functie-app in Azure, implementeert deze en stuurt aanvragen naar de nieuwe versie van uw app. In het volgende diagram worden indelingen uitgevoerd op de versie 1.0.1 van de app, maar aanvragen voor de versie 1.1.0 worden doorgestuurd naar de nieuwe functie-app.

De router bewaakt de status van indelingen op de versie 1.0.1 en verwijdert apps nadat alle indelingen zijn voltooid.

Store-instellingen bijhouden

Elke functie-app moet afzonderlijke planningswachtrijen gebruiken, mogelijk in afzonderlijke opslagaccounts. Als u query's wilt uitvoeren op alle indelingen in alle versies van uw toepassing, kunt u exemplaar- en geschiedenistabellen delen in uw functie-apps. U kunt tabellen delen door de trackingStoreConnectionStringName instellingen en trackingStoreNamePrefix instellingen in het host.json-instellingenbestand te configureren, zodat ze allemaal dezelfde waarden gebruiken.

Zie Exemplaren beheren in Durable Functions in Azure voor meer informatie.

Volgende stappen

Durable Functions-versiebeheer