Återhämta dig efter en misslyckad distribution av appen till Flex Consumption-planen

När en distribution introducerar en bugg behöver du ett sätt att återställa snabbt. Den här artikeln visar hur du återställer efter en misslyckad distribution till en Flex Consumption-funktionsapp genom att använda en CI/CD-process (löpande integrering och kontinuerlig distribution). Den här processen omfattar följande återställningsmetoder:

Återställningsmetod Hastighet När det bör användas Beskrivning
Kör om tidigare lyckad körning (återgå) Snabbaste Det finns en känd bra version eller inga data- eller tillståndsändringar mellan versioner Välj en tidigare körning och kör om den. Vänta sedan tills bygget och distributionen är klara.
git revert och sedan git push (rulla framåt) Medel Korrigeringen är enkel eller så går det inte att återställa det externa tillståndet Identifiera incheckningen som orsakade felet, revertera den och pusha den. Vänta sedan på samma bygg- och distributionstid.
git commit en snabbkorrigering och sedan git push (rulla framåt) Långsammaste Grundorsaken är känd och kräver en riktad åtgärd Identifiera grundorsaken; ta fram, granska, testa och slå samman en korrigering; och vänta sedan på att build och driftsättning ska slutföras.

Dessa strategier återställer både funktionsappkoden och appinställningarna, så att konfigurationsändringarna kan återställas med kodändringar.

Varför du behöver CI/CD för att återställa en distribution

När du distribuerar kod till din Flex Consumption-planapp:

  • Koden distribueras som ett ZIP-paket till en container för bloblagring, som monteras vid start.
  • Varje distribution skriver över det aktuella paketet.
  • Plattformen behåller ingen inbyggd revisionshistorik för att behålla tidigare versioner.
  • Funktionen för distributionsplatser stöds inte för närvarande.
  • Appinställningar tillämpas separat via Azure-portalen, CLI eller infrastruktur som kod (IaC) och plattformen kan inte återställa dem till ett tidigare tillstånd.

Dessa distributionsbeteenden begränsar dina alternativ för att återställa din Flex Consumption-planapp från en felaktig distribution.

Din Git-historik och CI/CD-process är det enda sättet att spåra koddistributioner vid en viss tidpunkt. Att skapa en driftsättning som omfattar både kod och konfiguration gör att du kan återhämta dig från en misslyckad release genom att låta nästa körning peka på en tidigare verifierad commit.

Mer information om distributionsmodellen Flex Consumption finns i Flex Consumption plan och Site updates in the Flex Consumption plan.

Prerequisites

Förbereda distributionen för att hantera appinställningar

Innan du kan utföra en fullständig återställning måste du placera appinställningarna i källkontrollen och tillämpa dem som en del av distributionen. Med den här metoden kan du återställa både kod och konfiguration i en enda omkörning, men det krävs extra steg, till exempel att tillämpa inställningar, vänta på omstarter och rensa odeklarerade värden.

Tip

När distributionen inte innehåller inställningar kan du bara återställa den distribuerade koden, men inte konfigurationen.

Det här avsnittet beskriver två metoder för att hantera appinställningar som en del av distributionen:

Tillvägagångssätt I arbetsflödet (Azure CLI) I tjänstdefinieringen (Bicep)
Så här fungerar det Driftsättningsstegen tillämpar inställningar från en JSON-fil med az functionapp config appsettings, och tar sedan bort inställningar som inte deklarerats Bicep mall deklarerar inställningar i siteConfig.appSettings; ARM ersätter hela samlingen vid distribution
Komplexitet Moderat. JSON-fil plus extra CLI-steg i arbetsflödet Högre. Kräver kunskaper i Bicep
Driftdetektering Nej Ja (what-if)
Bäst för Komma igång för små team Produktionsklar, komplex infrastruktur för flera miljöer

Mer allmän information om appinställningar finns i Referens för appinställningar för Azure Functions.

Överväganden för appinställningar

Var uppmärksam på dessa överväganden när du arbetar med programmatisk konfiguration av appinställningar.

Important

Om du inte inkluderar alla nödvändiga inställningar när du använder någon av metoderna kan appen du har distribuerat sluta fungera.

  • Båda metoderna i det här avsnittet behandlar din inställningsfil som det fullständiga önskade tillståndet. De tar bort alla appinställningar som inte deklarerats i filen från appen vid varje distribution. Inkludera alltid alla nödvändiga inställningar för att undvika att bryta din app.

  • Behandla app-settings.json och ändringar i Bicep-filmallen med samma noggrannhet som kodändringar. Granska inställningarnas ändringar i pull-begäranden för att fånga konfigurationsfel innan de når produktion.

  • För optimal säkerhet följer du dessa riktlinjer för dina anslutningar:

    • Använd hanterade identitetsanslutningar där det är möjligt. Konfigurera identitetsbaserade anslutningar för värdlagring (AzureWebJobsStorage), distributionslagring och utlösar-/bindningsanslutningar. Mer information finns i Konfigurera distributionsinställningar.

      • Använd Key Vault referenser när hemligheter är oundvikliga. Key Vault lagrar dina hemligheter på ett säkert sätt. I stället för att lagra hemligheter direkt kan du använda en referens för att på ett säkert sätt komma åt den hemlighet som krävs vid körning. Mer information finns i Använd Key Vault-referenser.

  • När du använder CI/CD, så utlöser varje ändring av appinställningarna eller koden en separat webbplatsuppdatering. Som standard genererar den här distributionsprocessen minst två platsuppdateringar: först när inställningarna tillämpas och sedan när koden distribueras. För distributioner utan driftstopp använder du i stället en löpande uppdateringsstrategi , där instanser töms och ersätts i batchar. Mer information finns i Webbplatsuppdateringar för Flex Consumption-planen.

Konfigurera appinställningar i arbetsflödet

Använd de här grundläggande stegen för att lägga till en konfigurationsfil för appinställningar i projektdistributionen:

  1. Skapa en JSON-fil på lagringsplatsen, till exempel i infra/app-settings.json. Den här filen måste innehålla alla nödvändiga appinställningar i ett JSON-format som ser ut som i följande exempel:

    [
  {
    "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. I din specifika distributionsdefinition lägger du till steg som tillämpar inställningarna innan koddistributionen sker, med en paus på 30 sekunder mellan dem.

Följande avsnitt innehåller specifika distributionsexempel med båda metoderna.

Exempel: driftsättning av app-settings.json

Det här distributionsexemplet visar hur du konfigurerar distributionen så att den inkluderar konfiguration. Välj den flik som matchar din CI/CD-metod.

Lägg till följande steg i det deploy jobb i ditt arbetsflöde. Lägg till actions/checkout@v4 i deploy-jobbet så att infra/app-settings.json blir tillgängligt, och lägg till RESOURCE_GROUP i ditt env-block på arbetsflödesnivå. Stegen tillämpar inställningarna först, väntar på omstarten, distribuerar kod och rensar sedan odeklarerade inställningar.

  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

Steget azure/login@v2 i det OIDC-baserade arbetsflödet ger den autentisering som krävs för az cli kommandona.

Definiera inställningar i en driftsättning med Bicep

För IaC-distributioner hanterar du appinställningar direkt i Bicep-mallen. Bicep ersätter direkt hela samlingen siteConfig.appSettings vid varje distribution utan att behöva ett separat rensningssteg. Den stöder också driftidentifiering med hjälp av what-if.

När du bara uppdaterar avsnittet appinställningar i din Bicep-fil förblir alla andra Azure resurser oförändrade under distributionen. Den här artikeln omfattar inte heltäckande redigering i Bicep. Fullständiga Flex Consumption-mallar finns i Azure Functions infrastruktur som kod.

Här är det relevanta fragmentet i Bicep-mallen (endast appSettings-delen):

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

Lägg till steg för att distribuera Bicep-mallen före koddistributionen, med en 30-sekunders väntan däremellan. Det är asynkront att uppdatera appinställningarna via Bicep. Appen startas om för att hämta de nya värdena och distributionen av kod under omstarten kan misslyckas.

      - 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

Återställ en driftsättning

Att återgå innebär att köra en tidigare lyckad körning igen. En ny körning checkar ut den ursprungliga commit-SHA:n som utlöste körningen (inte grenens nuvarande HEAD), så den bygger om och distribuerar koden och inställningsfilen från den tidpunkten. Du behöver inte göra några nya commitar.

Så här återställer du en distribution genom att köra en tidigare lyckad körning igen:

  1. Gå till fliken Åtgärder i din GitHub lagringsplats.
  2. Hitta den senaste lyckade körningen av arbetsflödet före den felaktiga driftsättningen.
  3. Välj Kör alla jobb igen.
  4. Arbetsflödet checkar ut den commit som hör till körningen, bygger om, distribuerar koden och synkroniserar appinställningarna från den commitens app-settings.json.

Vad som byggs om när du kör igen

Omkörningen bygger om koden från den gamla committen. Den återanvänder inte den ursprungliga binära artefakten. Det här beteendet innebär:

  • Med fastlåsta beroendelåsfiler (package-lock.json, requirements.txt och så vidare) är utdata funktionellt identisk.
  • Byggtiden är densamma som för en vanlig driftsättning. Det är inte omedelbart.
  • Externa beroenden som hämtas vid byggtiden (NuGet, npm, pip) måste fortfarande vara tillgängliga.

Överväganden vid återställning

  • Fäst dina beroendelåsfiler (package-lock.json, requirements.txteller låsta .csproj versioner) i källkontrollen. Fästa låsfiler ser till att omkörning av en distribution ger en funktionellt identisk version oavsett när omkörningen sker.

  • Vid omkörning används YAML-filen för arbetsflödet eller pipelinen från den ursprungliga committen. Hemligheter och pipelinevariabler matchar dock sina aktuella värden när de körs igen. När du roterar dina hemliga värden mellan den ursprungliga körningen och en omkörning används det nya hemliga värdet.

  • En omkörning återställer din distribuerade app till ett känt tillstånd, men den ändrar inte din Git-historik. Grenens HEAD pekar fortfarande på den trasiga commiten.

  • Vad som inte återställs när du kör igen:

    • Azure resurskonfiguration som hanteras utanför distributionen, inklusive värdplaner, nätverk och identitetstilldelningar.
    • Data- eller schemaändringar i underordnade tjänster, till exempel databaser, meddelandeköer och lagring.
    • Key Vault-hemlighetsvärden. Endast Key Vault-referenser lagras i källkontroll. Att rotera secrets är en åtgärd i Key Vault.

  • Testa återställningsprocessen regelbundet. Vänta inte tills en produktionsincident inträffar innan du upptäcker att något inte fungerar.

Åtgärda grenen efter en återställning

Eftersom nästa körning som utlöses av en push driftsätter den felaktiga incheckningen på nytt får andra utvecklare som hämtar grenen fortfarande den felaktiga koden. Du måste åtgärda den här situationen med någon av följande åtgärder:

  • Skapa en hotfix-commit som åtgärdar problemet, vilket i praktiken är en framåtrullning.
  • Utför en git revert för att ångra den brutna incheckningen genom att skapa en ny incheckning, vilket också är en roll forward-åtgärd.
  • En grenprincip som förhindrar sammanslagning tills du åtgärdar problemet.

Tills du har slutfört någon av dessa åtgärder bör du undvika att utlösa en ny körning på den grenen. Valideringsvägledning finns i Verifiera innan sammanslagning.

Rulla fram en distribution

Att rulla framåt innebär att pusha en ny commit för att åtgärda problemet. Den brutna distributionen förblir live tills korrigeringen distribueras, så den här strategin fungerar bäst när appen kan tolerera degraderat beteende under den tiden.

  1. Skapa en fix-commit på din gren. Den här korrigeringen kan vara:

    • En snabbkorrigering som löser problemet direkt.
    • En git revert <bad-commit-sha> som skapar en ny commit som återställer de felaktiga ändringarna. Även om git revert koden återställs är det en framåtrullning eftersom den genererar en ny incheckning och utlöser en ny distribution.

  2. Om åtgärden också kräver konfigurationsändringar, uppdatera appinställningarna (antingen i app-settings.json eller i din Bicep-mall) i samma commit.

  3. Skicka incheckningen. Din distribution bygger och distribuerar korrigeringen automatiskt.

Verifiera innan sammanslagning

Oavsett vilken återställningsstrategi du använder, validera och åtgärda commitar innan du sammanfogar dem med produktionsgrenen så att problemet inte förvärras.

Dessa rekommendationer gäller oavsett om du proaktivt går vidare eller åtgärdar grenen efter en återgång:

  • Använd en mellanlagringsmiljö: Eftersom Flex Consumption-planen för närvarande inte stöder distributionsplatser bör du i stället överväga att distribuera till en separat Flex Consumption-planapp för att verifiera korrigeringen innan du slår samman till produktionsgrenen.

  • Automatisera hälsokontroller: Lägg till ett postdeploy-steg som anropar en slutpunkt för hälsokontroll i din app och verifierar ett positivt svar. Vid fel kan du överväga att starta en ny körning av den senast lyckade körningen för att automatiskt rulla tillbaka.

  • Övervaka efter distributionen: Konfigurera Application Insights-aviseringar för regressionsidentifiering. Tidig identifiering minskar effekten av en felaktig distribution.

Relaterat innehåll

  • Last updated on