Wiederherstellung nach einer fehlerhaften App-Bereitstellung in einem Flex Consumption-Plan

Wenn eine Bereitstellung einen Fehler einführt, benötigen Sie eine Möglichkeit, schnell wiederherzustellen. In diesem Artikel wird erläutert, wie Sie sich mithilfe eines Prozesses für kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) von einer fehlerhaften Bereitstellung für eine Flex Consumption-Funktions-App erholen können. Dieser Prozess umfasst die folgenden Wiederherstellungsmethoden:

Diese Strategien stellen sowohl Ihren Funktions-App-Code als auch die App-Einstellungen wieder her, sodass Ihre Konfigurationsänderungen mit Codeänderungen wiederhergestellt werden können.

Warum Sie CI/CD zum Wiederherstellen einer Bereitstellung benötigen

Wenn Sie Code für Ihre Flex-Verbrauchsplan-App bereitstellen:

• Ihr Code wird als ZIP-Paket in einem Blob Storage-Container bereitgestellt, der beim Start eingebunden wird.
• Jede Bereitstellung überschreibt das aktuelle Paket.
• Die Plattform behält keinen integrierten Überarbeitungsverlauf bei, um frühere Versionen beizubehalten.
• Die Funktion Bereitstellungsslots wird derzeit nicht unterstützt.
• App-Einstellungen werden separat über das Azure Portal, die CLI oder den Infrastruktur-as-Code (IaC) angewendet, und die Plattform kann sie nicht in einem vorherigen Zustand wiederherstellen.

Dieses Verhalten bei der Bereitstellung schränkt Ihre Möglichkeiten ein, Ihre App im Flex Consumption-Plan nach einer fehlerhaften Bereitstellung wiederherzustellen.

Ihr Git-Verlaufs- und CI/CD-Prozess bieten die einzige Möglichkeit, Codebereitstellungen zu einem bestimmten Zeitpunkt nachzuverfolgen. Wenn Sie eine Bereitstellung erstellen, die sowohl Code als auch Konfiguration umfasst, können Sie sich von einer fehlerhaften Veröffentlichung erholen, indem Sie den nächsten Durchlauf auf einen bekannten funktionierenden Commit verweisen.

Weitere Informationen zum Flex Consumption-Bereitstellungsmodell finden Sie unter Flex Consumption-Plan und Standortupdates im Flex Consumption-Plan.

Voraussetzungen

• Eine vorhandene Funktions-App, die in einem Flex Consumption-Plan in Azure bereitgestellt wird.

• Quellcode in einem Git-Repository. Verwenden Sie Git-Tags oder zeichnen Sie Commit-SHAs für jedes Release auf, damit Sie schnell erkennen können, worauf Sie zurücksetzen müssen.

• Eine für Ihre Funktions-App konfigurierte Bereitstellung:

  • GitHub-Aktionen
  • Azure-Pipelines

  Ein Workflow, der mit der OIDC-Authentifizierung konfiguriert ist, wie in der kontinuierlichen Übermittlung mithilfe von GitHub Actions beschrieben. Der Workflow muss azure/login verwenden. Die Authentifizierung per Veröffentlichungsprofil unterstützt die in diesem Handbuch verwendeten az cli Befehle nicht.

Bereiten Sie Ihre Bereitstellung für die Verwaltung von App-Einstellungen vor

Bevor Sie ein vollständiges Rollback ausführen können, müssen Sie die App-Einstellungen in die Quellcodeverwaltung setzen und sie als Teil Der Bereitstellung anwenden. Mit diesem Ansatz können Sie Code und Konfiguration in einer einzigen erneuten Ausführung wiederherstellen, erfordert jedoch zusätzliche Schritte, z. B. das Anwenden von Einstellungen, das Warten auf Neustarts und das Bereinigen nicht deklarierter Werte.

In diesem Abschnitt werden zwei Ansätze zum Verwalten von App-Einstellungen als Teil der Bereitstellung erläutert:

Allgemeine Informationen zu App-Einstellungen finden Sie in der App-Einstellungsreferenz für Azure Functions.

Überlegungen zu App-Einstellungen

Beachten Sie diese Überlegungen beim Arbeiten mit der programmgesteuerten Konfiguration von App-Einstellungen.

• Beide Ansätze in diesem Abschnitt behandeln Ihre Einstellungsdatei als den vollständigen gewünschten Zustand. Sie entfernen bei jeder Bereitstellung alle App-Einstellungen aus der App, die nicht in der Datei deklariert sind. Schließen Sie immer alle erforderlichen Einstellungen ein, um eine Unterbrechung Ihrer App zu vermeiden.

• Behandeln Sie app-settings.json und Änderungen an Bicep-Dateivorlagen mit derselben Sorgfalt wie Codeänderungen. Überprüfen Sie Die Einstellungenänderungen in Pullanforderungen, um Konfigurationsfehler abzufangen, bevor sie die Produktion erreichen.

• Um optimale Sicherheit zu gewährleisten, befolgen Sie die folgenden Richtlinien für Ihre Verbindungen:

  • Verwenden Sie verwaltete Identitätsverbindungen nach Möglichkeit. Richten Sie identitätsbasierte Verbindungen für Hostspeicher (AzureWebJobsStorage), Bereitstellungsspeicher und Trigger-/Bindungsverbindungen ein. Weitere Informationen finden Sie unter Konfigurieren von Bereitstellungseinstellungen.

    • Verwenden Sie Key Vault-Referenzen, wenn Geheimnisse unvermeidbar sind. Key Vault speichert Ihre Geheimnisse sicher. Anstatt geheime Schlüssel direkt zu speichern, können Sie einen Verweis verwenden, um sicher auf den erforderlichen geheimen Schlüssel zur Laufzeit zuzugreifen. Weitere Informationen finden Sie unter Verweise auf Key Vault verwenden.

• Wenn Sie CI/CD verwenden, löst jede Änderung an ihren App-Einstellungen oder ihrem Code ein separates Websiteupdate aus. Standardmäßig erzeugt dieser Bereitstellungsprozess mindestens zwei Websiteupdates: zuerst, wenn Einstellungen angewendet werden, und dann, wenn Code bereitgestellt wird. Verwenden Sie für Bereitstellungen ohne Ausfallzeiten stattdessen eine rollierende Updatestrategie , bei der Instanzen in Batches entwässert und ersetzt werden. Weitere Informationen finden Sie unter Websiteaktualisierungen im Flex Consumption-Plan.

Konfigurieren von App-Einstellungen im Workflow

Führen Sie die folgenden grundlegenden Schritte aus, um Ihrer Projektbereitstellung eine Konfigurationsdatei für App-Einstellungen hinzuzufügen:

1. Erstellen Sie eine JSON-Datei in Ihrem Repository, z. B. in infra/app-settings.json. Diese Datei muss alle erforderlichen App-Einstellungen in einem JSON-Format enthalten, das wie im folgenden Beispiel aussieht:

   [
     {
       "name": "FUNCTIONS_EXTENSION_VERSION",
       "value": "~4"
     },
     {
       "name": "FUNCTIONS_WORKER_RUNTIME",
       "value": "dotnet-isolated"
     },
     {
       "name": "APPLICATIONINSIGHTS_CONNECTION_STRING",
       "value": "InstrumentationKey=00000000-..."
     },
     {
       "name": "AzureWebJobsStorage__blobServiceUri",
       "value": "https://mystorageaccount.blob.core.windows.net"
     },
     {
       "name": "AzureWebJobsStorage__queueServiceUri",
       "value": "https://mystorageaccount.queue.core.windows.net"
     },
     {
       "name": "AzureWebJobsStorage__tableServiceUri",
       "value": "https://mystorageaccount.table.core.windows.net"
     },
     {
       "name": "MyFeatureFlag",
       "value": "true"
     },
     {
       "name": "ServiceBus__fullyQualifiedNamespace",
       "value": "my-namespace.servicebus.windows.net"
     }
   ]
   

2. Fügen Sie in Ihrer spezifischen Bereitstellungsdefinition Schritte hinzu, mit denen die Einstellungen angewendet werden, bevor die Codebereitstellung erfolgt, wobei zwischen ihnen eine Pause von 30 Sekunden erfolgt.

In den folgenden Abschnitten werden spezifische Bereitstellungsbeispiele mit beiden Ansätzen bereitgestellt.

Beispiel: Bereitstellung von app-settings.json

In diesem Bereitstellungsbeispiel wird gezeigt, wie Sie Ihre Bereitstellung so konfigurieren, dass sie eine Konfiguration enthält. Wählen Sie die Registerkarte aus, die Ihrer CI/CD-Methode entspricht.

  deploy:
    needs: build
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v4

      - name: 'Download artifact from build job'
        uses: actions/download-artifact@v4
        with:
          name: ${{ env.BUILD_ARTIFACT_NAME }}
          path: ./downloaded-artifact

      - name: 'Log in to Azure'
        uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

      - name: 'Apply app settings'
        run: |
          az functionapp config appsettings set \
            --name ${{ env.AZURE_FUNCTIONAPP_NAME }} \
            --resource-group ${{ env.RESOURCE_GROUP }} \
            --settings @infra/app-settings.json

      - name: 'Wait for settings restart'
        run: sleep 30

      - name: 'Deploy code'
        uses: Azure/functions-action@v1
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: ./downloaded-artifact

      - name: 'Remove undeclared app settings'
        run: |
          DESIRED=$(jq -r '.[].name' infra/app-settings.json)
          CURRENT=$(az functionapp config appsettings list \
            --name ${{ env.AZURE_FUNCTIONAPP_NAME }} \
            --resource-group ${{ env.RESOURCE_GROUP }} \
            --query "[].name" -o tsv)
          TO_DELETE=""
          for setting in $CURRENT; do
            if ! echo "$DESIRED" | grep -qx "$setting"; then
              TO_DELETE="$TO_DELETE $setting"
            fi
          done
          if [ -n "$TO_DELETE" ]; then
            az functionapp config appsettings delete \
              --name ${{ env.AZURE_FUNCTIONAPP_NAME }} \
              --resource-group ${{ env.RESOURCE_GROUP }} \
              --setting-names $TO_DELETE
          fi

- task: AzureCLI@2
  displayName: 'Apply app settings'
  inputs:
    azureSubscription: '$(SERVICE_CONNECTION)'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az functionapp config appsettings set \
        --name $(FUNCTION_APP_NAME) \
        --resource-group $(RESOURCE_GROUP) \
        --settings @infra/app-settings.json

- script: sleep 30
  displayName: 'Wait for settings restart'

- task: AzureFunctionApp@2
  displayName: 'Deploy code'
  inputs:
    azureSubscription: '$(SERVICE_CONNECTION)'
    appType: 'functionAppLinux'
    isFlexConsumption: true
    appName: '$(FUNCTION_APP_NAME)'
    package: '$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip'
    deploymentMethod: 'auto'

- task: AzureCLI@2
  displayName: 'Remove undeclared app settings'
  inputs:
    azureSubscription: '$(SERVICE_CONNECTION)'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      DESIRED=$(jq -r '.[].name' infra/app-settings.json)
      CURRENT=$(az functionapp config appsettings list \
        --name $(FUNCTION_APP_NAME) \
        --resource-group $(RESOURCE_GROUP) \
        --query "[].name" -o tsv)
      TO_DELETE=""
      for setting in $CURRENT; do
        if ! echo "$DESIRED" | grep -qx "$setting"; then
          TO_DELETE="$TO_DELETE $setting"
        fi
      done
      if [ -n "$TO_DELETE" ]; then
        az functionapp config appsettings delete \
          --name $(FUNCTION_APP_NAME) \
          --resource-group $(RESOURCE_GROUP) \
          --setting-names $TO_DELETE
      fi

Definieren Sie Einstellungen in einer Bicep-Bereitstellung

Verwalten Sie app-Einstellungen für IaC-Bereitstellungen direkt in der Bicep-Vorlage. Bicep ersetzt bei jeder Bereitstellung nativ die gesamte siteConfig.appSettings-Sammlung, ohne dass ein separater Bereinigungsschritt nötig ist. Es unterstützt auch die Drifterkennung durch die Verwendung von what-if.

Wenn Sie nur den Abschnitt "App-Einstellungen" Ihrer Bicep-Datei aktualisieren, bleiben alle anderen Azure Ressourcen während der Bereitstellung unverändert. Dieser Artikel behandelt die Erstellung mit Bicep nicht umfassend. Vollständige Vorlagen für den Flex Consumption-Plan finden Sie unter die Azure Functions-Infrastruktur als Code.

Dies ist das relevante Fragment der Bicep-Vorlage (nur der appSettings Teil):

siteConfig: {
  appSettings: [
    {
      name: 'MyFeatureFlag'
      value: 'true'
    }
    {
      name: 'ServiceBus__Connection'
      value: '@Microsoft.KeyVault(SecretUri=https://my-vault.vault.azure.net/secrets/sb-conn)'
    }
  ]
}

Fügen Sie Schritte zum Bereitstellen der Bicep-Vorlage vor der Codebereitstellung hinzu, mit einer Wartezeit von 30 Sekunden dazwischen. Das Aktualisieren von App-Einstellungen über Bicep ist asynchron. Die App startet neu, um die neuen Werte aufzunehmen, und das Bereitstellen von Code während des Neustarts kann fehlschlagen.

      - name: 'Deploy infrastructure'
        run: |
          az deployment group create \
            --resource-group ${{ env.RESOURCE_GROUP }} \
            --template-file infra/main.bicep \
            --parameters appName=${{ env.AZURE_FUNCTIONAPP_NAME }}

      - name: 'Wait for settings restart'
        run: sleep 30

      - name: 'Deploy code'
        uses: Azure/functions-action@v1
        with:
          app-name: ${{ env.AZURE_FUNCTIONAPP_NAME }}
          package: ./downloaded-artifact

- task: AzureCLI@2
  displayName: 'Deploy infrastructure'
  inputs:
    azureSubscription: '$(SERVICE_CONNECTION)'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az deployment group create \
        --resource-group $(RESOURCE_GROUP) \
        --template-file infra/main.bicep \
        --parameters appName=$(FUNCTION_APP_NAME)

- script: sleep 30
  displayName: 'Wait for settings restart'

- task: AzureFunctionApp@2
  displayName: 'Deploy code'
  inputs:
    azureSubscription: '$(SERVICE_CONNECTION)'
    appType: 'functionAppLinux'
    isFlexConsumption: true
    appName: '$(FUNCTION_APP_NAME)'
    package: '$(System.DefaultWorkingDirectory)/build$(Build.BuildId).zip'
    deploymentMethod: 'auto'

Zurücksetzen einer Bereitstellung

Ein Rollback bedeutet, dass eine vorherige erfolgreiche Ausführung noch einmal ausgeführt wird. Eine erneute Ausführung checkt die ursprüngliche Commit-SHA aus, die diesen Lauf ausgelöst hat (nicht den aktuellen HEAD des Branches), sodass der Code und die Einstellungsdatei aus diesem Zeitpunkt neu gebaut und bereitgestellt werden. Sie benötigen keine neuen Commits.

So führen Sie ein Rollback einer Bereitstellung durch erneutes Ausführen einer vorherigen erfolgreichen Ausführung durch:

Was durch erneutes Ausführen neu erstellt wird

Die erneute Ausführung erstellt den Code aus dem alten Commit neu. Das ursprüngliche binäre Artefakt wird nicht wiederverwendet. Dieses Verhalten bedeutet:

• Bei angehefteten Abhängigkeitssperrdateien (package-lock.json, requirements.txtusw.) ist die Ausgabe funktionell identisch.
• Die Buildzeit ist identisch mit einer normalen Bereitstellung. Es geschieht nicht sofort.
• Externe Abhängigkeiten, die zur Buildzeit abgerufen werden (NuGet, npm, pip) müssen weiterhin verfügbar sein.

Aspekte beim Rollback

• Heften Sie Die Abhängigkeitssperrdateien (package-lock.jsonoder requirements.txtgesperrte .csproj Versionen) in der Quellcodeverwaltung an. Festgeschriebene Lockfiles stellen sicher, dass das erneute Ausführen einer Bereitstellung unabhängig vom Zeitpunkt der Wiederholung einen funktional identischen Build erzeugt.

• Bei der erneuten Ausführung wird der Workflow oder die Pipeline YAML aus dem ursprünglichen Commit verwendet. Geheime und Pipelinevariablen werden jedoch zum Zeitpunkt der erneuten Ausführung in ihre aktuellen Werte aufgelöst. Wenn Sie Ihre Geheimnisse zwischen dem ursprünglichen Durchlauf und einem erneuten Durchlauf rotieren, wird der neue geheime Wert verwendet.

• Ein erneuter Durchlauf versetzt Ihre bereitgestellte App wieder in einen bekanntermaßen funktionsfähigen Zustand zurück, ändert jedoch nichts an Ihrem Git-Verlauf. Der HEAD Ihres Branches verweist weiterhin auf den fehlerhaften Commit.

• Was durch erneutes Ausführen nicht wiederhergestellt wird:

  • Azure-Ressourcenkonfiguration, die außerhalb Ihrer Bereitstellung verwaltet wird, einschließlich Hostingplänen, Netzwerkkonfigurationen und Identitätszuweisungen.
  • Daten- oder Schemaänderungen in nachgeschalteten Diensten, z. B. Datenbanken, Nachrichtenwarteschlangen und Speicher.
  • Geheimniswerte in Key Vault. Nur Key Vault Verweise werden in der Quellcodeverwaltung verwaltet. Das Drehen geheimer Schlüssel ist ein Key Vault Vorgang.

• Testen Sie den Rollbackvorgang regelmäßig. Warten Sie nicht auf einen Vorfall in der Produktionsumgebung, um festzustellen, dass etwas nicht funktioniert.

Korrigieren der Verzweigung nach einem Rollback

Da der nächste durch einen Push ausgelöste Durchlauf den fehlerhaften Commit erneut ausrollt, sehen andere Entwickler, die den Branch pullen, weiterhin den fehlerhaften Code. Sie müssen diese Situation mit einer der folgenden Aktionen beheben:

• Erstellen Sie einen Hotfix-Commit, der das Problem behebt, bei dem es sich im Wesentlichen um einen Roll-Forward-Vorgang handelt.
• Führen Sie ein git revert aus, um den fehlerhaften Commit rückgängig zu machen, wobei ein neuer Commit erstellt wird, was ebenfalls eine Roll-forward-Aktion ist.
• Eine Branchrichtlinie, die das Zusammenführen verhindert, bis Sie das Problem beheben.

Bis Sie eine dieser Aktionen abgeschlossen haben, vermeiden Sie, dass eine neue Ausführung auf dieser Verzweigung ausgelöst wird. Anleitungen zur Überprüfung finden Sie unter "Überprüfen vor dem Zusammenführen".

Eine Bereitstellung vorwärts ausführen

„Rolling forward“ bedeutet, einen neuen Commit zu pushen, um das Problem zu beheben. Die fehlerhafte Bereitstellung bleibt live, bis der Fix bereitgestellt wird, sodass diese Strategie am besten funktioniert, wenn die App während dieser Zeit beeinträchtigtes Verhalten tolerieren kann.

1. Erstellen Sie einen Fix-Commit auf Ihrem Branch. Diese Korrektur kann wie folgt aussehen:

   • Ein Hotfix , der das Problem direkt behebt.
   • Ein git revert <bad-commit-sha>, der einen neuen Commit erstellt, der fehlerhafte Änderungen rückgängig macht. git revert Obwohl der Code umgekehrt wird, ist es ein Roll forward, da er einen neuen Commit erzeugt und eine neue Bereitstellung auslöst.

2. Wenn der Fix auch Konfigurationsänderungen erfordert, aktualisieren Sie ihre App-Einstellungen (entweder in app-settings.json oder in Ihrer Bicep Vorlage) im gleichen Commit.

3. Pushen Sie den Commit. Ihre Bereitstellung erstellt und stellt den Fix automatisch bereit.

Überprüfen vor dem Zusammenführen

Unabhängig von Ihrer Wiederherstellungsstrategie überprüfen und korrigieren Sie Commits, bevor Sie sie in Ihren Produktionszweig zusammenführen, um das Problem nicht noch zu verschärfen.

Diese Empfehlungen gelten, unabhängig davon, ob Sie die Verzweigung nach einem Rollback proaktiv voranbringen oder korrigieren:

• Verwenden Sie eine Staging-Umgebung: Da der Flex Consumption-Plan derzeit keine Bereitstellungsslots unterstützt, sollten Sie stattdessen erwägen, in einer separaten App mit Flex Consumption-Plan bereitzustellen, um Ihre Fehlerbehebung zu validieren, bevor Sie die Änderungen mit dem Produktionsbranch zusammenführen.

• Automatisieren von Integritätsprüfungen: Fügen Sie einen Schritt nach der Bereitstellung hinzu, der einen Endpunkt für die Integritätsprüfung in Ihrer App aufruft, und überprüft eine positive Antwort. Bei einem Fehler sollten Sie erwägen, eine erneute Ausführung des zuvor erfolgreichen Durchlaufs auszulösen, um automatisch ein Rollback durchzuführen.

• Überwachen nach der Bereitstellung: Einrichten von Application Insights-Warnungen zur Regressionserkennung. Die frühzeitige Erkennung reduziert die Auswirkungen einer schlechten Bereitstellung.

Verwandte Inhalte

• Continuous Delivery mit GitHub Actions
• Kontinuierliche Bereitstellung mithilfe von Azure Pipelines
• Flex-Verbrauchstarif
• Azure Functions Infrastruktur als Code
• Verwalten Ihrer Funktions-App