Configurer des environnements intermédiaires dans Azure App Service
Remarque
Depuis le 1er juin 2024, toutes les applications App Service nouvellement créées ont la possibilité de générer un nom d’hôte par défaut unique en utilisant la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés.
Exemple : myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Pour plus d’informations, reportez-vous à Nom d’hôte par défaut unique pour les ressources App Service.
Lorsque vous déployez votre application web, votre application web Linux, votre backend mobile ou votre API dans Azure App Service, vous pouvez utiliser un autre emplacement de déploiement que l’emplacement de production par défaut lorsque vous exécutez le niveau de plan Standard, Premium ou Isolé d’App Service. Les emplacements de déploiement sont des applications en production pourvues de leur propre nom d’hôte. Les éléments de contenu et de configuration des applications peuvent être échangés entre deux emplacements de déploiement, y compris l’emplacement de production.
Le déploiement de votre application sur un emplacement hors production présente les avantages suivants :
- Vous pouvez valider les modifications d’une application dans un emplacement de déploiement intermédiaire avant de l’échanger avec l’emplacement de production.
- Déployer d’abord une application dans un emplacement et la basculer ensuite en production permet de vous assurer que toutes les instances de l’emplacement sont initialisées avant d’être basculées en production. Cela permet d’éliminer les temps d’arrêt lors du déploiement de l’application. La redirection du trafic est transparente et aucune requête n’est abandonnée du fait d’opérations de permutation. Vous pouvez automatiser l’intégralité de ce workflow en configurant l’échange automatique lorsqu’aucune validation n’est nécessaire avant l’échange.
- Après basculement, la précédente application de production se retrouve dans l’emplacement de l’application précédemment intermédiaire. Si les modifications permutées en production ne vous conviennent pas, vous pouvez effectuer la même permutation afin de récupérer immédiatement le contenu du précédent site qui vous plaisait.
Chaque niveau de plan App Service prend en charge un nombre différent d’emplacements de déploiement. L’utilisation de ces emplacements de déploiement n’entraîne aucun coût supplémentaire. Pour connaître le nombre d’emplacements pris en charge par le plan de votre application, consultez Limites App Service.
Pour mettre votre application à l’échelle vers un autre niveau, vérifiez que le niveau cible peut prendre en charge le nombre d’emplacements déjà utilisés par votre application. Par exemple, si votre application comprend plus de cinq emplacements, vous ne pouvez pas effectuer de scale-down vers le niveau Standard, car le niveau Standard ne prend en charge que cinq emplacements de déploiement.
Cette vidéo vous montre comment configurer des environnements de préproduction dans Azure App Service.
Les étapes de la vidéo sont également décrites dans les sections suivantes.
Prérequis
Pour plus d’informations sur les autorisations dont vous avez besoin pour effectuer l’opération d’emplacement souhaitée, consultez Opérations du fournisseur de ressources (recherchez emplacement, par exemple).
Ajouter un emplacement
Pour que vous puissiez activer plusieurs emplacements de déploiement, l’application doit s’exécuter au niveau Standard, Premium ou Isolé.
Dans le portail Azure, accédez à la page de gestion de votre application.
Dans le volet gauche, sélectionnez Emplacements de déploiement>Ajouter un emplacement.
Notes
Si l’application n’est pas encore au niveau Standard, Premium ou Isolé, sélectionnez Mettre à niveau et accédez à l’onglet Mise à l’échelle de votre application avant de continuer.
Dans la boîte de dialogue Ajouter un emplacement, nommez l’emplacement, puis indiquez si vous souhaitez cloner une configuration d’application à partir d’un autre emplacement de déploiement. Sélectionnez Ajouter pour continuer.
Vous pouvez cloner une configuration à partir d’un emplacement existant. Parmi les paramètres pouvant être clonés figurent des paramètres de l’application, des chaînes de connexion, des versions du framework de langage, des sockets web, la version HTTP et le nombre de bits de la plateforme.
Notes
Actuellement, un point de terminaison privé n’est pas cloné entre les emplacements.
Une fois l’emplacement ajouté, sélectionnez Fermer pour fermer la boîte de dialogue. Le nouvel emplacement est désormais affiché dans la page Emplacements de déploiement. Par défaut, l’option % de trafic est définie sur 0 pour le nouvel emplacement, avec tout le trafic client acheminé vers l’emplacement de production.
Sélectionnez le nouvel emplacement de déploiement pour ouvrir la page des ressources de cet emplacement.
L’emplacement intermédiaire dispose d’une page de gestion, comme n’importe quelle application App Service. Vous pouvez modifier la configuration de l’emplacement. Pour vous rappeler que vous affichez l’emplacement de déploiement, le nom de l’application est affiché sous la forme <nom-application>/<nom-emplacement>, et le type d’application est App Service (emplacement). Vous pouvez également afficher l’emplacement sous la forme d’une application distincte dans votre groupe de ressources, avec les mêmes désignations.
Sélectionnez l’URL de l’application dans la page des ressources de l’emplacement. L’emplacement de déploiement est une application en production et il a son propre nom d’hôte. Pour limiter l’accès public à l’emplacement de déploiement, consultez Restrictions d’adresse IP avec Azure App Service.
Le nouvel emplacement de déploiement n’a aucun contenu, même si vous clonez les paramètres à partir d’un autre emplacement. Par exemple, vous pouvez publier sur cet emplacement avec Git. Vous pouvez effectuer un déploiement sur l’emplacement à partir d’une autre branche du dépôt, ou d’un dépôt différent. L’obtention du profil de publication dans Azure App Service peut vous fournir les informations nécessaires pour le déploiement sur l’emplacement. Le profil peut être importé par Visual Studio pour déployer du contenu sur l’emplacement.
L’URL de l’emplacement est au format http://sitename-slotname.azurewebsites.net. Pour conserver la longueur de l’URL dans les limites DNS nécessaires, le nom du site est tronqué à 40 caractères, tandis que la combinaison nom de site et nom d’emplacement doit être inférieure à 59 caractères.
Que se passe-t-il pendant un échange ?
Étapes qui composent une opération d’échange
Lorsque vous échangez deux emplacements (en général, vous passez d’un emplacement de préproduction comme source à un emplacement de production comme cible), App Service effectue ce qui suit pour éviter que l’emplacement cible ne subisse un temps d’arrêt :
Applique les paramètres suivants de l’emplacement cible (par exemple, l’emplacement de production) à toutes les instances de l’emplacement source :
- Les paramètres d’application et les chaînes de connexion propres aux emplacements (si nécessaire)
- Les paramètres de déploiement continu (si activés)
- Les paramètres relatifs à l’authentification App Service (si activés)
Quand l’un des paramètres est appliqué à l’emplacement source, la modification déclenche le redémarrage de toutes les instances dans l’emplacement source. Au cours d’un échange avec aperçu, cela marque la fin de la première phase. L’opération d’échange est suspendue, ce qui vous permet de vérifier que l’emplacement source fonctionne correctement avec les paramètres de l’emplacement cible.
Attendez que chaque instance de l’emplacement source ait terminé son redémarrage. Si l’une des instances ne parvient pas à redémarrer, l’opération d’échange rétablit toutes les modifications apportées à l’emplacement source, puis cesse d’être exécutée.
Si le cache local est activé, déclenchez son initialisation en envoyant une requête HTTP à la racine de l’application (« / »), sur chaque instance de l’emplacement source. Attendez que chaque instance retourne une réponse HTTP. L’initialisation du cache local provoque un autre redémarrage sur chaque instance.
Si un échange automatique est activé avec une initialisation personnalisée, déclenchez l’initialisation de l’application personnalisée sur chaque instance de l’emplacement source.
Si
applicationInitializationn’est pas spécifié, déclenchez une requête HTTP à la racine de l’application de l’emplacement source sur chaque instance.Si une instance retourne une réponse HTTP, elle est considérée comme initialisée.
Si toutes les instances de l’emplacement source sont correctement initialisées, échangez les deux emplacements en échangeant leurs règles de routage. Après cette étape, l’emplacement cible (par exemple, l’emplacement de production) dispose de l’application déjà initialisée dans l’emplacement source.
Maintenant que l’emplacement source dispose de l’application de l’emplacement cible avant échange, effectuez la même opération en appliquant tous les paramètres et en redémarrant les instances.
Lors d’une opération d’échange, l’intégralité du processus d’initialisation des applications échangées se déroule dans l’emplacement source. L’emplacement cible reste en ligne pendant la préparation et l’initialisation de l’emplacement source, que l’échange ait réussi ou échoué. Pour permuter un emplacement de préproduction avec l’emplacement de production, assurez-vous que l’emplacement de production est toujours l’emplacement cible. De cette façon, l’opération d’échange n’affectera pas votre application de production.
Notes
Les instances de vos anciennes instances de production (qui seront échangées dans l’environnement intermédiaire après cette opération d’échange) seront recyclées rapidement au cours de la dernière étape du processus d’échange. Si vous avez des opérations de longue durée dans votre application, elles sont abandonnées, lors du recyclage des travaux. Cela s’applique également aux applications de fonction. Par conséquent, votre code d’application doit être écrit d’une manière tolérante aux pannes.
Quels sont les paramètres échangés ?
Lorsque vous clonez la configuration depuis un autre emplacement de déploiement, celle-ci est modifiable. Au cours d’un échange, certains éléments de configuration suivent le contenu (éléments non propres à un emplacement) tandis que d’autres restent dans le même emplacement après l’échange (éléments propres à un emplacement). Les listes suivantes représentent les paramètres qui évoluent lorsque vous échangez les emplacements.
Paramètres échangés:
- Pile de langues et version, 32/64 bits
- Paramètres d’application (peuvent être configurés pour respecter un emplacement)
- Chaînes de connexion (peuvent être configurées pour respecter un emplacement)
- Comptes de stockage montés (peuvent être configurés pour respecter un emplacement)
- Mappages de gestionnaires
- Certificats publics
- Contenu WebJobs
- Connexions hybrides*
- Points de terminaison de service*
- Azure Content Delivery Network*
- Mappages de chemin d’accès
Il est prévu que les fonctionnalités marquées d’un astérisque (*) ne soient plus échangées.
Paramètres non échangés :
- Paramètres généraux non mentionnés dans les paramètres qui sont échangés
- Points de terminaison de publication
- Noms de domaine personnalisés
- Certificats non publics et paramètres TLS/SSL
- Paramètres de mise à l’échelle
- Planificateurs WebJobs
- Restrictions d’adresse IP
- Always On
- Paramètres de diagnostic
- Partage des ressources cross-origin (CORS)
- Intégration du réseau virtuel
- Identités managées et paramètres associés
- Paramètres se terminant par le suffixe _EXTENSION_VERSION
- Paramètres créés par Connecteur de services
Remarque
Pour rendre ces paramètres remplaçables, ajoutez le paramètre d’application WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS dans chaque emplacement de l’application, et affectez-lui la valeur 0 ou false. Ces paramètres sont tous remplaçables ou aucun d’entre eux ne l’est. Vous ne pouvez pas rendre certains paramètres remplaçables et d’autres, pas. Les identités managées ne sont jamais échangées et ne sont pas affectées par ce paramètre d’application de remplacement.
Certains paramètres d’application qui s’appliquent à des paramètres non échangés ne sont pas non plus échangés. Par exemple, étant donné que les paramètres de diagnostic ne sont pas échangés, les paramètres d’application associés comme WEBSITE_HTTPLOGGING_RETENTION_DAYS et DIAGNOSTICS_AZUREBLOBRETENTIONDAYS ne sont pas non plus échangés, même s’ils n’apparaissent pas comme des paramètres d’emplacement.
Si vous souhaitez configurer un paramètre d’application ou une chaîne de connexion pour qu’ils restent dans leur emplacement d’origine (et ne puissent donc pas être échangés), accédez à la page Configuration de l’emplacement en question. Ajoutez ou modifiez un paramètre, puis sélectionnez Paramètre d’emplacement de déploiement. Le fait de cocher cette case indique à App Service que le paramètre n’est pas échangeable.
Permuter deux emplacements
Vous pouvez échanger des emplacements de déploiement dans la page Emplacements de déploiement et la page Vue d’ensemble de votre application. Pour obtenir des détails techniques sur l’échange des emplacements, consultez Que se passe-t-il pendant un échange ?.
Important
Avant de basculer une application de l’emplacement de déploiement vers l’emplacement de production, vérifiez que l’emplacement de production est bien votre emplacement cible, et que tous les paramètres de l’emplacement source sont configurés comme vous le souhaitez dans l’emplacement de production.
Pour échanger des emplacements de déploiement :
Accédez à la page Emplacements de déploiement de votre application, puis sélectionnez Échanger.
La boîte de dialogue Échanger regroupe les paramètres des emplacements source et cible sélectionnés qui vont être échangés.
Sélectionnez les emplacements Source et Cible souhaités. En général, la cible correspond à l’emplacement de production. Sélectionnez également les onglets Modifications sources et Modifications cibles pour vérifier que les changements de configuration à opérer correspondent à ce que vous attendez. Lorsque vous avez terminé, vous pouvez échanger les emplacements immédiatement en sélectionnant Échanger.
Pour voir comment votre emplacement cible s’exécuterait avec les nouveaux paramètres avant que l’échange ne soit réellement effectué, ne sélectionnez pas Échanger, mais suivez les instructions fournies dans Échange avec aperçu.
Lorsque vous avez terminé, fermez la boîte de dialogue en sélectionnant Fermer.
Si vous rencontrez des problèmes, consultez Résoudre les problèmes liés aux échanges.
Échange avec aperçu (échange multiphase)
Avant de passer à l’emplacement de production (emplacement cible), contrôlez l’exécution de l’application avec les paramètres échangés. L’emplacement source est également initialisé avant la fin de l’échange, ce qui est souhaitable pour les applications stratégiques.
Lorsque vous effectuez un échange avec aperçu, App Service effectue la même opération d’échange, mais il fait une pause après la première étape. Vous pouvez donc vérifier le résultat sur l’emplacement de préproduction avant la fin de l’échange.
Si vous annulez l’échange, App Service réapplique les éléments de configuration à l’emplacement source.
Notes
L’échange avec aperçu ne peut pas être utilisé quand l’authentification de site est activée pour l’un des emplacements.
Pour effectuer un échange avec aperçu :
Procédez comme indiqué dans Échanger des emplacements de déploiement, mais sélectionnez Effectuer l’échange avec aperçu.
La boîte de dialogue montre comment la configuration de l’emplacement source est modifiée dans la phase 1, et comment les emplacements source et cible sont modifiés dans la phase 2.
Lorsque vous êtes prêt à démarrer l’échange, sélectionnez Démarrer l’échange.
Lorsque la phase 1 est terminée, vous en êtes averti dans la boîte de dialogue. Affichez l’aperçu de l’échange dans l’emplacement source en accédant à
https://<app_name>-<source-slot-name>.azurewebsites.net.Lorsque vous êtes prêt à effectuer l’échange en attente, sélectionnez Terminer l’échange dans Action d’échange, puis sélectionnez Terminer l’échange.
Pour annuler un échange en attente, sélectionnez Annuler l’échange à la place, puis sélectionnez Annuler l’échange en bas.
Lorsque vous avez terminé, fermez la boîte de dialogue en sélectionnant Fermer.
Si vous rencontrez des problèmes, consultez Résoudre les problèmes liés aux échanges.
Restaurer un échange
Si des erreurs se produisent dans l’emplacement cible (par exemple, l’emplacement de production) après une permutation d’emplacements, rétablissez ces deux emplacements comme ils étaient avant l’opération, en les intervertissant immédiatement.
Configurer l’échange automatique
Notes
L’échange automatique n’est pas pris en charge dans les applications web sur Linux et Web App pour conteneurs.
L’échange automatique simplifie les scénarios Azure DevOps impliquant un déploiement de l’application en continu, sans démarrage à froid ni temps d’arrêt pour les utilisateurs de l’application. Lorsque vous activez l’échange automatique d’un emplacement vers l’emplacement de production, chaque fois que vous envoyez (push) des modifications de votre code à cet emplacement, App Service fait basculer automatiquement l’application vers la production après son initialisation dans l’emplacement source.
Notes
Avant de configurer l’échange automatique pour l’emplacement de production, il est conseillé de tester l’échange automatique sur un emplacement cible hors production.
Pour configurer l’échange automatique :
Accédez à la page des ressources de votre application. Sélectionnez Emplacements de déploiement><emplacement source souhaité>>Configuration>Paramètres généraux.
Pour Échange automatique activé, sélectionnez Activé. Ensuite, sélectionnez l’emplacement cible souhaité pour Échanger automatiquement l’emplacement de déploiement, puis sélectionnez Enregistrer dans la barre de commandes.
Exécutez un push de code sur l’emplacement source. L’échange automatique se produit peu après, et la mise à jour est appliquée dans l’URL de votre emplacement cible.
Si vous rencontrez des problèmes, consultez Résoudre les problèmes liés aux échanges.
Spécifier l’initialisation personnalisée
Certaines applications peuvent nécessiter quelques actions préparatoires personnalisées avant l’échange. L’élément de configuration applicationInitialization du fichier web.config vous permet de spécifier les actions d’initialisation personnalisées à exécuter. L’opération d’échange attend la fin de l’initialisation personnalisée pour procéder à l’échange avec l’emplacement cible. Voici un exemple de fragment web.config.
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
Pour plus d’informations sur la personnalisation de l’élément applicationInitialization, consultez Most common deployment slot swap failures and how to fix them.
Vous pouvez également personnaliser le comportement d’initialisation en utilisant l’un des deux paramètres d’application suivants (ou les deux) :
WEBSITE_SWAP_WARMUP_PING_PATH: chemin permettant d’effectuer un test ping sur HTTP afin d’initialiser votre site. Ajoutez ce paramètre d’application en spécifiant un chemin d’accès personnalisé qui commence par une barre oblique comme valeur. par exemple/statuscheck. La valeur par défaut est/.WEBSITE_SWAP_WARMUP_PING_STATUSES: Codes de réponse HTTP valides pour l’opération d'initialisation. Ajoutez ce paramètre d’application avec une liste séparée par des virgules de codes HTTP. Par exemple200,202. Si le code d’état retourné ne figure pas dans la liste, les opérations d’initialisation et d’échange sont arrêtées. Par défaut, tous les codes de réponse sont valides.WEBSITE_WARMUP_PATH: chemin d’accès relatif sur le site qui doit faire l’objet d’un test ping à chaque redémarrage du site (pas seulement pendant les échanges d’emplacements). Les valeurs sont, par exemple,/statuscheckou le chemin d’accès racine,/.
Notes
L’élément de configuration <applicationInitialization> fait partie de chaque démarrage d’application, tandis que les deux paramètres d’application de comportement de préchauffage s’appliquent uniquement aux échanges d’emplacements.
Si vous rencontrez des problèmes, consultez Résoudre les problèmes liés aux échanges.
Superviser un échange
Si l’exécution de l’opération d’échange prend beaucoup de temps, vous pouvez obtenir des informations au sujet de cette opération dans le journal d’activité.
Sur le portail, dans la page des ressources de votre application, sélectionnez Journal d’activité dans le volet de gauche.
Une opération d’échange s’affiche dans la requête de journal en tant que Swap Web App Slots. Vous pouvez la développer et sélectionner l’une des sous-opérations ou erreurs afin d’afficher le contenu en détail.
Acheminer le trafic de production automatiquement
Par défaut, toutes les requêtes clientes vers les URL de production de l’application (http://<app_name>.azurewebsites.net) sont acheminées vers l’emplacement de production. Vous pouvez acheminer une partie du trafic vers un autre emplacement. Cette fonctionnalité est utile si vous avez besoin d’un retour d’expérience utilisateur pour une nouvelle mise à jour, mais que vous n’êtes pas prêt à la publier en production.
Pour router le trafic de production automatiquement :
Accédez à la page des ressources de votre application et sélectionnez Emplacements de déploiement.
Dans la colonne % de trafic de l’emplacement vers lequel vous souhaitez acheminer le trafic, spécifiez un pourcentage (compris entre 0 et 100) pour représenter la quantité totale de trafic à diriger. Sélectionnez Enregistrer.
Une fois le paramètre enregistré, le pourcentage de clients spécifié est routé de manière aléatoire vers l’emplacement hors production.
Une fois qu’un client est automatiquement routé vers un emplacement spécifique, il est « épinglé » à cet emplacement pendant une heure ou jusqu’à ce que les cookies soient supprimés. Dans le navigateur client, vous pouvez voir à quel emplacement votre session est épinglée en examinant le cookie x-ms-routing-name dans les en-têtes HTTP. Une requête qui est acheminée vers l’emplacement « intermédiaire » contient le cookie x-ms-routing-name=staging. Une requête qui est acheminée vers l’emplacement de production a le cookie x-ms-routing-name=self.
Acheminer le trafic de production manuellement
Parallèlement au routage automatique du trafic, App Service peut acheminer les requêtes vers un emplacement particulier. Cela s’avère utile si vous souhaitez que vos utilisateurs puissent choisir d’accepter ou de refuser votre application bêta. Pour router le trafic de production manuellement, vous utilisez le paramètre de requête x-ms-routing-name.
Par exemple, pour permettre aux utilisateurs de refuser votre application bêta, vous pouvez placer ce lien dans votre page web :
<a href="<webappname>.azurewebsites.net/?x-ms-routing-name=self">Go back to production app</a>
La chaîne x-ms-routing-name=self spécifie l’emplacement de production. Lorsque le navigateur client accède au lien, il est redirigé vers l’emplacement de production. Chaque requête ultérieure comprendra le cookie x-ms-routing-name=self qui épinglera la session à l’emplacement de production.
Pour donner aux utilisateurs la possibilité d’accepter votre application bêta, définissez le même paramètre de requête avec le nom de l’emplacement hors production. Voici un exemple :
<webappname>.azurewebsites.net/?x-ms-routing-name=staging
Par défaut, les nouveaux emplacements se voient attribuer une règle de routage de 0% (indiquée en gris). Lorsque vous définissez cette valeur explicitement sur 0% (indiquée en noir), vos utilisateurs peuvent accéder à l’emplacement de préproduction manuellement, à l’aide du paramètre de requête x-ms-routing-name. Toutefois, ils ne seront pas routés vers l’emplacement automatiquement, car le pourcentage de routage est défini sur 0. Il s’agit d’un scénario avancé où vous pouvez « cacher » votre emplacement de préproduction du public, tout en permettant aux équipes internes de tester les modifications sur l’emplacement.
Supprimer un emplacement
Recherchez et sélectionnez votre application. Sélectionnez Emplacements de déploiement><emplacement à supprimer>>Vue d’ensemble. Le type d’application est indiqué comme App Service (Emplacement) pour vous rappeler que vous consultez un emplacement de déploiement. Avant de supprimer un emplacement, veillez à l’arrêter et à définir son trafic sur zéro. Sélectionnez Supprimer dans la barre de commandes.
Automatiser avec des modèles Resource Manager
Les modèles Azure Resource Manager sont des fichiers JSON déclaratifs utilisés pour automatiser le déploiement et la configuration de ressources Azure. Pour échanger des emplacements à l’aide de modèles Resource Manager, définissez deux propriétés sur les ressources Microsoft.Web/sites/slots et Microsoft.Web/sites :
buildVersion: cette propriété de type chaîne représente la version actuelle de l’application déployée dans l’emplacement. Par exemple : « v1 », « 1.0.0.1 » ou « 2019-09-20T11:53:25.2887393-07:00 ».targetBuildVersion: propriété de type chaîne spécifiant la valeurbuildVersionque l’emplacement doit avoir. SitargetBuildVersionn’est pas égal aubuildVersionactuel, cela déclenche l’opération d’échange en trouvant l’emplacement avec lebuildVersionspécifié.
Exemple de modèle Resource Manager
Le modèle Resource Manager suivant échange deux emplacements en mettant à jour le buildVersion de l’emplacement staging et en définissant le targetBuildVersion sur l’emplacement de production. Il suppose que vous avez créé un emplacement appelé staging.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"my_site_name": {
"defaultValue": "SwapAPIDemo",
"type": "String"
},
"sites_buildVersion": {
"defaultValue": "v1",
"type": "String"
}
},
"resources": [
{
"type": "Microsoft.Web/sites/slots",
"apiVersion": "2018-02-01",
"name": "[concat(parameters('my_site_name'), '/staging')]",
"location": "East US",
"kind": "app",
"properties": {
"buildVersion": "[parameters('sites_buildVersion')]"
}
},
{
"type": "Microsoft.Web/sites",
"apiVersion": "2018-02-01",
"name": "[parameters('my_site_name')]",
"location": "East US",
"kind": "app",
"dependsOn": [
"[resourceId('Microsoft.Web/sites/slots', parameters('my_site_name'), 'staging')]"
],
"properties": {
"targetBuildVersion": "[parameters('sites_buildVersion')]"
}
}
]
}
Ce modèle Resource Manager est idempotent, ce qui signifie qu’il peut être exécuté à plusieurs reprises et produire le même état des emplacements. Sans modification du modèle, les exécutions suivantes du même modèle ne déclenchent aucun échange d’emplacement, car les emplacements sont déjà dans l’état souhaité.
Résoudre les problèmes liés aux échanges
Si une erreur se produit pendant un échange d’emplacement, celle-ci est journalisée dans D:\home\LogFiles\eventlog.xml. Elle est également journalisée dans le journal des erreurs propres à l’application.
Voici quelques erreurs courantes liées aux échanges :
Une requête HTTP envoyée à la racine de l’application a expiré. L’opération d’échange attend 90 secondes pour chaque requête HTTP, et retente jusqu’à cinq fois. Si toutes les nouvelles tentatives expirent elles aussi, l’opération d’échange est arrêtée.
L’initialisation du cache local peut échouer si le contenu de l’application dépasse le quota de disque local spécifié. Pour plus d’informations, consultez Vue d’ensemble du cache local.
Pendant une opération de mise à jour de site, l’erreur suivante peut se produire « L’emplacement ne peut pas être modifié, car ses paramètres de configuration ont été préparés pour l’échange ». Cela peut se produire si l’échange avec la phase 1 de préversion (permutation à plusieurs phases) a été terminée, mais que la phase 2 n’a pas encore été effectuée ou si un échange a échoué. Il existe deux façons de résoudre ce problème :
- Annuler l’opération d’échange qui réinitialise le site à l’ancien état
- Terminer l’opération d’échange qui met à jour le site à l’état souhaité
Reportez-vous à l’échange avec la préversion (échange multi-phase) pour savoir comment annuler ou terminer l’opération d’échange.
Pendant l’initialisation personnalisée, les requêtes HTTP sont effectuées en interne (sans passer par l’URL externe). Elles peuvent échouer avec certaines règles de réécriture d’URL dans Web.config. Par exemple, les règles de redirection des noms de domaine ou d’application du protocole HTTPS peuvent empêcher les requêtes d’initialisation d’atteindre le code de l’application. Pour contourner ce problème, modifiez vos règles de réécriture en ajoutant les deux conditions suivantes :
<conditions> <add input="{WARMUP_REQUEST}" pattern="1" negate="true" /> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>Sans une initialisation personnalisée, les règles de réécriture d’URL peuvent encore bloquer les requêtes HTTP. Pour contourner ce problème, modifiez vos règles de réécriture en ajoutant la condition suivante :
<conditions> <add input="{REMOTE_ADDR}" pattern="^100?\." negate="true" /> ... </conditions>Après des échanges d’emplacements, l’application peut rencontrer des redémarrages inattendus. En effet, après un échange, la configuration de la liaison du nom d’hôte se désynchronise, ce qui n’entraîne pas de redémarrages. En revanche, certains événements de stockage sous-jacents (comme des basculements de volume de stockage) peuvent détecter ces différences et forcer le redémarrage de tous les processus Worker. Pour minimiser ces types de redémarrages, définissez le paramètre d’application
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1sur tous les emplacements. En revanche, ce paramètre d’application ne fonctionne pas avec des applications Windows Communication Foundation (WCF).