Configurer des environnements intermédiaires dans Azure App Service
Remarque
À compter du 1er juin 2024, les applications App Service nouvellement créées peuvent générer un nom d’hôte par défaut unique qui utilise la convention d’affectation de noms <app-name>-<random-hash>.<region>.azurewebsites.net. Les noms d’application existants restent inchangés. Par exemple :
myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Pour plus d’informations, consultez Nom d’hôte par défaut unique pour les ressources App Service.
Quand vous déployez votre application web, votre application web sur Linux, votre backend mobile ou votre application API sur Azure App Service, vous pouvez utiliser un autre emplacement de déploiement que l’emplacement de production par défaut. Cette approche est disponible si vous fonctionnez dans le niveau de plan App Service Standard, Premium ou Isolé. Les emplacements de déploiement sont des applications en direct avec leurs propres noms 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 la basculer dans l’emplacement de production.
- Déployer d’abord une application dans un emplacement et la basculer ensuite en production permet d’assurer que toutes les instances de l’emplacement sont initialisées avant de les basculer en production. Cette approche permet d’éliminer les temps d’arrêt quand vous déployez votre application. La redirection du trafic est transparente. Aucune demande n’est supprimée en raison d’opérations d’échange. 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 basculées dans l’emplacement de production ne vous conviennent pas, vous pouvez effectuer la même bascule immédiatement pour revenir à votre dernier site fonctionnel connu.
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 a plus de cinq emplacements, vous ne pouvez pas effectuer de scale-down vers le niveau Standard. 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 un 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 Déploiement>Emplacements de déploiement>Ajouter.
Remarque
Si l’application n’est pas déjà dans le niveau Standard, Premium ou Isolé, sélectionnez Mettre à niveau. Accédez à l’onglet Mettre à 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 les paramètres entrés, 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 s’affiche sous la forme <nom-d’application>/<nom-d’emplacement>. 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. Visual Studio peut importer le profil pour déployer un contenu sur l’emplacement.
L’URL de l’emplacement est au format http://sitename-slotname.azurewebsites.net. Pour maintenir la longueur de l’URL dans les limites DNS nécessaires, le nom du site est tronqué à 40 caractères. La combinaison du nom de site et du 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
Quand vous basculez deux emplacements, App Service effectue ce qui suit pour s’assurer que l’emplacement cible ne subit de 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’une bascule avec aperçu, cette action marque la fin de la première phase. L’opération de bascule est en attente. Vous pouvez valider le bon fonctionnement de l’emplacement source 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.
Remarque
Vos anciennes instances de production sont basculées dans l’emplacement intermédiaire après cette opération de bascule. Ces instances sont recyclées à la dernière étape du processus de bascule. Si votre application effectue des opérations de longue durée, elles sont abandonnées lors du recyclage des Workers. Ce fait s’applique également aux applications de fonction. Par conséquent, votre code d’application doit être écrit d’une manière tolérante aux défauts.
Quels sont les paramètres échangés ?
Lorsque vous clonez la configuration depuis un autre emplacement de déploiement, celle-ci est modifiable. Certains éléments de configuration suivent le contenu à travers une bascule (pas d’emplacement spécifique). D’autres éléments de configuration restent dans le même emplacement après une bascule (emplacement spécifique). 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 les paramètres compatibles avec l’échange, ajoutez le paramètre d’application WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS dans chaque emplacement de l’application et définissez sa valeur sur 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 basculées. Ce paramètre d’application de remplacement ne les affecte pas.
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 basculés, les paramètres d’application associés tels que WEBSITE_HTTPLOGGING_RETENTION_DAYS et DIAGNOSTICS_AZUREBLOBRETENTIONDAYS ne le sont pas non plus, même s’ils n’apparaissent pas comme des paramètres d’emplacement.
Pour configurer un paramètre d’application ou une chaîne de connexion pour qu’ils restent dans un emplacement spécifique, qui n’est pas basculé, accédez à la page Paramètres>Variable d’environnement de cet emplacement. Ajoutez ou modifiez un paramètre, puis sélectionnez Paramètre d’emplacement de déploiement. La sélection de cette option indique à App Service que le paramètre ne peut pas être basculé.
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 plus d’informations sur la bascule d’emplacements, consultez Que se passe-t-il pendant une bascule ?.
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 Basculer montre les paramètres des emplacements source et cible sélectionnés à basculer.
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. Quand vous avez fini, vous pouvez basculer les emplacements immédiatement en sélectionnant Basculer.
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.
Quand vous avez fini, sélectionnez Fermer pour fermer la boîte de dialogue.
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.
Quand la phase 1 est terminée, la boîte de dialogue vous avertit. 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.
Quand vous avez fini, sélectionnez Fermer pour fermer la boîte de dialogue.
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 Déploiement>Emplacements de déploiement><Emplacement source souhaité>.
Dans le volet gauche, sélectionnez Paramètres>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. La bascule automatique se produit après un court délai. La mise à jour se reflète sur 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 dans web.config vous permet de spécifier des actions d’initialisation personnalisées. 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 avec les paramètres d’application suivants :
-
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,/.
Remarque
L’élément de configuration <applicationInitialization> fait partie de chaque démarrage d’application, tandis que les paramètres d’application de comportement d’initialisation s’appliquent uniquement aux bascules 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 web 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. Cliquez sur 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 le client 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 routé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. Cette option est utile si vous souhaitez que vos utilisateurs puissent accepter ou 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. Ils ne seront pas automatiquement routés vers l’emplacement, car le pourcentage de routage est défini sur 0. Cette configuration représente un scénario avancé où vous pouvez cacher votre emplacement intermédiaire 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 Déploiement>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: Propriété de type chaîne qui représente la version actuelle de l’application déployée dans l’emplacement. Par exemple :v1,1.0.0.1ou2019-09-20T11:53:25.2887393-07:00. -
targetBuildVersion: Propriété de type chaîne qui spécifie quelbuildVersionl’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 bascule deux emplacements en mettant à jour le buildVersion de l’emplacement staging et en définissant le targetBuildVersion sur l’emplacement de production. Vous devez disposer d’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')]"
}
}
]
}
Le modèle Resource Manager est idempotent. Vous pouvez l’exécuter à 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 une bascule d’emplacement, celle-ci apparaît 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 une bascule. Cette erreur peut se produire si la phase 1 d’une bascule avec aperçu (échange multiphase) se termine, mais que la phase 2 n’a pas encore été effectuée. Elle peut également se produire si une bascule a échoué. Il existe deux façons de résoudre ce problème :
- Annuler l’opération de bascule qui réinitialise le site à l’ancien état
- Terminer l’opération de bascule qui met à jour le site au nouvel état souhaité
Pour savoir comment annuler ou terminer l’opération de bascule, consultez Bascule avec aperçu (échange multiphase).
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 bascules d’emplacements, l’application peut subir des redémarrages inattendus. Les redémarrages se produisent car, après une bascule, la configuration de la liaison du nom d’hôte se désynchronise. Cette situation elle-même ne provoque pas de redémarrages. Toutefois, certains événements de stockage sous-jacents, tels que des bascules 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. Toutefois, ce paramètre d’application ne fonctionne pas avec des applications Windows Communication Foundation (WCF).