Partager via

Configurer des environnements intermédiaires dans Azure 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 exécutez le niveau Standard, Premium ou Isolé d’un plan 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 web 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’application avant d’échanger l’emplacement en production.

  • Vous pouvez vous assurer que toutes les instances de l’emplacement sont réchauffées avant de l’échanger 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.

L’utilisation de ces emplacements de déploiement n’entraîne aucun coût supplémentaire. Chaque niveau de plan App Service prend en charge un nombre différent d’emplacements de déploiement. Pour connaître le nombre d’emplacements pris en charge par le niveau de votre application, consultez les limites d’App Service.

Pour mettre à l’échelle votre application à un autre niveau, assurez-vous que le niveau cible prend en charge le nombre d’emplacements que votre application utilise déjà. Par exemple, si votre application a plus de cinq emplacements, vous ne pouvez pas la réduire au niveau Standard. Le niveau Standard ne prend en charge que cinq emplacements de déploiement.

La vidéo suivante complète les étapes décrites dans cet article en illustrant comment configurer des environnements intermédiaires dans Azure App Service.

Prérequis

  • Autorisations d’exécution de l’opération d’emplacement souhaitée. Pour plus d’informations sur les autorisations requises, consultez les opérations du fournisseur de ressources. Recherchez un emplacement, par exemple.

Ajouter un emplacement

Pour que vous activez plusieurs emplacements de déploiement, l’application doit s’exécuter dans le niveau Standard, Premium ou Isolé.

  1. Dans le portail Azure, accédez à la page de gestion de votre application.

  2. Dans le menu de gauche, sélectionnez Déploiement>Slots de déploiement. Sélectionnez ensuite 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 Échelle de votre application avant de continuer.

  3. Dans la boîte de dialogue Ajouter un emplacement, donnez un nom à l’emplacement et sélectionnez s’il faut cloner une configuration d’application à partir d’un autre emplacement de déploiement. Sélectionnez Ajouter pour continuer.

    Capture d’écran montrant les sélections pour configurer un nouvel emplacement de déploiement appelé « staging » dans le portail.

    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.

    Remarque

    Actuellement, un point de terminaison privé n’est pas cloné entre les slots.

  4. Après avoir entré les paramètres, sélectionnez Fermer pour fermer la boîte de dialogue. Le nouvel emplacement apparaît maintenant dans la page Emplacements de déploiement . Par défaut, le trafic % est défini sur 0 pour le nouvel emplacement, avec tout le trafic client acheminé vers l’emplacement de production.

  5. Sélectionnez le nouvel emplacement de déploiement pour ouvrir sa page de ressources.

    Capture d’écran montrant comment ouvrir la page de gestion d’un emplacement de déploiement dans le portail.

    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 et le nom de l’emplacement apparaissent dans l’URL. 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.

  6. Dans la page des ressources de l’emplacement, sélectionnez l’URL de l’application. 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 Configurer les restrictions d’accès 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’article Obtenir un profil de publication à partir d’Azure App Service peut fournir les informations requises pour le déploiement sur le slot. 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 conserver la longueur de l’URL dans les limites DNS nécessaires, le nom du site peut être jusqu’à 40 caractères, et le nom de l’emplacement peut être jusqu’à 19 caractères. La longueur combinée du nom du site et du nom de l'emplacement doit être inférieure à 59 caractères.

Comprendre ce qui se passe pendant un échange

Étapes qui composent une opération d’échange

Quand vous échangez deux emplacements, App Service procède comme suit pour s’assurer que l’emplacement cible ne subit pas de temps d’arrêt :

  1. Applique les paramètres suivants de l’emplacement cible (par exemple, l’emplacement de production) à toutes les instances de l’emplacement source :

    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 swap est suspendue. Vous pouvez valider le bon fonctionnement de l’emplacement source avec les paramètres de l’emplacement cible.

  2. 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.

  3. Si le cache local est activé, déclenchez l’initialisation du cache local en effectuant 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.

  4. Si l’échange automatique est activé avec un préchauffage personnalisé, déclenchez l’initialisation de l’application personnalisée sur chaque instance de l’emplacement source.

    Si applicationInitialization n’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 n'importe quelle réponse HTTP, elle est considérée comme prête.

  5. 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.

  6. Maintenant que l’emplacement source a l’application de pré-échange qui était auparavant dans l’emplacement cible, effectuez la même opération en appliquant tous les paramètres et en redémarrant les instances.

À tout moment de l’opération d’échange, tout le travail d’initialisation des applications permutées se produit sur 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 échanger un emplacement de préproduction avec un emplacement de production, vérifiez 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 déplacées vers l'environnement de test après l'exécution de cette opération de bascule. Ces instances sont recyclées à la dernière étape du processus d'échange. 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. Assurez-vous que votre code d’application est écrit de manière tolérante aux pannes.

Quels paramètres sont échangés

Lorsque vous clonez une configuration depuis un autre emplacement de déploiement, la configuration clonée est modifiable. Certains éléments de configuration suivent le contenu d’un échange (ils ne sont pas spécifiques à l’emplacement). D’autres éléments de configuration restent dans le même emplacement après un échange (ils sont spécifiques à l’emplacement).

Lorsque vous échangez des emplacements, ces paramètres sont échangés :

  • Paramètres du framework de langage (par exemple, version .NET, version Java, version PHP, version Python, version Node.js version)
  • Paramètre de plateforme 32 bits vs 64 bits
  • WebSockets activés/désactivés
  • Paramètres de l’application (peuvent être configurés pour coller à un emplacement)
  • Chaînes de connexion (peuvent être configurées pour coller à un emplacement)
  • Comptes de stockage montés (peuvent être configurés pour être fixés à un emplacement)
  • Mappages de gestionnaires
  • Certificats publics
  • Le contenu WebJobs
  • Connexions hybrides
  • Points de terminaison de service
  • Réseau de distribution de contenu Azure
  • Mappages de chemin
  • Intégration du réseau virtuel

Lorsque vous échangez des emplacements, ces paramètres ne sont pas échangés

  • Paramètres de protocole (https uniquement, version TLS, certificats clients) *
  • 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 *
  • Toujours actif *
  • Paramètres du journal de diagnostic *
  • Partage de ressources cross-origin (CORS) *
  • Identités managées
  • Paramètres se terminant par le suffixe _EXTENSION_VERSION
  • Paramètres créés par Service Connector

Remarque

Les paramètres marqués avec * peuvent être échangés en ajoutant le paramètre WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS d’application à chaque emplacement de l’application et en définissant sa valeur sur 0 ou false. Cela revient à l'ancien comportement d'échange de données avant que ces paramètres ne deviennent spécifiques à l’emplacement dédié. Lorsque vous utilisez ce remplacement, ces paramètres marqués deviennent tous échangeables ou tous ne peuvent pas être échangés. Vous ne pouvez pas rendre certains paramètres remplaçables et d’autres, 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 échangés, les paramètres d’application associés comme WEBSITE_HTTPLOGGING_RETENTION_DAYS et DIAGNOSTICS_AZUREBLOBRETENTIONDAYS ne sont pas également échangés, même s’ils ne s’affichent pas en tant que paramètres d’emplacement.

Échanger des emplacements de déploiement

Vous pouvez échanger des emplacements de déploiement dans la page Emplacements de déploiement et la page Vue d’ensemble de votre application.

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.

  1. Accédez à la page Emplacements de déploiement de votre application, puis sélectionnez Échanger.

    Capture d’écran montrant les sélections pour lancer une opération d’échange dans le portail.

    La boîte de dialogue Permutation affiche les paramètres dans les emplacements source et cible sélectionnés à modifier.

  2. Sélectionnez les emplacements Source et Cible souhaités. En général, la cible correspond à l’emplacement de production. Sélectionnez également les modifications de l’emplacement source et les onglets Modifications des emplacements cibles et vérifiez que les modifications de configuration sont attendues. Lorsque vous avez terminé, vous pouvez permuter les emplacements immédiatement en sélectionnant Démarrer l’échange.

    Capture d’écran montrant les sélections pour la configuration et la fin d’un échange dans le portail.

    Pour voir comment votre emplacement cible s’exécuterait avec les nouveaux paramètres avant l’échange, ne sélectionnez pas Démarrer l’échange. Suivez les instructions de Permutation avec préversion plus loin dans cet article.

  3. Sélectionnez Fermer pour fermer la boîte de dialogue.

Si vous rencontrez des problèmes, consultez Résoudre les problèmes d’échange plus loin dans cet article.

Échange avec aperçu (échange multi-phases)

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.

Remarque

Vous ne pouvez pas utiliser l’échange avec la préversion lorsque l’authentification de site est activée dans l’un des emplacements.

  1. Suivez les étapes de la section Échanger les emplacements de déploiement , mais sélectionnez Effectuer l’échange avec la préversion.

    La boîte de dialogue vous montre comment la configuration dans l'emplacement source change lors de la première phase, puis comment les emplacements source et cible changent dans la deuxième phase.

  2. Lorsque vous êtes prêt à démarrer l’échange, sélectionnez Démarrer l’échange.

    Une fois la première phase terminée, la boîte de dialogue vous avertit.

  3. Lorsque vous êtes prêt à terminer l’échange en attente, sélectionnez Terminer l’échange dans l’action Swap, puis sélectionnez le bouton Terminer l’échange.

    Capture d’écran montrant comment configurer un échange avec aperçu dans le portail.

    Pour annuler un échange en attente, sélectionnez Annuler l’échange à la place, puis sélectionnez le bouton Annuler l’échange .

  4. Lorsque vous avez terminé, sélectionnez Fermer pour fermer la boîte de dialogue.

Si vous rencontrez des problèmes, consultez Résoudre les problèmes d’échange plus loin dans cet article.

Annuler 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-les à leur état initial en les permutant de nouveau immédiatement.

Configurer l’échange automatique

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.

Remarque

L’échange automatique n’est pas pris en charge dans les applications web sur Linux et dans Web App pour conteneurs.

Avant de configurer l'échange automatique pour l'emplacement de production, envisagez de le tester sur un emplacement cible hors production.

  1. Accédez à la page des ressources de votre application. Sélectionnez déploiement>Emplacements de déploiement, puis sélectionnez l’emplacement source souhaité.

  2. Dans le menu de gauche, sélectionnez Paramètres>Configuration>Paramètres généraux.

  3. Pour Échange automatique activé, sélectionnez Activé. Pour Emplacement de déploiement avec échange automatique, sélectionnez l’emplacement cible. Sélectionnez Ensuite Enregistrer dans la barre de commandes.

    Capture d’écran montrant les sélections pour la configuration de l’échange automatique dans l’emplacement de production dans le portail.

  4. Exécutez un push de code sur l’emplacement source. L'échange automatique se produit après un court instant. 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 d’échange plus loin dans cet article.

Rendre un paramètre d'application non échangeable

Pour configurer un paramètre d’application en tant que paramètre spécifique d’un emplacement (non échangé) :

  1. Accédez à Paramètres>Variable d'environnement pour cet emplacement.

  2. Ajoutez ou modifiez un paramètre, puis sélectionnez Paramètre d’emplacement de déploiement. Si vous cochez cette case, App Service indique que le paramètre n’est pas permutable.

  3. Sélectionnez Appliquer.

Capture d’écran montrant la case à cocher permettant de configurer un paramètre d’application en tant que paramètre d’emplacement dans le portail Azure.

Spécifier l'échauffement personnalisé

Certaines applications peuvent nécessiter quelques actions préparatoires personnalisées avant l’échange. Vous pouvez spécifier ces actions personnalisées à l’aide de l’élément applicationInitialization de configuration dans Web.config. 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 Web.config de fragment :

<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 le billet de blog Sur les échecs d’échange d’emplacements de déploiement les plus courants et sur la façon de les corriger.

Vous pouvez également personnaliser le comportement de préchauffement à l’aide des 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 exemple 200,202. Si le code d’état retourné n’est pas dans la liste, les opérations de préchauffement 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 incluent par exemple /statuscheck ou le chemin racine, /.

L’élément <applicationInitialization> de configuration fait partie de chaque démarrage de l’application, tandis que les paramètres de l’application pour le comportement de préchauffement s’appliquent uniquement aux échanges d’emplacements.

Si vous rencontrez des problèmes, consultez Résoudre les problèmes d’échange plus loin dans cet article.

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é.

  1. Dans la page de ressources de votre application dans le portail, dans le menu de gauche, sélectionnez Journal d’activité.

  2. Une opération d’échange s’affiche dans la requête de journal en tant que Swap Web App Slots. Pour afficher les détails, vous pouvez le développer et sélectionner l’une des sous-opérations ou erreurs.

Acheminer automatiquement le trafic de production

Par défaut, toutes les demandes clientes adressées à l’URL de production de l’application 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 de commentaires utilisateur pour une nouvelle mise à jour, mais que vous n’êtes pas prêt à le publier en production.

  1. Accédez à la page de ressources de votre application web et sélectionnez Déploiement>Emplacements de déploiement.

  2. Dans la colonne Traffic % de l’emplacement vers lequel vous souhaitez acheminer, spécifiez un pourcentage (compris entre 0 et 100) pour représenter la quantité totale de trafic que vous souhaitez router. Ensuite, sélectionnez Enregistrer.

    Capture d’écran montrant les sélections du portail pour le routage d’un pourcentage de trafic de requête vers un emplacement de déploiement.

Après avoir enregistré le paramètre, le pourcentage spécifié de clients est routé de façon aléatoire vers l’emplacement de non-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 acheminée vers l'emplacement de préparation 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 ont une règle de routage 0%, affiché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 routés automatiquement 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 slot de mise en scène du public, tout en permettant aux équipes internes de tester les modifications sur ce slot.

Supprimer un emplacement

  1. Recherchez et sélectionnez votre application.

  2. Sélectionnez Déploiement>Emplacements de déploiement>Emplacement à supprimer>Aperçu. Le type d’application apparaît en tant que App Service (Slot) pour vous rappeler le fait que vous affichez un slot de déploiement.

  3. Arrêtez l’emplacement et définissez le trafic dans l’emplacement sur zéro.

  4. Dans la barre de commandes, sélectionnez Supprimer.

Capture d’écran montrant les sélections pour la suppression d’un emplacement de déploiement dans le portail.

Automatiser avec des modèles Resource Manager

Les modèles Azure Resource Manager sont des fichiers JSON déclaratifs pour automatiser le déploiement et la configuration des ressources Azure. Pour échanger des emplacements à l’aide de modèles Resource Manager, vous 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.1 ou 2019-09-20T11:53:25.2887393-07:00.
  • targetBuildVersion : Une propriété de chaîne qui spécifie la valeur buildVersion que l'emplacement doit avoir. Si la targetBuildVersion valeur n’est pas égale à la valeur actuelle buildVersion , elle déclenche l’opération d’échange en recherchant l’emplacement avec la valeur spécifiée buildVersion .

Exemple de modèle Resource Manager

Le modèle Resource Manager suivant échange deux emplacements en mettant à jour la buildVersion valeur de l’emplacement staging et en définissant la targetBuildVersion valeur 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 un échange d’emplacement, l’erreur 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 elle 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 lorsque le contenu de l’application dépasse le quota de disque local spécifié pour le cache local. Pour plus d’informations, consultez la vue d’ensemble du cache local Azure App Service.

  • 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 ». Cette erreur peut se produire si la première phase d’un échange à plusieurs phases se termine, mais que la deuxième phase n’a pas eu lieu. Cela peut également se produire si un échange a échoué. Il existe deux façons de résoudre ce problème :

    • Annulez l’opération d’échange, qui réinitialise le site à l’ancien état.
    • Terminez l’opération d’échange, qui met à jour le site à l’état souhaité.

    Pour savoir comment annuler ou terminer l’opération d’échange, consultez Swap with preview (échange en plusieurs phases) plus haut dans cet article.

  • Pendant l’initialisation personnalisée, les requêtes HTTP sont effectuées en interne sans passer par l’URL externe. Ils 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 de préchauffage 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 un échange, la configuration de la liaison de nom d’hôte est obsolète. Cette situation elle-même ne provoque pas de redémarrages. Toutefois, certains événements de stockage sous-jacents, tels que des basculements de volumes de stockage, peuvent déceler ces écarts et obliger tous les processus de travail à redémarrer.

    Pour minimiser ces types de redémarrages, définissez le paramètre d’applicationWEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 sur tous les emplacements. Toutefois, ce paramètre d’application ne fonctionne pas avec des applications Windows Communication Foundation (WCF).

Étape suivante

Configurer des restrictions d’accès dans Azure App Service

  • Last updated on