Zotavení z chybného nasazení aplikace plánu Flex Consumption

Když nasazení způsobí chybu, potřebujete způsob, jak se rychle zotavit. V tomto článku se dozvíte, jak se zotavit z chybného nasazení do aplikace funkcí Flex Consumption pomocí procesu kontinuální integrace a průběžného nasazování (CI/CD). Tento proces zahrnuje tyto metody obnovení:

Metoda obnovení Rychlost Kdy ho použít Description
Opětovné spuštění předchozího úspěšného spuštění (vrácení zpět) Nejrychlejší Známá dobrá verze existuje nebo se mezi verzemi nemění žádná data nebo stav. Vyberte předchozí spuštění a znovu ho spusťte a pak počkejte na sestavení a nasazení.
git revert a pak git push (posunout vpřed) Moderate Oprava je jednoduchá, nebo externí stav nelze vrátit zpět Identifikujte problematický commit, revertujte ho a pushněte změny. Pak počkejte na stejný čas sestavení a nasazení.
git commit opravná aktualizace a poté git push (přejít na novější verzi) Nejpomalejší Původní příčina je známá a potřebuje cílovou opravu. Identifikujte hlavní příčinu; vytvořte, zkontrolujte, otestujte a slučte opravu; a pak počkejte na dokončení sestavení a nasazení.

Tyto strategie obnoví kód aplikace funkcí i nastavení aplikace, takže změny konfigurace se dají obnovit pomocí změn kódu.

Proč potřebujete CI/CD k obnovení nasazení

Když nasadíte kód do aplikace plánu Flex Consumption:

  • Váš kód se nasadí jako balíček ZIP do kontejneru úložiště objektů blob, který se připojí při spuštění.
  • Každé nasazení přepíše aktuální balíček.
  • Platforma neuchová žádnou předdefinované historii revizí, aby si zachovala předchozí verze.
  • Funkce slotů nasazení se v současné době nepodporuje.
  • Nastavení aplikace se používá samostatně prostřednictvím portálu Azure, rozhraní příkazového řádku nebo infrastruktury jako kódu (IaC) a platforma je nemůže obnovit do předchozího stavu.

Tyto způsoby chování při nasazení omezují vaše možnosti obnovení aplikace v plánu Flex Consumption po nezdařeném nasazení.

Historie Gitu a proces CI/CD poskytují jediný způsob, jak sledovat nasazení kódu v daném časovém okamžiku. Vytvoření nasazení, které zahrnuje kód i konfiguraci, vám umožní obnovit se po nepovedeném vydání tím, že při příštím spuštění odkážete na známý funkční commit.

Další informace o modelu nasazení Flex Consumption naleznete v tématech plán Flex Consumption a aktualizace webu v plánu Flex Consumption.

Předpoklady

Příprava nasazení pro správu nastavení aplikace

Než budete moct provést úplné vrácení zpět, musíte nastavení aplikace umístit do správy zdrojového kódu a použít je jako součást nasazení. I když tento přístup umožňuje obnovit kód i konfiguraci v jediném opětovném spuštění, vyžaduje další kroky, jako je použití nastavení, čekání na restartování a vyčištění nedelarovaných hodnot.

Tip

Pokud vaše nasazení neobsahuje nastavení, můžete vrátit jenom nasazený kód, ale ne konfiguraci.

Tato část popisuje dva přístupy ke správě nastavení aplikace v rámci nasazení:

Approach V pracovním postupu (Azure CLI) V definici služby (Bicep)
Jak to funguje Při nasazení se použije nastavení ze souboru JSON pomocí az functionapp config appsettings a poté se odstraní nedeklarovaná nastavení. Šablona Bicep definuje nastavení v siteConfig.appSettings; ARM během nasazení nahradí celou kolekci.
Složitost Střední. Soubor JSON a další kroky v CLI v pracovním postupu Vyšší. Vyžaduje znalost Bicepu
Detekce driftu No Ano (what-if)
Nejvhodnější pro Začínáme, malé týmy Infrastruktura připravená pro produkční prostředí, více prostředí a složitá infrastruktura

Další obecné informace o nastavení aplikace najdete v referenčních informacích k nastavení aplikace pro Azure Functions.

Důležité informace o nastavení aplikace

Při práci s programovou konfigurací nastavení aplikace věnujte pozornost těmto aspektům.

Important

Selhání zahrnutí všech požadovaných nastavení pomocí některého z přístupů může narušit nasazenou aplikaci.

  • Oba přístupy v této části zachází se souborem nastavení jako s úplným požadovaným stavem. Odeberou všechna nastavení aplikace, která nejsou v souboru deklarována, z aplikace při každém nasazení. Vždy zahrňte všechna požadovaná nastavení, aby nedošlo k narušení vaší aplikace.

  • Ke změnám v app-settings.json a v šablonách souborů Bicep přistupujte se stejnou pečlivostí jako ke změnám kódu. Zkontrolujte změny nastavení v žádostech o přijetí změn a zachyťte chyby konfigurace, než se dostanou do produkčního prostředí.

  • Pokud chcete zajistit optimální zabezpečení, postupujte podle těchto pokynů pro vaše připojení:

    • Používejte připojení spravovaných identit všude, kde je to možné. Nastavte připojení založená na identitě pro hostitelské úložiště (AzureWebJobsStorage), úložiště nasazení a připojení triggeru/vazby. Další informace naleznete v tématu Konfigurace nastavení nasazení.

      • Pokud se použití tajných údajů nelze vyhnout, použijte reference na Key Vault. Key Vault bezpečně ukládá vaše tajné údaje. Místo přímého ukládání tajných kódů můžete pomocí odkazu bezpečně přistupovat k požadovanému tajnému kódu za běhu. Další informace najdete v tématu Použití odkazů na Key Vault.

  • Když používáte CI/CD, každá změna nastavení aplikace nebo kódu aktivuje samostatnou aktualizaci webu. Ve výchozím nastavení tento proces nasazení vytvoří aspoň dvě aktualizace lokality: nejprve při použití nastavení a po nasazení kódu. Pro nasazení bez výpadku použijte místo toho strategii průběžné aktualizace, při níž jsou instance postupně odpojovány z provozu a nahrazovány po dávkách. Další informace najdete v tématu Aktualizace webu v plánu Flex Consumption.

Konfigurace nastavení aplikace v pracovním postupu

Pomocí těchto základních kroků přidejte do nasazení projektu konfigurační soubor nastavení aplikace:

  1. Vytvořte v úložišti soubor JSON, například v infra/app-settings.json. Tento soubor musí obsahovat všechna požadovaná nastavení aplikace ve formátu JSON, který vypadá jako v následujícím příkladu:

    [
  {
    "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. Do definice konkrétního nasazení přidejte kroky, které před nasazením kódu uplatní tato nastavení, s 30sekundovou prodlevou mezi jednotlivými kroky.

Následující části obsahují konkrétní příklady nasazení s využitím obou přístupů.

Příklad: nasazení app-settings.json

Tento příklad nasazení ukazuje, jak nakonfigurovat nasazení tak, aby zahrnovalo konfiguraci. Zvolte záložku, která odpovídá vaší metodě CI/CD.

Do úlohy v pracovním postupu přidejte následující kroky deploy . Přidejte actions/checkout@v4 do deploy úlohy, aby infra/app-settings.json byla k dispozici, a přidejte RESOURCE_GROUP do bloku na úrovni env pracovního postupu. V těchto krocích se nejprve použije nastavení, poté se počká na restart, nasadí se kód a nakonec se odstraní nedeklarovaná nastavení.

  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

Krok azure/login@v2 v pracovním postupu založeném na OIDC poskytuje ověřování potřebné pro az cli příkazy.

Definování nastavení v nasazení Bicep

Pro nasazení IaC spravujte nastavení aplikace přímo v šabloně Bicep. Bicep nativně nahrazuje celou kolekci siteConfig.appSettings při každém nasazení bez nutnosti samostatného kroku čištění. Podporuje také detekci odchylek pomocí what-if.

Když aktualizujete jenom část nastavení aplikace souboru Bicep, všechny ostatní Azure prostředky zůstanou během nasazení nezměněné. Tento článek nepokrývá psaní v jazyce Bicep od začátku do konce. Úplné šablony Flex Consumption najdete v článku Infrastruktura Azure Functions jako kód.

Zde je příslušný úryvek šablony Bicep (pouze část appSettings):

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

Přidejte kroky pro nasazení šablony Bicep před nasazením kódu, s 30sekundovou prodlevou mezi nimi. Aktualizace nastavení aplikace prostřednictvím Bicep je asynchronní. Aplikace se restartuje a vyzvedne nové hodnoty a nasazení kódu během restartování může selhat.

      - 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

Vrátit nasazení zpět

Návrat znamená opětovné spuštění předchozího úspěšného běhu. Opětovné spuštění použije SHA původního commitu, který toto spuštění aktivoval (nikoli aktuální HEAD větve), takže znovu sestaví a nasadí kód a soubor s nastavením z daného okamžiku. Nepotřebujete žádné nové commity.

Vrácení nasazení opětovným spuštěním předchozího úspěšného běhu:

  1. Přejděte na kartu Akce v úložišti GitHub.
  2. Najděte poslední úspěšné spuštění workflow před chybným nasazením.
  3. Vyberte Znovu spustit všechny úlohy.
  4. Pracovní postup načte commit daného spuštění, znovu sestaví a nasadí kód a synchronizuje nastavení aplikace z app-settings.json daného commitu.

Co opětovné spuštění znovu sestaví

Opětovné spuštění znovu sestaví kód ze starého potvrzení. Původní binární artefakt se znovu nepoužívá. Toto chování znamená:

  • S připnutými soubory uzamčení závislostí (package-lock.jsonrequirements.txtatd.) je výstup funkčně identický.
  • Doba sestavení je stejná jako u běžného nasazení. Není to okamžité.
  • Externí závislosti načtené v době sestavení (NuGet, npm, pip) musí být stále dostupné.

Hlediska vrácení změn

  • Zafixujte soubory pro uzamčení závislostí (package-lock.json, requirements.txt nebo uzamčené verze .csproj) v systému správy zdrojového kódu. Připnuté uzamčené soubory zajišťují, že opětovné spuštění nasazení vytvoří funkčně identické sestavení bez ohledu na to, kdy dojde k opětovnému spuštění.

  • Opětovné spuštění používá YAML pracovního postupu nebo pipeline z původního commitu. Tajné údaje a proměnné pipeline se však při opětovném spuštění vyhodnotí na své aktuální hodnoty. Při obměně tajných kódů mezi původním spuštěním a opětovným spuštěním se použije nová hodnota tajného kódu.

  • Opětovné spuštění obnoví nasazenou aplikaci do známého dobrého stavu, ale nezmění vaši historii Gitu. Vaše větev HEAD stále odkazuje na chybnou revizi.

  • Co se po opětovném spuštění neobnoví:

    • Konfigurace prostředků Azure spravovaná mimo vaše nasazení, včetně plánů hostování, síťových prostředků a přiřazení identit.
    • Změny dat nebo schématu v podřízených službách, jako jsou databáze, fronty zpráv a úložiště.
    • Hodnoty tajných kódů ve službě Key Vault. V systému správy zdrojového kódu se uchovávají pouze odkazy na Key Vault. Rotace tajných kódů je operace Key Vault.

  • Pravidelně testujte proces vrácení zpět. Nečekejte, až v produkci dojde k incidentu, abyste zjistili, že něco nefunguje.

Oprava větve po vrácení zpět

Protože další spuštění vyvolané pushem znovu nasadí chybný commit, ostatní vývojáři, kteří si tuto větev stáhnou, stále uvidí chybný kód. Tuto situaci musíte vyřešit pomocí jedné z těchto akcí:

  • Vytvořte hotfix commit, který řeší tento problém; jde v podstatě o operaci posunu vpřed.
  • Proveďte git revert, chcete-li vrátit změny chybného commitu vytvořením nového commitu, což je také operace roll-forward.
  • Zásady větve, které brání sloučení, dokud problém nevyřešíte.

Dokud některou z těchto akcí nenakončíte, vyhněte se aktivaci nového spuštění v této větvi. Pokyny k ověření najdete v tématu Ověření před sloučením.

Posunout nasazení vpřed

Posun vpřed znamená odeslání nového commitu, který problém opraví. Přerušené nasazení zůstane aktivní, dokud se oprava nenasadí, takže tato strategie funguje nejlépe, když aplikace během této doby dokáže tolerovat degradované chování.

  1. Vytvořte ve větvi potvrzení opravy. Tato oprava může být následující:

    • Jedna hotfix oprava, která přímo řeší problém.
    • A git revert <bad-commit-sha> , která vytvoří nové potvrzení, které vrátí zpět chybné změny. I když git revert vrátí změny v kódu zpět, je to krok vpřed, protože vytvoří nový commit a spustí nové nasazení.

  2. Pokud oprava také vyžaduje změny konfigurace, aktualizujte nastavení aplikace ve stejném commitu (buď v souboru app-settings.json, nebo v šabloně Bicep).

  3. Nahrajte commit. Vaše nasazení automaticky sestaví a nasadí opravu.

Ověření před sloučením

Bez ohledu na vaši strategii zotavení ověřte a opravte commity před jejich sloučením do produkční větve, abyste problém ještě nezhoršili.

Tato doporučení platí bez ohledu na to, zda postupujete vpřed proaktivně, nebo větev opravujete po vrácení změn:

  • Použijte přípravné prostředí: Vzhledem k tomu, že plán Flex Consumption aktuálně nepodporuje sloty pro nasazení, zvažte místo toho nasazení do samostatné aplikace v plánu Flex Consumption, abyste před sloučením do produkční větve mohli ověřit opravu.

  • Automatizace kontrol stavu: Přidejte krok postdeploy, který volá koncový bod kontroly stavu ve vaší aplikaci a ověřuje pozitivní odpověď. Při selhání zvažte aktivaci opětovného spuštění předchozího úspěšného spuštění, aby se automaticky vrátil zpět.

  • Monitorování po nasazení: Nastavení výstrah Application Insights pro detekci regrese Včasné zjišťování snižuje dopad chybného nasazení.

Související obsah

  • Last updated on