Strategien für Websiteupdates in Flex Consumption

Wenn Sie Ihre App mit Azure Functions im Flex-Verbrauchsplan hosten, können Sie steuern, wie Updates für ausgeführte Instanzen bereitgestellt werden. Wenn Sie Code bereitstellen, Anwendungseinstellungen ändern oder andere Konfigurationseigenschaften ändern, tritt ein Websiteupdate auf. Der Flex-Verbrauchsplan bietet eine Standortkonfigurationseinstellung (SiteUpdateStrategy), mit der Sie steuern können, ob ihre Funktions-App während dieser Updates Ausfallzeiten erlebt und wie laufende Ausführungen behandelt werden.

Der Flex-Verbrauchsplan unterstützt derzeit diese Updatestrategien:

• Neu erstellen: Funktionen starten alle ausgeführten Instanzen neu, nachdem Sie den Code durch die neueste Version ersetzt haben. Dieser Ansatz kann zu kurzen Ausfallzeiten führen, während Instanzen wiederverwendet und das Standardverhalten von anderen Azure Functions-Hostingplänen beibehalten werden.
• Paralleles Update (Vorschau): Ermöglicht Bereitstellungen ohne Downtime durch Entladen und Ersetzen von Instanzen in Batches. Laufende Ausführungen werden natürlich ohne erzwungene Beendigung abgeschlossen.

Strategievergleich

In dieser Tabelle werden die beiden Strategien für Websiteupdates verglichen:

Aktualisieren von Strategieverhalten

In dieser Tabelle wird der Aktualisierungsprozess der beiden Strategien verglichen:

In dieser Tabelle werden die wichtigsten Merkmale der beiden Strategien verglichen:

Überlegungen zur fortlaufenden Updatestrategie

Beachten Sie diese aktuellen Verhaltensweisen und Einschränkungen bei der Verwendung der Rolling-Update-Strategie. Diese Liste wird während des Vorschauzeitraums beibehalten und kann sich ändern, wenn sich das Datum für die allgemeine Verfügbarkeit der Funktion nähert.

• Plattformverwaltete Parameter: Die Plattform steuert die Parameter (z. B. Batchanzahl, Instanzen pro Batch, Anzahl von Batches und Ablaufintervallen), die das Rollupdateverhalten bestimmen. Diese Parameter können sich vor GA ändern, um die Leistung und Zuverlässigkeit zu optimieren.
• Keine Echtzeitüberwachung: Es gibt derzeit keinen Einblick in die Anzahl der Abflüsse, die Anzahl der verbleibenden Batches oder die aktuellen Statusprozentsätze.
• Kein Abschlusssignal: Sie können jedoch Instanzprotokolle überwachen, um zu schätzen, wann eine Aktualisierung abgeschlossen ist.
• Szenarien mit einer einzelnen Instanz: Apps, die in einer Instanz ausgeführt werden, erleben ähnlich wie bei der Neuerstellung eine kurze Downtime. Laufende Ausführungen werden jedoch noch abgeschlossen.
• Dauerhafte Funktionen: Da das Mischen von Versionen während Updates zu unerwartetem Verhalten in einer dauerhaften Orchestrierung führen kann, verwenden Sie eine explizite Orchestrierungsversionsabgleichsstrategie.
• Infrastruktur als Code: Durch die gleichzeitige Bereitstellung von Code- und Konfigurationsänderungen werden mehrere rollierende Updates ausgelöst, die sich möglicherweise überlappen.
• Abwärtskompatibilität: Stellen Sie sicher, dass Ihre Änderungen während des Übergangszeitraums für rollierende Updates mit der vorherigen Version funktionieren.

Konfigurieren Ihrer Updatestrategie

Sie können die Updatestrategie für Ihre App festlegen, indem Sie die Websiteeinstellung SiteUpdateStrategy verwenden, die ein untergeordnetes Element von functionAppConfig ist. Standardmäßig ist SiteUpdateStrategy.type auf Recreatefestgelegt. Derzeit unterstützen nur Bicep- und ARM-Vorlagen mit API-Version 2023-12-01 oder höher das Ändern dieser Eigenschaft.

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

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

Änderungen an der Websiteaktualisierungsstrategie werden beim nächsten Websiteupdate wirksam. Beispiel: Beim Ändern des Typs (type) von Recreate in RollingUpdate wird die Neuerstellungsstrategie für dieses Update verwendet. Alle nachfolgenden Websiteupdates verwenden dann rollierende Updates.

Überwachen von Websiteupdates

Während der öffentlichen Vorschau gibt es kein eingebautes Signal für den Abschluss von Website-Aktualisierungen. Sie können KQL-Abfragen in Application Insights als bestmöglichen Ansatz verwenden, um den Fortschritt des fortlaufenden Updates zu schätzen.

Überwachung des Fortschritts von rollierenden Updates

Diese KQL-Abfragen bieten eine bestmögliche Schätzung des Fortschritts von parallelen Updates, indem sie die Instanzfluktuation in Application Insights-Protokollen nachverfolgen. Dieser Ansatz hat erhebliche Einschränkungen und sollte nicht für die Produktionsautomatisierung verwendet werden:

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

So verwenden Sie diese Abfrage zur Schätzung:

1. Fügen Sie diese Abfrage im Blatt „Protokolle“ der Application Insights-Ressource ein, die Ihrer Funktions-App zugeordnet ist.
2. Legen Sie deploymentStart auf den Zeitstempel fest, wenn Ihr Website-Update erfolgreich abgeschlossen ist.
3. Führen Sie die Abfrage regelmäßig aus, um den Fortschritt zu schätzen. Legen Sie das Abrufintervall auf mindestens so lange fest, wie die durchschnittliche Ausführungszeit der Funktion dauert, und stellen Sie sicher, dass die checkInterval Variable in der Abfrage mit dieser Abfragehäufigkeit übereinstimmt.
4. Die Abfrage gibt ungefähre Werte zurück:
   • RollingUpdateComplete: Optimale Schätzung, ob alle ursprünglichen Instanzen ersetzt werden
   • PercentComplete: Geschätzter Prozentsatz der ursprünglichen Instanzen, die ersetzt werden
   • OriginalStillActiveCount: Geschätzte Anzahl der noch ausgeführten ursprünglichen Instanzen
   • NewCount: Anzahl der aktuell aktiven neuen Instanzen

Beachten Sie diese Einschränkungen bei der Verwendung dieser Abfragen:

1. Zeitliche Lücke: Die deploymentStart Zeit gibt an, wann Ihr Website-Update erfolgreich ist, aber das tatsächliche Rollout-Update beginnt möglicherweise nicht sofort. Während dieser Lücke stellen alle Ereignisse für die horizontale Skalierung Instanzen bereit, die die ursprüngliche Version ausführen. Da die Abfrage nur Instanzen nachverfolgt, die zu deploymentStart aktiv sind, überwacht sie diese neuen Originalversion-Instanzen nicht, was möglicherweise falsche Vervollständigungssignale verursacht.

2. Protokollbasierte Erkennung: Dieser Ansatz basiert auf Anwendungsprotokollen, um den Instanzstatus zu ableiten, anstatt den Instanzstatus direkt abzufragen. Instanzen können ausgeführt, aber nicht aktiv protokolliert werden, was zu falschen Abschlusssignalen führt, wenn ursprüngliche Instanzen noch aktiv sind, aber keine Protokolle im checkInterval Fenster ausgegeben haben.

Empfehlung für die Produktion: Verwenden sie rollierende Updates, wenn Bereitstellungen ohne Ausfallzeiten kritisch sind. Stellen Sie sicher, dass Ihre Bereitstellungspipelines nicht auf den Abschluss des Updates warten müssen, bevor Sie mit den nachfolgenden Schritten fortfahren. Verwenden Sie "neu erstellen", wenn Sie schnellere und vorhersehbare Aktualisierungszeiten benötigen und kurze Ausfallzeiten tolerieren können.

Häufig gestellte Fragen

Ich bin an Bereitstellungsslots für unterbrechungsfreie Bereitstellungen gewöhnt. Wie unterscheiden sich rollierende Updates?

• Im Gegensatz zu Bereitstellungsplätzen benötigen rollierende Updates keine zusätzliche Infrastruktur. Setzen Sie siteUpdateStrategy.type auf "RollingUpdate" für Bereitstellungen ohne Ausfallzeiten.
• Parallele Updates bewahren laufende Ausführungen, während Bereitstellungsslots sie während des Austauschs beenden. Bestimmte Standorteigenschaften und statische Einstellungen können nicht ausgetauscht werden und erfordern eine direkte Änderung des Produktionsslots.
• Im Gegensatz zu Bereitstellungsslots bieten parallele Updates keine separate Umgebung für Canary-Tests und keine Möglichkeit, einen Prozentsatz des Livedatenverkehrs umzuleiten. Wenn Sie diese Features benötigen, verwenden Sie einen Plan, der Bereitstellungsslots unterstützt, etwa Elastisch Premium. Oder verwalten Sie separate Flex-Verbrauchs-Apps hinter einer Traffic Manager-Instanz.

Wie kann ich ein Rollback für ein Websiteupdate durchführen?

• Es gibt derzeit kein Feature zum Zurücksetzen eines Websiteupdates. Wenn ein Rollback erforderlich ist, initiieren Sie ein weiteres Websiteupdate mit dem vorherigen Code- oder Konfigurationsstatus.

Wie werden Timertrigger behandelt?

• Timertrigger behalten ihren Singleton-Charakter. Sobald eine durch einen Timer ausgelöste Funktions-App für das Entladen markiert ist, werden neue Timerfunktionen in der aktuellen Version ausgeführt.

Während des rollierenden Updates werden Laufzeitfehler angezeigt... Was ist schief gegangen?

• Wenn neue Instanzen nicht starten oder auf Laufzeitfehler stoßen, liegt das Problem wahrscheinlich im Anwendungscode, bei den Abhängigkeiten, den Konfigurationseinstellungen oder den Umgebungsvariablen, die geändert wurden.
• Um das Problem zu beheben, stellen Sie Ihre letzte bekannte fehlerfreie Version erneut bereit, um die Laufzeit wiederherzustellen. Testen Sie dann die vorgeschlagenen Änderungen in einer Entwicklungs- oder Staging-Umgebung, bevor Sie die Wiederholung vornehmen. Überprüfen Sie Fehlerprotokolle, um zu ermitteln, welche bestimmte Änderung das Problem verursacht hat.

Nächste Schritte

• Erfahren Sie mehr über den Flex-Verbrauchsplan
• Erfahren Sie mehr darüber, wie sich Bereitstellungen im flexiblen Verbrauchsmodell unterscheiden
• Lernen Sie, wie Sie Infrastruktur-als-Code-Vorlagen schreiben