Herstellen na een slechte implementatie van een Flex Consumption-plan-app

Wanneer een implementatie een fout introduceert, hebt u een manier nodig om snel te herstellen. In dit artikel leest u hoe u herstelt van een slechte implementatie naar een Flex Consumption-functie-app met behulp van een CI/CD-proces (continue integratie en continue implementatie). Dit proces omvat de volgende herstelmethoden:

Herstelmethode Snelheid Wanneer gebruiken Beschrijving
Vorige geslaagde uitvoering opnieuw uitvoeren (terugdraaien) Snelst Bekende goede versie bestaat, of er zijn geen gegevens of statuswijzigingen tussen versies Selecteer een vorige uitvoering en voer deze opnieuw uit en wacht vervolgens op build en implementatie.
git revert en vervolgens git push (vooruitdraaien) Moderate De oplossing is eenvoudig, anders kan de externe toestand niet worden teruggezet Identificeer de commit die de fout veroorzaakt, draai deze terug en push. Wacht vervolgens op dezelfde build- en implementatietijd.
git commit een hotfix en vervolgens git push (vooruitrollen) Langzaamst De hoofdoorzaak is bekend en heeft een gerichte oplossing nodig De hoofdoorzaak identificeren; een oplossing maken, beoordelen, testen en samenvoegen; en wacht totdat het bouwen en implementeren is voltooid.

Deze strategieën herstellen zowel de code van uw functie-app als de app-instellingen, zodat uw configuratiewijzigingen kunnen worden hersteld met codewijzigingen.

Waarom u CI/CD nodig hebt om een implementatie te herstellen

Wanneer u code implementeert in uw Flex Consumption-abonnements-app:

  • Uw code wordt als ZIP-pakket gedeployed in een blobopslagcontainer, die bij het opstarten wordt gekoppeld.
  • Bij elke implementatie wordt het huidige pakket overschreven.
  • Het platform bewaart geen ingebouwde revisiegeschiedenis om eerdere versies te behouden.
  • De functie implementatiesites wordt momenteel niet ondersteund.
  • App-instellingen worden afzonderlijk toegepast via de Azure portal, CLI of infrastructuur als code (IaC) en het platform kan deze niet herstellen naar een eerdere status.

Deze implementatiegedrag beperkt uw opties voor het herstellen van uw Flex Consumption-abonnements-app vanaf een slechte implementatie.

Uw Git-geschiedenis en CI/CD-proces bieden de enige manier om code-implementaties op een bepaald moment bij te houden. Door een implementatie te bouwen die zowel code als configuratie bevat, kunt u herstellen van een slechte release door de volgende uitvoering aan te wijzen bij een bekende goede doorvoering.

Zie Flex Consumption-plan en Site-updates in het Flex Consumption-plan voor meer informatie over het implementatiemodel van Flex Consumption.

Prerequisites

  • Een bestaande functie-app die is geïmplementeerd in een Flex Consumption-abonnement in Azure.

  • Broncode in een Git-opslagplaats. Gebruik Git-tags of leg voor elke release commit-SHA's vast, zodat u snel kunt bepalen waarop u kunt terugvallen.

  • Een implementatie die is geconfigureerd voor uw functie-app:

    Een werkstroom die is geconfigureerd met OIDC-verificatie, zoals beschreven in Continue levering met behulp van GitHub Actions. De workflow moet azure/login gebruiken. Verificatie voor publicatieprofielen biedt geen ondersteuning voor de az cli opdrachten die in deze handleiding worden gebruikt.

Uw implementatie voorbereiden voor het beheren van app-instellingen

Voordat u een volledige terugdraaiactie kunt uitvoeren, moet u uw app-instellingen in broncodebeheer plaatsen en deze toepassen als onderdeel van uw implementatie. Hoewel u met deze methode zowel code als configuratie in één nieuwe uitvoering kunt herstellen, zijn er extra stappen vereist, zoals het toepassen van instellingen, het wachten op opnieuw opstarten en het opschonen van niet-declaratiewaarden.

Tip

Wanneer uw implementatie geen instellingen bevat, kunt u alleen de geïmplementeerde code terugdraaien, maar niet de configuratie.

In deze sectie worden twee benaderingen beschreven voor het beheren van app-instellingen als onderdeel van uw implementatie:

Approach In de werkstroom (Azure CLI) In de servicedefinitie (Bicep)
Hoe werkt het? Implementatiestappen passen instellingen toe uit een JSON-bestand met behulp van az functionapp config appsettingsen verwijder vervolgens niet-declaratieve instellingen Bicep sjabloon declareert instellingen in siteConfig.appSettings; ARM vervangt de volledige verzameling bij de implementatie
Complexiteit Gematigd. JSON-bestand plus extra CLI-stappen in uw werkstroom Hoger. Vereist kennis van Bicep
Driftdetectie Nee. Ja (what-if)
Het beste voor Aan de slag, kleine teams Productieklare, multi-omgevings-, complexe infrastructuur

Zie de naslaginformatie over app-instellingen voor Azure Functions voor meer algemene informatie over app-instellingen.

Overwegingen voor app-instellingen

Let op deze overwegingen bij het werken met programmatische configuratie van app-instellingen.

Important

Als u niet alle vereiste instellingen opneemt met behulp van beide benaderingen, kan uw geïmplementeerde app worden verbroken.

  • Beide benaderingen in deze sectie behandelen uw instellingenbestand als de volledige gewenste status. Ze verwijderen alle app-instellingen die niet in het bestand zijn gedeclareerd uit de app bij elke implementatie. Neem altijd alle vereiste instellingen op om te voorkomen dat uw app wordt onderbroken.

  • Behandel app-settings.json en wijzigingen in Bicep-bestandssjablonen net zo kritisch als codewijzigingen. Controleer instellingenwijzigingen in pull-aanvragen om configuratiefouten te ondervangen voordat ze productie bereiken.

  • Volg deze richtlijnen voor uw verbindingen voor optimale beveiliging:

    • Gebruik waar mogelijk beheerde identiteitverbindingen. Stel op identiteit gebaseerde verbindingen in voor hostopslag (AzureWebJobsStorage), implementatieopslag en trigger-/bindingsverbindingen. Zie Implementatie-instellingen configureren voor meer informatie.

      • Gebruik Key Vault verwijzingen wanneer geheimen onvermijdelijk zijn. Key Vault uw geheimen veilig opslaat. In plaats van geheimen rechtstreeks op te slaan, kunt u een verwijzing gebruiken om tijdens runtime veilig toegang te krijgen tot het vereiste geheim. Zie Key Vault-verwijzingen gebruiken voor meer informatie.

  • Wanneer u CI/CD gebruikt, verandert elke wijziging in uw app-instellingen of activeert uw code een afzonderlijke site-update. Dit implementatieproces produceert standaard ten minste twee site-updates: eerst wanneer instellingen worden toegepast en vervolgens wanneer code wordt geïmplementeerd. Voor implementaties zonder downtime gebruikt u in plaats daarvan een strategie voor rolling updates , waarbij exemplaren worden leeggemaakt en vervangen in batches. Zie Site-updates in het Flex Consumption-abonnement voor meer informatie.

App-instellingen configureren in de werkstroom

Gebruik deze basisstappen om een configuratiebestand voor app-instellingen toe te voegen aan uw projectimplementatie:

  1. Maak een JSON-bestand in uw opslagplaats, zoals in infra/app-settings.json. Dit bestand moet alle vereiste app-instellingen bevatten in een JSON-indeling die eruitziet als in het volgende voorbeeld:

    [
  {
    "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. Voeg in uw specifieke implementatiedefinitie stappen toe die de instellingen toepassen voordat de code-implementatie plaatsvindt, met een pauze van 30 seconden ertussen.

De volgende secties bevatten specifieke implementatievoorbeelden met behulp van beide benaderingen.

Voorbeeld: app-settings.json implementatie

In dit implementatievoorbeeld ziet u hoe u uw implementatie zo configureert dat deze configuratie bevat. Kies het tabblad dat overeenkomt met uw CI/CD-methode.

Voeg de volgende stappen toe aan de deploy taak in uw werkstroom. Voeg actions/checkout@v4 toe aan de deploy-taak, zodat infra/app-settings.json beschikbaar is, en voeg RESOURCE_GROUP toe aan je env-blok op workflowniveau. De stappen passen eerst instellingen toe, wachten tot het opnieuw opstarten is uitgevoerd, code implementeren en vervolgens niet-declaratieve instellingen opschonen.

  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

De azure/login@v2 stap in de werkstroom op basis van OIDC biedt de verificatie die nodig is voor de az cli opdrachten.

Instellingen definiëren in een Bicep-implementatie

Voor IaC-implementaties beheert u app-instellingen rechtstreeks in de Bicep-sjabloon. Bicep vervangt standaard bij elke implementatie de volledige verzameling siteConfig.appSettings, zonder dat daarvoor een afzonderlijke opschoonstap nodig is. Het ondersteunt ook driftdetectie met behulp van what-if.

Wanneer u alleen de sectie met app-instellingen van uw Bicep-bestand bijwerkt, blijven alle andere Azure resources ongewijzigd tijdens de implementatie. Dit artikel behandelt niet het schrijven van Bicep-code van begin tot eind. Zie Azure Functions-infrastructuur als code voor volledige Flex Consumption-sjablonen.

Hier volgt het relevante fragment van de Bicep-sjabloon (alleen het appSettings gedeelte):

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

Voeg stappen toe voor het implementeren van de Bicep-sjabloon vóór de code-implementatie, met een wachttijd van 30 seconden tussendoor. Het bijwerken van app-instellingen via Bicep is asynchroon. De app wordt opnieuw opgestart om de nieuwe waarden op te halen en het implementeren van code tijdens het opnieuw opstarten kan mislukken.

      - 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

Een implementatie terugdraaien

Terugdraaien betekent dat een eerdere succesvolle run opnieuw wordt uitgevoerd. Bij een heruitvoering wordt de oorspronkelijke commit-SHA uitgecheckt waarmee die uitvoering is gestart (niet de huidige HEAD van de branch), zodat de code en het instellingenbestand van dat moment opnieuw worden gebouwd en gedeployed. U hebt geen nieuwe commits nodig.

Een implementatie terugdraaien door een vorige geslaagde uitvoering opnieuw uit te voeren:

  1. Ga naar het tabblad Acties in uw GitHub opslagplaats.
  2. Zoek de laatste geslaagde werkstroomuitvoering vóór de slechte implementatie.
  3. Selecteer Alle taken opnieuw uitvoeren.
  4. De workflow checkt de commit van die uitvoering uit, bouwt opnieuw, rolt de code uit en synchroniseert de app-instellingen vanuit de app-settings.json van die commit.

Wat opnieuw uitvoeren opnieuw opbouwt

De code wordt bij de heruitvoering opnieuw opgebouwd vanaf de oude commit. Het oorspronkelijke binaire artefact wordt niet opnieuw gebruikt. Dit gedrag betekent:

  • Met vastgemaakte afhankelijkheidsvergrendelingsbestanden (package-lock.jsonenzovoort requirements.txt) is de uitvoer functioneel identiek.
  • De buildtijd is hetzelfde als een normale implementatie. Het gebeurt niet onmiddellijk.
  • Externe afhankelijkheden die zijn opgehaald tijdens de build (NuGet, npm, pip) moeten nog steeds beschikbaar zijn.

Overwegingen bij het terugdraaien

  • Leg uw lockbestanden voor afhankelijkheden (package-lock.json, requirements.txt of vergrendelde .csproj-versies) vast in versiebeheer. Vastgemaakte vergrendelingsbestanden zorgen ervoor dat het opnieuw uitvoeren van een implementatie een functioneel identieke build produceert, ongeacht wanneer de nieuwe uitvoering plaatsvindt.

  • Bij opnieuw uitvoeren wordt de YAML van de oorspronkelijke commit voor de workflow of pijplijn gebruikt. Geheimen en pijplijnvariabelen worden echter omgezet in hun huidige waarden op het moment dat ze opnieuw worden uitgevoerd. Wanneer u uw geheimen tussen de oorspronkelijke uitvoering en een nieuwe uitvoering roteert, wordt de nieuwe geheime waarde gebruikt.

  • Met een nieuwe uitvoering wordt uw geïmplementeerde app hersteld naar een bekende goede status, maar wordt uw Git-geschiedenis niet gewijzigd. Je branch HEAD verwijst nog steeds naar de kapotte commit.

  • Wat opnieuw uitvoeren niet herstelt:

    • Azure resourceconfiguratie die buiten uw implementatie wordt beheerd, inclusief hostingplannen, netwerken en identiteitstoewijzingen.
    • Wijzigingen in gegevens of schema's in downstreamservices, zoals databases, berichtenwachtrijen en opslag.
    • Key Vault geheime waarden. Alleen Key Vault verwijzingen worden bijgehouden in broncodebeheer. Het roteren van geheimen is een bewerking in Key Vault.

  • Test uw rollbackproces regelmatig. Wacht niet tot een productie-incident aan het licht brengt dat er iets kapot is.

De branch herstellen na een rollback

Omdat de volgende run die door een push wordt geactiveerd de defecte commit opnieuw uitrolt, zien andere ontwikkelaars die de branch pullen nog steeds de defecte code. U moet deze situatie oplossen met een van deze acties:

  • Maak een hotfixdoorvoering waarmee het probleem wordt opgelost. Dit is in feite een roll forward-bewerking.
  • Voer een git revert bewerking uit om de verbroken doorvoering ongedaan te maken door een nieuwe doorvoering te maken. Dit is ook een roll forward-actie.
  • Een vertakkingsbeleid dat het samenvoegen voorkomt totdat u het probleem hebt opgelost.

Totdat u een van deze acties hebt voltooid, vermijdt u het activeren van een nieuwe uitvoering op die vertakking. Zie Valideren voordat u samenvoegt voor meer informatie over validatie.

Een implementatie doorsturen

Rolling forward houdt in dat je een nieuwe commit pusht om het probleem op te lossen. De verbroken implementatie blijft actief totdat de oplossing wordt geïmplementeerd, dus deze strategie werkt het beste wanneer de app gedurende die tijd gedegradeerd gedrag tolereert.

  1. Maak een fix-commit aan op je branch. Deze oplossing kan het volgende zijn:

    • Een hotfix waarmee het probleem rechtstreeks wordt opgelost.
    • Een git revert <bad-commit-sha> die een nieuwe commit maakt waarmee de onjuiste wijzigingen ongedaan worden gemaakt. git revert Hoewel de code wordt omgekeerd, is het een roll forward omdat deze een nieuwe doorvoer produceert en een nieuwe implementatie activeert.

  2. Als de oplossing ook configuratiewijzigingen vereist, werkt u uw app-instellingen (in app-settings.json of in uw Bicep-sjabloon) bij in dezelfde commit.

  3. Push de doorvoering. Uw implementatie bouwt en implementeert de oplossing automatisch.

Valideren voordat u gaat samenvoegen

Ongeacht uw herstelstrategie moet u commits valideren en corrigeren voordat u ze naar uw productiebranch mergeert, om te voorkomen dat het probleem verergert.

Deze aanbevelingen zijn van toepassing, ongeacht of u proactief verdergaat of de branch herstelt na een rollback:

  • Gebruik een testomgeving: Omdat het Flex Consumption-plan momenteel geen ondersteuning biedt voor implementatieslots, kunt u in plaats daarvan overwegen om te implementeren in een afzonderlijke Flex Consumption-plan-app om uw oplossing te valideren voordat u deze samenvoegt in de productiebranch.

  • Statuscontroles automatiseren: Voeg een postdeploystap toe waarmee een statuscontrole-eindpunt in uw app wordt aanroepen en een positief antwoord wordt gecontroleerd. Als er een fout optreedt, kunt u overwegen de vorige succesvolle uitvoering opnieuw te starten om automatisch een rollback uit te voeren.

  • Controleren na implementatie: Application Insights-waarschuwingen instellen voor regressiedetectie. Vroege detectie vermindert de impact van een slechte implementatie.

Verwante onderwerpen

  • Last updated on