Bereitstellung ohne Ausfallzeiten für Durable Functions

Das zuverlässiges Ausführungsmodell von Durable Functions erfordert, dass Orchestrierungen deterministisch sind, wodurch beim Bereitstellen von Updates eine Herausforderung entsteht. Wenn eine Bereitstellung Breaking Changes – wie z. B. geänderte Aktivitätsfunktionssignaturen oder geänderte Orchestratorlogik – enthält, schlagen laufende Orchestrierungsinstanzen fehl. Diese Situation ist besonders ein Problem bei langen Orchestrierungen, die Stunden oder Arbeitstage darstellen können.

In der folgenden Tabelle werden vier Strategien für die Bereitstellung von Null-Ausfallzeiten verglichen. Wählen Sie die Strategie aus, die Ihrem Workload am besten entspricht:

Orchestrierungsversionierung

Die Orchestrierungsversionierung ist die empfohlene Strategie für Bereitstellungen ohne Ausfallzeiten bei einschneidenden Änderungen. Sie ermöglicht es, dass verschiedene Versionen von Orchestrierungen ohne Konflikte gleichzeitig koexistieren und ausgeführt werden können.

Mit Orchestrierungsversionierung:

• Jede Orchestrierungsinstanz erhält eine Version, die bei der Erstellung dauerhaft damit verknüpft ist.
• Mitarbeiter, die neuere Orchestratorversionen ausführen, können weiterhin ältere Versionsinstanzen ausführen.
• Mitarbeiter, die ältere Orchestrierungsversionen ausführen , können keine neueren Versionsinstanzen ausführen.
• Orchestrator-Funktionen können ihre Version und Verzweigungsausführung entsprechend untersuchen.

Dieser Ansatz erleichtert das Rollout von Upgrades, bei denen Mitarbeiter, die verschiedene Versionen Ihrer Anwendung ausführen, sicher koexistieren können. Im Gegensatz zu den anderen Strategien in diesem Artikel ist die Orchestrierungsversionsverwaltung back-end agnostisch und funktioniert mit jedem Speicheranbieter.

Vollständige Implementierungsschritte – einschließlich der Konfiguration der Versionierung, Behandlung der Versionsverzweigungen im Orchestratorcode und Verwaltung von Rollupgrades – finden Sie unter Orchestration-Versionsverwaltung.

Die verbleibenden Strategien sind Alternativen für Szenarien, in denen die Orchestrierungsversionierung nicht geeignet ist.

Namensbasierte Versionsverwaltung

Mit dieser Strategie erstellen Sie neue Versionen Ihrer Funktionen zusammen mit den alten Versionen in derselben Funktions-App. Die Version jeder Funktion wird Teil ihres Namens (zum Beispiel MyOrchestrator_v1, MyOrchestrator_v2). Da frühere Versionen beibehalten werden, können In-Flight-Orchestrierungsinstanzen weiterhin darauf verweisen. Anforderungen für neue Orchestrierungsinstanzen rufen die neueste Version auf, auf die Ihre Orchestrierungsclientfunktion über eine App-Einstellung verweisen kann. Das folgende Diagramm veranschaulicht diesen Ansatz.

Bei dieser Strategie muss jede Funktion kopiert werden, und die zugehörigen Verweise auf andere Funktionen müssen aktualisiert werden. Sie können dies vereinfachen, indem Sie ein Skript schreiben. Hier ist ein Beispielprojekt mit einem Migrationsskript.

Statusüberprüfung mit Slot

Während die aktuelle Version Ihrer Funktions-App in Ihrem Produktionsslot ausgeführt wird, stellen Sie die neue Version der Funktions-App in Ihrem Stagingslot bereit. Überprüfen Sie vor dem Austauschen Ihrer Produktions- und Stagingslots, ob aktuell ausgeführte Orchestrierungsinstanzen vorhanden sind. Nachdem die Vorgänge für alle Orchestrierungsinstanzen abgeschlossen wurden, können Sie das Austauschen durchführen. Diese Strategie funktioniert, wenn Sie über vorhersagbare Zeiträume verfügen, in denen keine Orchestrierungsinstanzen ausgeführt werden. Dies ist der beste Ansatz, wenn Ihre Orchestrierungen nicht zeitintensiv sind und sich Ihre Orchestrierungsausführungen nicht häufig überlappen.

Konfiguration von Funktions-Apps

Verwenden Sie das folgende Verfahren, um dieses Szenario einzurichten.

1. Fügen Sie Ihrer Funktions-App für Staging und Produktion Bereitstellungsslots hinzu.

2. Legen Sie für jeden Slot die Anwendungseinstellung AzureWebJobsStorage auf die Verbindung eines freigegebenen Speicherkontos fest. Diese Speicherkontoverbindung wird von der Azure Functions Laufzeit verwendet, um die Zugriffsschlüssel der Funktionen sicher zu speichern. Für die höchste Sicherheit sollten Sie mit Ihrem Speicherkonto eine Verbindung mit einer verwalteten Identität herstellen.

3. Erstellen Sie für jeden Slot eine neue App-Einstellung (z.B. DurableManagementStorage). Legen Sie den zugehörigen Wert auf die Verbindungszeichenfolge unterschiedlicher Speicherkonten fest. Diese Speicherkonten werden von der Durable Functions Erweiterung für zuverlässige Ausführung verwendet. Verwenden Sie ein separates Speicherkonto für jeden Slot. Markieren Sie diese Einstellung nicht als Einstellung für den Bereitstellungsslot. Auch hier gelten Verbindungen unter Verwendung verwalteter Identitäten als am sichersten.

4. Geben Sie im Abschnitt „durableTask“ der Datei „host.json“ Ihrer Funktions-App connectionStringName (Durable 2.x) oder azureStorageConnectionStringName (Durable 1.x) als Namen der App-Einstellung an, die Sie in Schritt 3 erstellt haben.

Die folgende Abbildung zeigt die beschriebene Konfiguration mit Bereitstellungsslots und Speicherkonten. Bei diesem potenziellen Szenario vor der Bereitstellung wird Version 2 einer Funktions-App im Produktionsslot ausgeführt, während Version 1 im Stagingslot verbleibt.

beispiel für host.json

Das folgende JSON-Fragment zeigt die einstellung Verbindungszeichenfolge in der Datei host.json.

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

Konfiguration der CI/CD-Pipeline

Konfigurieren Sie Ihre CI/CD-Pipeline so, dass die Bereitstellung nur dann durchgeführt wird, wenn Ihre Funktions-App nicht über ausstehende oder ausgeführte Orchestrierungsinstanzen verfügt. Wenn Sie Azure Pipelines verwenden, können Sie eine Funktion erstellen, die diese Bedingungen überprüft, wie im folgenden C#-Beispiel. Dasselbe Muster gilt für andere Sprachen – Abfrage von Orchestrierungsinstanzen mit Pending oder Running Status, um festzustellen, ob welche existieren.

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

Konfigurieren Sie als Nächstes das Staging-Gate, damit abgewartet wird, bis keine Orchestrierungen mehr ausgeführt werden. Weitere Informationen finden Sie unter Steuerung von Releasebereitstellungen mit Gates.

Azure Pipelines überprüft Ihre Funktions-App auf ausgeführte Orchestrierungsinstanzen, bevor Ihre Bereitstellung gestartet wird.

Die neue Version Ihrer Funktions-App sollte nun im Stagingslot bereitgestellt worden sein.

Tauschen Sie abschließend die Slots aus.

Anwendungseinstellungen, die nicht als Einstellungen für Bereitstellungsslots gekennzeichnet sind, werden ebenfalls ausgetauscht, sodass Version 2 weiterhin über den Verweis auf Speicherkonto A verfügt. Da der Orchestrierungszustand im Speicherkonto nachverfolgt wird, werden alle Orchestrierungen, die in Version 2 der App ausgeführt werden, im neuen Slot ohne Unterbrechung weiter ausgeführt.

Wenn Sie für beide Slots dasselbe Speicherkonto nutzen möchten, können Sie die Namen Ihrer Aufgabenhubs ändern. In diesem Fall müssen Sie den Zustand Ihrer Slots und die HubName-Einstellungen Ihrer App verwalten. Weitere Informationen finden Sie unter Task Hubs in Durable Functions.

Weiterleitung von Bewerbungen

Diese Strategie ist die komplexeste, aber es ist die einzige Option für Systeme mit kontinuierlich laufenden Orchestrierungen, die nie über ein Leerfenster für Slot-Swaps verfügen.

Für diese Strategie erstellen Sie einen Application Router vor Ihrem Durable Functions , z. B. eine Azure-Funktion mit HTTP-Triggern oder eine API-Verwaltungsinstanz, die basierend auf Versionsheadern weitergeleitet wird. Der Router ist für Folgendes verantwortlich:

• Bereitstellen der Funktions-App.
• Verwalten, welche Version der App aktiv ist.
• Routing von Orchestrierungsanfragen an die korrekte Funktions-App entsprechend der jeweiligen Version.

Beim ersten Empfang einer Orchestrierungsanforderung werden vom Router die folgenden Aufgaben durchgeführt:

1. Erstellt eine neue Funktions-App in Azure.
2. Stellt den Code Ihrer Funktions-App in der neuen Funktions-App in Azure bereit.
3. Weiterleiten der Orchestrierungsanforderung an die neue App

Der Router verwaltet den Zustand in Bezug darauf, welche Version Ihres App-Codes für welche Funktions-App in Azure bereitgestellt wird.

Der Router leitet Bereitstellungs- und Orchestrierungsanforderungen basierend auf der Version, die mit der Anforderung gesendet wurde, an die richtige Funktions-App weiter. Die Patchversion wird ignoriert.

Wenn Sie eine neue Version Ihrer App ohne Breaking Change bereitstellen, können Sie die Patchversion inkrementieren. Der Router führt die Bereitstellung für Ihre vorhandene Funktions-App durch und sendet Anforderungen für die alte und neue Version des Codes, die an dieselbe Funktions-App weitergeleitet werden.

Wenn Sie eine neue Version Ihrer App mit einer Breaking Change bereitstellen, können Sie die Haupt- oder Nebenversion inkrementieren. Anschließend erstellt der Anwendungsrouter eine neue Funktions-App in Azure, stellt sie bereit und leitet Anforderungen für die neue Version Ihrer App an sie weiter. In der folgenden Abbildung werden ausgeführte Orchestrierungen von Version 1.0.1 der App weiterhin ausgeführt, aber Anforderungen für Version 1.1.0 werden an die neue Funktions-App weitergeleitet.

Der Router überwacht den Status von Orchestrierungen der Version 1.0.1 und entfernt die Apps, nachdem alle Orchestrierungen abgeschlossen wurden.

Nachverfolgen von Speichereinstellungen

Für jede Funktions-App sollten separate Zeitplanungswarteschlangen verwendet werden (ggf. in separaten Speicherkonten). Falls Sie übergreifend alle Orchestrierungsinstanzen für alle Versionen Ihrer Anwendung abfragen möchten, können Sie Instanz- und Verlaufstabellen für Ihre gesamten Funktions-Apps gemeinsam nutzen. Sie können Tabellen freigeben, indem Sie die trackingStoreConnectionStringName- und trackingStoreNamePrefix-Einstellungen in der Datei host.json so konfigurieren, dass jeweils die gleichen Werte verwendet werden.

Weitere Informationen finden Sie unter Instanzen verwalten in Durable Functions in Azure.

Nächste Schritte