Déployer sur des emplacements de déploiement Azure App Service avec Azure Developer CLI

Azure Developer CLI (azd) prend en charge les emplacements de déploiement Azure App Service pour les applications hébergées sur App Service. Vous pouvez définir des emplacements dans votre infrastructure, déployer du code sur un emplacement spécifique et échanger des emplacements lorsque vous êtes prêt à promouvoir une version.

Utilisez cette approche pour les déploiements intermédiaires, bleu-vert, les tests de fumée et les restaurations sans ajouter de scripts de déploiement personnalisés.

Prerequisites

Projet azd qui déploie un service sur Azure App Service.
Infrastructure en tant que code qui définit vos ressources App Service dans Bicep.
Un plan de service d'application sur le niveau Standard (S1) ou supérieur. Les niveaux gratuits, partagés et de base ne prennent pas en charge les emplacements de déploiement.

Définir un emplacement de déploiement dans Bicep

Définissez votre site de production comme d’habitude, puis ajoutez une Microsoft.Web/sites/slots ressource pour chaque emplacement que vous souhaitez azd cibler.

resource appServicePlan 'Microsoft.Web/serverfarms@2021-03-01' = {
  name: 'my-appservice-plan'
  location: resourceGroup().location
  sku: {
    name: 'S1'
    tier: 'Standard'
  }
}

resource webApp 'Microsoft.Web/sites@2021-03-01' = {
  name: 'my-appservice'
  location: resourceGroup().location
  kind: 'app'
  properties: {
    serverFarmId: appServicePlan.id
  }
}

resource stagingSlot 'Microsoft.Web/sites/slots@2021-03-01' = {
  name: '${webApp.name}/staging'
  location: webApp.location
  properties: {}
}

Si vous utilisez des modules vérifiés Azure (AVM), définissez l’application web et les modules d’emplacement de déploiement dans le même déploiement et transmettez le nom de l’application au module d’emplacement.

Déployer dans un slot avec azd

Exécutez azd up ou azd provision et azd deploy comme d’habitude.

azd up

Lors du premier déploiement, azd déploie sur le site de production et tous les emplacements définis dans votre infrastructure. Ce premier déploiement établit la même base de référence sur l’application principale et chaque emplacement.

Après le premier déploiement, azd deploy modifie la façon dont il sélectionne la cible de déploiement quand des emplacements existent. azd ne continue pas à déployer directement vers l'application de production s'il y a des slots disponibles. Au lieu de cela, vous déployez dans un slot, validez la version, puis basculez en production.

Comment azd sélectionne la cible de déploiement

Quand azd deploy s'exécute pour un App Service qui a des emplacements de déploiement, c'est lui qui sélectionne la cible en vérifiant l’historique du déploiement sur l’application principale, puis évalue les emplacements disponibles.

Le comportement fonctionne comme suit :

Si aucun déploiement précédent n’existe, azd se déploie sur l’application principale et sur tous les emplacements.
Si des déploiements précédents existent et qu’aucun slot n'existe, azd déploie uniquement sur l'application principale.
Si des déploiements précédents existent et qu’il existe exactement un emplacement, azd il est déployé uniquement sur cet emplacement.
Si des déploiements précédents existent et que deux ou plusieurs emplacements existent, azd utilise l’emplacement spécifié par une variable d’environnement ou vous invite à en choisir un.

Important

Après le premier déploiement, azd ne se déploie pas directement sur l’application App Service principale quand des emplacements existent. Ce comportement est intentionnel et permet d’éviter les déploiements directs à production accidentels. Pour mettre à jour la production, déployez sur un emplacement, puis échangez l’emplacement en production (@main).

Sélectionner un emplacement avec une variable d’environnement

Lorsque votre service a deux emplacements ou plus après le premier déploiement, vous pouvez ignorer l’invite interactive en définissant une variable d’environnement pour le service que vous souhaitez déployer.

Utilisez le format suivant :

AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME

Générez le nom de la variable à partir du nom du service en azure.yaml utilisant des majuscules et en remplaçant les traits d’union par des traits de soulignement.

Par exemple, si votre service est nommé my-api, utilisez AZD_DEPLOY_MY_API_SLOT_NAME.

azd env set AZD_DEPLOY_MY_API_SLOT_NAME staging
azd deploy my-api

Vous pouvez stocker cette valeur dans votre azd environnement à l’aide azd env setde , ou la définir directement dans votre système CI avant d’exécuter azd deploy.

Si votre service a exactement un emplacement, azd ignore la variable d’environnement, car il n’existe qu’une seule cible de déploiement possible.

Si votre service a deux emplacements ou plus et que la variable d’environnement n’est pas définie, azd vous invite à choisir un emplacement.

Ignorer la détection du slot et déployer sur l’application principale

Dans certains scénarios, vous devez azd déployer directement vers l’application App Service principale, même si des slots existent. Par exemple:

Votre pipeline CI doit mettre à jour l’application principale sans toucher aux slots existants.
Vous devez récupérer après un état défaillant du slot et souhaitez redéployer directement le site de production.
Vous redéfinissez la base de référence de l’application principale avant de configurer de nouveaux emplacements.

Pour contourner la détection des emplacements, définissez la variable d’environnement suivante pour le service :

AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS

Générez le nom de la variable à partir du nom du service en azure.yaml utilisant des majuscules et en remplaçant les traits d’union par des traits de soulignement. Définissez la valeur sur true pour ignorer la détection des emplacements et effectuer le déploiement vers l’application principale.

Par exemple, si votre service est nommé my-api, utilisez AZD_DEPLOY_MY_API_IGNORE_SLOTS.

azd env set AZD_DEPLOY_MY_API_IGNORE_SLOTS true
azd deploy my-api

Quand AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS est défini sur true, azd effectue le déploiement sur l’application principale et ignore toute valeur de AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME pour le même service. Supprimez la variable ou définissez-la sur false pour revenir au comportement par défaut sensible aux slots.

Comportement CI et non-interactif

Lorsque vous exécutez ou déployez azd deploy --no-prompt à partir de ci, la sélection d’emplacements se comporte différemment en fonction du nombre d’emplacements disponibles :

Slots	Comportement des variables d’environnement	Résultat
`0`	Non applicable.	`azd` déploie sur l’application principale.
`1`	Ignoré sauf si `AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS` est `true`.	`azd` déploie dans le seul emplacement, ou dans l’application principale lorsque les emplacements sont ignorés.
`2+`	`AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME` est requis pour éviter l’affichage d’une invite, sauf si `AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS` est `true`.	`azd` déploie sur l’emplacement spécifié, se déploie sur l’application principale lorsque les emplacements sont ignorés ou échouent si aucune cible ne peut être sélectionnée.

Si vous automatisez les déploiements pour un App Service qui a deux emplacements ou plus, défini AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME dans l’environnement de pipeline avant d’exécuter azd deploy. Pour forcer un déploiement direct sur l’emplacement principal depuis CI lorsque des emplacements existent, définissez AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS sur true à la place.

Échanger des emplacements de déploiement Azure App Service

Utilisez l’extension azure.appservice pour échanger des emplacements après la validation. Si l’extension n’est pas déjà installée, azd vous invite à l’installer la première fois que vous exécutez la commande.

Exécutez l’expérience interactive :

azd appservice swap

S’il n’existe qu’un seul emplacement hors production, azd ignore les invites et échange directement avec la production.

Pour l’automatisation, spécifiez explicitement les emplacements source et de destination. Utilisez @main pour référencer le créneau de production.

azd appservice swap --src staging --dst @main
azd appservice swap --src @main --dst staging
azd appservice swap --service myapi --src staging --dst @main

Utilisez ces modèles pour prendre en charge les flux de mise en production courants :

Promouvoir un déploiement intermédiaire validé en production avec --src staging --dst @main.
Revenez en échangeant l'emplacement de production et l'emplacement intermédiaire avec --src @main --dst staging.
Ciblez un service App Service spécifique dans un projet multiservice azd avec --service.

L'échange est le parcours prévu pour la mise à jour de la production après la configuration des slots. Permet azd deploy de mettre à jour un emplacement, puis d’utiliser azd appservice swap pour promouvoir cet emplacement en production.

Workflow d’emplacement de déploiement recommandé

Définissez un ou plusieurs emplacements de déploiement App Service dans vos modèles Bicep.
Provisionnez les ressources App Service à l’aide azd provision ou azd up.
Laissez le premier déploiement établir une base de référence sur l’application principale et chaque emplacement.
Déployez les mises à jour ultérieures de l’application sur un emplacement intermédiaire en définissant AZD_DEPLOY_<SERVICE_NAME>_SLOT_NAME lorsque vous avez deux emplacements ou plus, ou en sélectionnant l’emplacement lorsque vous y êtes invité. Pour forcer un déploiement direct sur l’emplacement principal depuis CI lorsque des emplacements de déploiement existent, définissez AZD_DEPLOY_<SERVICE_NAME>_IGNORE_SLOTS sur true à la place.
Validez le déploiement par étapes.
Exécutez azd appservice swap --src <slot> --dst @main pour promouvoir la version.
Si nécessaire, exécutez le swap inverse pour revenir en arrière.

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2026-06-11