Récupération après un déploiement défectueux d’une application du plan Flex Consumption

Lorsqu’un déploiement introduit un bogue, vous avez besoin d’un moyen de récupérer rapidement. Cet article vous montre comment récupérer après un déploiement défectueux vers une application de fonction Flex Consumption à l’aide d’un processus d’intégration et de déploiement continus (CI/CD). Ce processus inclut les méthodes de récupération suivantes :

Méthode de récupération Vitesse Quand utiliser Description
Relancer la dernière exécution réussie (revenir en arrière) Le plus rapide Une version correcte connue existe ou aucune modification des données ou de l’état entre les versions Sélectionnez une exécution précédente, puis relancez-la. Attendez ensuite la fin du build et du déploiement.
git revert, puis git push (correction par un nouveau déploiement) Moderate Le correctif est simple ou l’état externe ne peut pas être restauré Identifiez le commit à l'origine de la régression, annulez-le, puis envoyez les modifications. Attendez ensuite la même durée de build et de déploiement.
git commit un correctif, puis git push (roll forward) Le plus lent La cause racine est connue et nécessite un correctif ciblé Identifier la cause racine ; créer, vérifier, tester et fusionner un correctif ; puis attendez la fin de la génération et du déploiement.

Ces stratégies récupèrent à la fois le code de votre application de fonction et les paramètres de l’application, de sorte que vos modifications de configuration sont récupérables avec les modifications de code.

Pourquoi vous avez besoin du CI/CD pour rétablir un déploiement

Lorsque vous déployez du code sur votre application de plan Flex Consumption :

  • Votre code est déployé sous forme d’archive ZIP dans un conteneur de stockage Blob, qui est monté au démarrage.
  • Chaque déploiement remplace le package actuel.
  • La plateforme ne conserve aucun historique de révision intégré pour conserver les versions précédentes.
  • La fonctionnalité emplacements de déploiement n’est actuellement pas prise en charge.
  • Les paramètres d'application sont appliqués séparément via le portail Azure, l'interface CLI ou l'infrastructure en tant que code (IaC) et la plateforme ne peut pas les restaurer à un état précédent.

Ces comportements de déploiement limitent vos options de récupération de votre application de plan Flex Consumption à partir d’un déploiement incorrect.

Votre historique Git et votre processus CI/CD offrent le seul moyen de suivre les déploiements de code à un moment donné. Créer un déploiement qui inclut à la fois le code et la configuration vous permet de revenir sur une mise en production défectueuse en faisant pointer l’exécution suivante vers un commit fiable.

Pour plus d’informations sur le modèle de déploiement Flex Consumption, consultez le plan Flex Consumption et les mises à jour du site dans le plan Flex Consumption.

Prerequisites

  • Une application de fonction existante déployée sur un plan Flex Consumption dans Azure.

  • Code source dans un référentiel Git. Utilisez des tags Git ou consignez les SHA de commit pour chaque version afin de pouvoir identifier rapidement la version vers laquelle revenir en arrière.

  • Déploiement configuré pour votre application de fonction :

    Flux de travail configuré avec l’authentification OIDC, comme décrit dans la livraison continue à l’aide de GitHub Actions. Le flux de travail doit utiliser azure/login. L’authentification par profil de publication ne prend pas en charge les commandes az cli utilisées dans ce guide.

Préparer votre déploiement pour gérer les paramètres de l’application

Avant de pouvoir effectuer une restauration complète, vous devez placer les paramètres de votre application dans le contrôle de code source et les appliquer dans le cadre de votre déploiement. Bien que cette approche vous permet de récupérer du code et de la configuration dans une seule réexécutation, il nécessite des étapes supplémentaires, telles que l’application de paramètres, l’attente de redémarrages et le nettoyage des valeurs non déclarées.

Tip

Lorsque votre déploiement n’inclut pas de paramètres, vous pouvez uniquement restaurer le code déployé, mais pas la configuration.

Cette section décrit deux approches pour la gestion des paramètres d’application dans le cadre de votre déploiement :

Approach Dans le flux de travail (Azure CLI) Dans la définition du service (Bicep)
Fonctionnement Les étapes de déploiement appliquent les paramètres d’un fichier JSON à l’aide de az functionapp config appsettings, puis suppriment les paramètres non déclarés Le modèle Bicep déclare les paramètres de configuration dans siteConfig.appSettings ; ARM remplace l’intégralité de la collection au déploiement
Complexité Modéré. Fichier JSON et étapes CLI supplémentaires dans votre flux de travail Plus élevé. Nécessite des connaissances sur Bicep
Détection de dérive Non Oui (what-if)
Idéal pour Premiers pas, petites équipes Infrastructure complexe prête pour la production, multi-environnement

Pour plus d’informations générales sur les paramètres de l’application, consultez les informations de référence sur les paramètres de l’application pour Azure Functions.

Considérations relatives aux paramètres de l’application

Attention à ces considérations lors de l’utilisation de la configuration programmatique des paramètres d’application.

Important

L’absence d’inclure tous les paramètres requis à l’aide de l’une ou l’autre approche peut interrompre votre application déployée.

  • Les deux approches de cette section traitent votre fichier de paramètres comme l’état souhaité complet. Ils suppriment tous les paramètres d’application non déclarés dans le fichier de l’application sur chaque déploiement. Incluez toujours tous les paramètres requis pour éviter de rompre votre application.

  • Traitez les modifications apportées aux modèles de fichiers app-settings.json et Bicep avec le même niveau de vigilance que les modifications de code. Passez en revue les modifications apportées aux paramètres dans les demandes de tirage pour intercepter les erreurs de configuration avant qu’elles atteignent la production.

  • Pour une sécurité optimale, suivez ces instructions pour vos connexions :

    • Utilisez les connexions d’identité managée dans la mesure du possible. Configurez des connexions basées sur une identité pour le stockage hôte (AzureWebJobsStorage), le stockage de déploiement ainsi que les connexions des déclencheurs et des liaisons. Pour plus d’informations, consultez Configurer les paramètres de déploiement.

      • Utilisez des références à Key Vault lorsque les secrets sont inévitables. Key Vault stocke vos secrets en toute sécurité. Au lieu de stocker directement des secrets, vous pouvez utiliser une référence pour accéder en toute sécurité au secret requis au moment de l’exécution. Pour plus d’informations, consultez Utiliser des références Key Vault.

  • Lorsque vous utilisez CI/CD, chaque modification apportée aux paramètres de votre application ou à votre code déclenche une mise à jour de site distincte. Par défaut, ce processus de déploiement produit au moins deux mises à jour de site : d’abord quand les paramètres sont appliqués, puis quand le code est déployé. Pour les déploiements sans temps d’arrêt, utilisez plutôt une stratégie de mise à jour propagée , où les instances sont vidées et remplacées par lots. Pour plus d’informations, consultez Les mises à jour du site dans le plan Flex Consumption.

Configurer les paramètres d’application dans le flux de travail

Utilisez ces étapes de base pour ajouter un fichier de configuration des paramètres d’application à votre déploiement de projet :

  1. Créez un fichier JSON dans votre référentiel, par exemple dans infra/app-settings.json. Ce fichier doit inclure tous les paramètres d’application requis dans un format JSON qui ressemble à l’exemple suivant :

    [
  {
    "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. Dans votre définition de déploiement spécifique, ajoutez des étapes qui appliquent les paramètres avant le déploiement du code, avec une pause de 30 secondes entre elles.

Les sections suivantes fournissent des exemples de déploiement spécifiques à l’aide des deux approches.

Exemple : déploiement de app-settings.json

Cet exemple de déploiement montre comment configurer votre déploiement pour inclure la configuration. Choisissez l’onglet qui correspond à votre méthode CI/CD.

Ajoutez les étapes suivantes à la tâche deploy de votre flux de travail. Ajoutez actions/checkout@v4 à la tâche deploy afin que infra/app-settings.json soit disponible, et ajoutez RESOURCE_GROUP à votre bloc env au niveau du flux de travail. Les étapes appliquent d’abord les paramètres, attendent le redémarrage, déploient le code, puis nettoient les paramètres non déclarés.

  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

L’étape azure/login@v2 du flux de travail basé sur OIDC fournit l’authentification nécessaire pour les az cli commandes.

Définir des paramètres dans un déploiement Bicep

Pour les déploiements IaC, gérez les paramètres d’application directement dans le modèle Bicep. Bicep remplace nativement la collection entière siteConfig.appSettings à chaque déploiement, sans nécessiter d’étape de nettoyage distincte. Il prend également en charge la détection de dérive en utilisant what-if.

Lorsque vous mettez à jour uniquement la section paramètres de l’application de votre fichier Bicep, toutes les autres ressources Azure restent inchangées pendant le déploiement. Cet article ne couvre pas de bout en bout la création de fichiers Bicep. Pour des modèles Flex Consumption complets, consultez l’infrastructure en tant que code d’Azure Functions.

Voici le fragment pertinent du modèle Bicep (la appSettings partie uniquement) :

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

Ajoutez des étapes pour déployer le modèle Bicep avant le déploiement du code, avec une attente de 30 secondes entre les deux. La mise à jour des paramètres d’application via Bicep est asynchrone. L’application redémarre pour récupérer les nouvelles valeurs et le déploiement du code pendant le redémarrage peut échouer.

      - 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

Restaurer un déploiement

Le retour en arrière consiste à relancer une exécution précédente ayant réussi. Une nouvelle exécution extrait le SHA du commit d'origine qui a déclenché cette exécution (et non le HEAD actuel de la branche), puis reconstruit et redéploie le code ainsi que le fichier de paramètres correspondant à ce moment-là. Vous n’avez pas besoin de nouvelles validations.

Pour annuler un déploiement en relançant une exécution précédente réussie :

  1. Accédez à l’onglet Actions de votre dépôt GitHub.
  2. Recherchez la dernière exécution réussie du flux de travail avant le déploiement incorrect.
  3. Sélectionnez Réexécuter toutes les tâches.
  4. Le flux de travail récupère le commit de cette exécution, reconstruit et déploie le code, puis synchronise les paramètres de l’application à partir du app-settings.json de ce commit.

Éléments reconstruits lors d'une nouvelle exécution

La relance reconstruit le code à partir de l’ancien commit. Elle ne réutilise pas l’artefact binaire d’origine. Ce comportement signifie :

  • Avec des fichiers de verrouillage des dépendances figés (package-lock.json, requirements.txt et ainsi de suite), le résultat est identique sur le plan fonctionnel.
  • La durée du build est identique à celle d'un déploiement normal. Ce n’est pas instantané.
  • Les dépendances externes extraites au moment de la génération (NuGet, npm, pip) doivent toujours être disponibles.

Considérations relatives au retour arrière

  • Épinglez vos fichiers de verrouillage des dépendances (package-lock.json, requirements.txt ou versions .csproj verrouillées) dans le contrôle de code source. Les fichiers de verrouillage figés garantissent que le fait de relancer un déploiement produit une version compilée fonctionnellement identique, quel que soit le moment où cette réexécution a lieu.

  • La réexécution utilise le fichier YAML du workflow ou du pipeline du commit d’origine. Toutefois, les secrets et les variables du pipeline sont résolus à partir de leurs valeurs actuelles au moment de la nouvelle exécution. Si vous faites pivoter vos secrets entre l'exécution d'origine et une nouvelle exécution, la nouvelle valeur du secret est utilisée.

  • Une réexécutation restaure votre application déployée dans un état connu, mais elle ne modifie pas votre historique Git. Le HEAD de votre branche pointe toujours vers le commit défectueux.

  • Ce que la réexécution ne restaure pas :

    • Configuration des ressources Azure gérée en dehors de votre déploiement, notamment les plans d’hébergement, la mise en réseau et les affectations d’identité.
    • Les modifications de données ou de schéma dans les services en aval, tels que les bases de données, les files d’attente de messages et le stockage.
    • Valeurs des secrets Key Vault. Seules les références Key Vault sont conservées dans le contrôle de code source. La rotation des secrets est une opération de Key Vault.

  • Testez régulièrement votre procédure de retour arrière. N’attendez pas qu’un incident de production vous fasse découvrir que cela ne fonctionne pas.

Corriger la branche après un retour en arrière

Étant donné que la prochaine exécution déclenchée par un push redéploie le commit défectueux, les autres développeurs qui récupèrent la branche voient toujours le code défectueux. Vous devez résoudre cette situation avec l’une des actions suivantes :

  • Créez un commit de hotfix qui corrige le problème ; il s’agit essentiellement d’une opération de roll forward.
  • Effectuez un git revert pour annuler le commit défectueux en créant un nouveau commit, ce qui constitue également une opération de roll forward.
  • Stratégie de branche qui empêche la fusion jusqu’à ce que vous corrigez le problème.

Tant que vous n’avez pas terminé l’une de ces actions, évitez de déclencher une nouvelle exécution sur cette branche. Pour obtenir des conseils de validation, consultez Valider avant la fusion.

Avancer un déploiement

La correction par un nouveau déploiement consiste à envoyer un nouveau commit corrigeant le problème. Le déploiement rompu reste actif jusqu’à ce que le correctif se déploie, de sorte que cette stratégie fonctionne mieux lorsque l’application peut tolérer un comportement détérioré pendant ce temps.

  1. Créez un commit de correction sur votre branche. Ce correctif peut être :

    • Un correctif d’urgence qui résout directement le problème.
    • Un git revert <bad-commit-sha> qui crée un nouveau commit annulant les modifications indésirables. Même si git revert elle inverse le code, il s’agit d’une progression, car elle produit une nouvelle validation et déclenche un nouveau déploiement.

  2. Si la correction nécessite également des modifications de configuration, mettez à jour les paramètres de votre application (dans app-settings.json ou dans votre modèle Bicep) dans le même commit.

  3. Poussez le commit. Votre déploiement génère et déploie automatiquement le correctif.

Valider avant la fusion

Quelle que soit votre stratégie de reprise, validez et corrigez les commits avant de les fusionner dans votre branche de production afin d’éviter d’aggraver le problème.

Ces recommandations s’appliquent que vous avanciez de manière proactive ou que vous corrigiez la branche après un retour en arrière :

  • Utilisez un environnement intermédiaire : étant donné que le plan Flex Consumption ne prend actuellement pas en charge les emplacements de déploiement, envisagez plutôt de déployer sur une application de plan Flex Consumption distincte pour valider votre correctif avant la fusion vers la branche de production.

  • Automatiser les vérifications d’intégrité : ajoutez une étape postdéploiement qui appelle un point de terminaison de contrôle d’intégrité dans votre application et vérifie une réponse positive. En cas d’échec, envisagez de relancer la précédente exécution réussie afin d’effectuer automatiquement un retour en arrière.

  • Surveiller après le déploiement : configurez les alertes Application Insights pour la détection de régression. La détection anticipée réduit l’impact d’un déploiement incorrect.

Contenu connexe

  • Last updated on