Tutoriel : Créer une application multirégion hautement disponible dans Azure App Service

La haute disponibilité et la tolérance de panne sont les composants clés d’une solution bien conçue. Une configuration robuste inclut un plan d’urgence pour les défaillances inattendues, afin de réduire les temps d’arrêt et de maintenir l’exécution automatique des systèmes.

Lorsque vous déployez une application dans le cloud, vous choisissez une région dans ce cloud pour la base d’infrastructure d’application. Si vous déployez une application dans une seule région et que cette région devient indisponible, l’application n’est pas disponible. Le manque de disponibilité peut être inacceptable selon les conditions du contrat de niveau de service de l’application (SLA). Pour garantir la disponibilité, déployez l’application et ses services dans plusieurs régions du cloud.

Ce tutoriel explique comment déployer une application web multirégion hautement disponible. La procédure implémente un scénario simple qui se compose d’une application web et de Azure Front Door. Vous pouvez développer les concepts pour prendre en charge d’autres modèles d’infrastructure. Par exemple, si votre application se connecte à une offre de base de données Azure ou à un compte de stockage, consultez Réplication géographique active pour les bases de données SQL et stockage Azure redondance. Pour obtenir une architecture de référence pour un scénario plus détaillé, consultez le modèle d’application web Fiable pour .NET.

Dans ce tutoriel, vous allez :

Prérequis

Si vous n'avez pas de compte Azure, créez un compte free avant de commencer.

Pour suivre ce tutoriel :

• Utilisez l’environnement Bash dans Azure Cloud Shell. Pour plus d’informations, consultez Commencer avec Azure Cloud Shell.

  

• Si vous préférez exécuter des commandes de référence CLI localement, installation la Azure CLI. Si vous exécutez sur Windows ou macOS, envisagez d'exécuter Azure CLI dans un conteneur Docker. Pour plus d’informations, consultez How to run the Azure CLI in a Docker container.

  • Si vous utilisez une installation locale, connectez-vous au Azure CLI à l'aide de la commande az login. Pour finir le processus d’authentification, suivez les étapes affichées dans votre terminal. Pour obtenir d’autres options de connexion, consultez Authenticate pour Azure à l’aide de Azure CLI.

  • Lorsque vous y êtes invité, installez l'extension Azure CLI lors de la première utilisation. Pour plus d’informations sur les extensions, consultez Utilisez et gérez les extensions avec le Azure CLI.

  • Exécutez az version pour rechercher la version et les bibliothèques dépendantes installées. Pour effectuer une mise à niveau vers la dernière version, exécutez az upgrade.

Passer en revue l’architecture du scénario

Le diagramme d’architecture suivant montre l’infrastructure que vous créez dans ce tutoriel. Il se compose de deux applications App Service identiques dans des régions distinctes. La première application web se trouve dans la région active. Il s’agit de l’application principale responsable du traitement du trafic entrant. La deuxième application se trouve dans la région de veille et attend que l'application principale soit disponible. Azure Front Door tente d’acheminer le trafic vers l’application web principale. Lorsque la région primaire n’est pas disponible, le trafic est acheminé vers le web de secours. Dans le diagramme, la ligne en pointillé représente le routage du trafic en fonction de l’état de la région. Les restrictions d’accès sont configurées afin de bloquer l’accès direct aux applications à partir d’Internet.

Azure propose différentes options pour l’équilibrage de charge et le routage du trafic. Azure Front Door est sélectionné pour ce didacticiel, car il implique des applications web accessibles sur Internet hébergées sur Azure App Service déployées dans plusieurs régions. Si votre configuration diffère de l’exemple de ce didacticiel, consultez Choisir une solution d’équilibrage de charge pour votre scénario.

Le scénario de ce didacticiel fournit le comportement suivant :

• Les applications App Service identiques sont déployées dans deux régions distinctes.
• Le trafic public envoyé directement aux applications web est bloqué.
• Azure Front Door achemine le trafic vers l’application active dans la région primaire.
• L’application de secours dans la région secondaire est disponible pour servir le trafic, si nécessaire.

Créer un groupe de ressources

Vous avez besoin de deux instances d’une application web qui s’exécutent dans différentes régions Azure pour ce didacticiel.

1. Passez en revue les paires de régions disponibles et sélectionnez deux régions jumelées pour vos applications web.

   Dans ce tutoriel, les deux régions sont appelées <primary-region> (eastus) et <standby-region> (westus).

2. Créez un groupe de ressources pour toutes les ressources que vous configurez dans ce tutoriel. Ce tutoriel crée le groupe de ressources à l’emplacement <primary-region> .

   az group create --name <resource-group> --location <primary-region>
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --name	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --location	<primary-region>	Emplacement de région du groupe de ressources. Ce tutoriel utilise le même emplacement de région pour le groupe de ressources et l’application web principale.	eastus

   Dans une implémentation réelle, utilisez des groupes de ressources distincts pour chaque région/ressource. La séparation permet l’isolation des ressources dans une situation de récupération d’urgence.

   Pour plus d’informations, consultez la référence de commande az group create .

Créer deux plans App Service

Créez deux plans App Service, un pour chaque application web. Créez chaque plan à l’emplacement de la région où vous prévoyez de créer l’application correspondante.

Pour cette commande, vous utilisez la paire de régions que vous avez sélectionnée précédemment. Utilisez la région active pour l’application web principale et la région passive de l’application web de secours.

Exécutez la commande suivante pour créer le plan App Service pour l’application web principale, puis réexécutez la commande pour créer le plan de l’application de secours.

az appservice plan create --name <app-service-plan> --resource-group <resource-group> --is-linux --location `<region>`

Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

Pour plus d'informations, consultez la référence de la commande az appservice plan create.

Créer deux applications

Créez deux applications web App Service. Placez chaque application dans un plan App Service et un emplacement de région correspondants.

1. Identifiez la --runtime version linguistique des applications web.

   Vous pouvez exécuter la commande suivante pour la liste des runtimes disponibles :

   az webapp list-runtimes
   

   Si vous envisagez d’utiliser l’exemple d’application Node.js décrit dans ce tutoriel, définissez la valeur <language-version> à NODE:24-lts.

2. Créez deux applications web. Exécutez la commande suivante pour créer l’application web principale, puis réexécutez la commande pour créer l’application de secours.

   az webapp create --name <web-app-name> --resource-group <resource-group> --plan <app-service-plan> --runtime <language-version>
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --name	<web-app-name>	Nom de l’application web. Chaque application doit avoir un nom global unique. Les caractères valides sont a-z, 0-9et -.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --name	<app-service-plan>	Nom du plan App Service pour l’application web.	zava-primary-plan zava-standby-plan
   --runtime	<language-version>	Version du langage d’exécution de l’application web.	NODE:24-lts

   Pour plus d’informations, consultez la référence de commande az webapp create .

3. Identifiez la defaultHostName valeur de chaque application web. Le format du nom d’hôte est <web-app-name>.azurewebsites.net.

   Analysez la sortie de commande pour chaque application web et recherchez la valeur, ou exécutez la commande suivante pour chaque application web :

   az webapp show --name <web-app-name> --resource-group <resource-group> --query "hostNames"
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --name	<web-app-name>	Nom de l’application web.	zava-primary-app zava-standby-app
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group

   Dans le portail Azure, le nom d’hôte de chaque application est visible sur la page Overview.

   Enregistrez les valeurs du nom d’hôte pour les versions ultérieures. Vous utilisez les noms d’hôte pour définir les adresses back-end pour Azure Front Door déploiement.

4. Vérifiez que vous pouvez accéder aux nouvelles applications web.

   1. Dans un navigateur, entrez le nom d’hôte de l’application web principale, tel que zava-primary-app.azurewebsites.net.

      Une fois la connexion établie, le message suivant s’affiche :

      

   2. Répétez le test avec le nom d’hôte de votre application web de secours.

Configurer Azure Front Door

Un déploiement multirégion peut utiliser une configuration active-active ou active-passive . La région primaire est active et la région de secours est passive.

• Une configuration active-active répartit les requêtes entre plusieurs régions actives.
• Une configuration active-passive continue d’exécuter des instances dans la région de secours (passive), mais n’envoie pas le trafic là-bas, sauf si la région principale (active) échoue.

Azure Front Door vous permet d’activer les deux configurations. Pour plus d’informations sur la conception d’applications pour la haute disponibilité et la tolérance de panne, consultez la liste de vérification de la révision de conception pour la fiabilité.

Créer un profil

Créez une instance de Azure Front Door Premium pour acheminer le trafic vers vos applications web.

1. Passez en revue la comparaison de niveaux Azure Front Door et sélectionnez le niveau de votre déploiement.

   Ce didacticiel utilise Azure Front Door Premium (Premium_AzureFrontDoor).

   Si vous préférez déployer Azure Front Door Standard, n'oubliez pas que le niveau Standard ne prend pas en charge le déploiement de règles managées avec la stratégie WAF.

2. Exécutez la commande suivante pour créer le profil :

   az afd profile create --profile-name <front-door-profile> --resource-group <resource-group> --sku <front-door-tier>
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --profile-name	<front-door-profile>	Nom du profil Azure Front Door. Le nom doit être unique au sein du groupe de ressources.	zava-profile
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --sku	<front-door-tier>	La référence SKU d’Azure Front Door utilisée pour le déploiement.	Premium_AzureFrontDoor (recommandé) Standard_AzureFrontDoor

   Pour plus d’informations, consultez la référence de la commande az afd profile create.

Ajout d’un point de terminaison

Créez un point de terminaison dans votre profil. Après avoir créé le premier point de terminaison, vous pouvez créer plusieurs points de terminaison dans votre profil.

az afd endpoint create --resource-group <resource-group> --endpoint-name <front-door-endpoint> --profile-name <front-door-profile> --enabled-state Enabled

Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

Pour plus d’informations, consultez la référence de commande az afd endpoint create .

Créer un groupe d’origins

Lorsque vous déployez sur Azure Front Door, vous avez besoin d’une origine pour servir de point de terminaison pour votre serveur principal d’application web. Pour plus d’informations, consultez Origins et groupes d’origines dans Azure Front Door. Les origines sont stockées dans un groupe d’origines.

Créez un groupe d’origines dans votre profil Azure Front Door pour contenir des origines pour vos deux applications web.

az afd origin-group create --resource-group <resource-group> --origin-group-name <front-door-origin-group> --profile-name <front-door-profile> \
   --probe-request-type <probe-request> \
   --probe-protocol <probe-protocol> \
   --probe-interval-in-seconds <probe-interval> \
   --probe-path <probe-path> \
   --sample-size <sample-size> \
   --successful-samples-required <required-samples> \
   --additional-latency-in-milliseconds <extra-latency>

Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

Pour plus d’informations, consultez la référence de la commande az afd origin-group create.

Ajouter des origines au groupe d’origine

Ajoutez une origine pour chacune de vos applications web à votre groupe d’origines Azure Front Door.

1. Ajoutez une origine pour l’application web principale . Définissez le paramètre --priority sur 1, ce qui informe Azure Front Door que cette application est le récepteur principal du trafic.

   az afd origin create --resource-group <resource-group> --host-name <web-app-name>.azurewebsites.net --profile-name <front-door-profile> \
      --origin-group-name <front-door-origin-group> \
      --origin-name <web-app-origin-name> \
      --origin-host-header <web-app-name>.azurewebsites.net \
      --priority <origin-priority> --weight <origin-weight> --enabled-state <origin-state> \
      --http-port <origin-port> --https-port <origin-secure-port>
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --host-name	<web-app-name>.azurewebsites.net	Nom d’hôte de votre application web principale . Le nom d’hôte combine le nom de l’application web, tel que zava-primary-app, avec l’identificateur de l’hôte, azurewebsites.net.	zava-primary-app.azurewebsites.net
   --profile-name	<front-door-profile>	Nom de votre profil Azure Front Door.	zava-profile
   --origin-group-name	<front-door-origin-group>	Nom du groupe d’origines Azure Front Door.	zava-origin-group
   --origin-name	<web-app-origin-name>	Nom de l’origine de l’application web principale . Le nom doit être unique dans le groupe d’origines.	primary-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	L’en-tête d’hôte à transmettre dans les requêtes dirigées vers l’origine principale de l’application web. Si vous ne spécifiez pas de valeur, le nom d’hôte de la demande détermine cette valeur. Les origines Azure CDN, telles que les Web Apps, le Stockage Blob et les Cloud Services, nécessitent par défaut que cette valeur de l’en-tête d’hôte corresponde au nom d’hôte d’origine.	zava-primary-app.azurewebsites.net
   --priority	<origin-priority>	Priorité de cette origine dans le groupe d’origines. Pour l’application web principale , définissez la priorité sur 1. Azure Front Door utilise les valeurs de priorité pour l’équilibrage de charge entre les origines et les régions actives. La valeur doit être comprise entre 1 et 5.	1
   --weight	<origin-weight>	Poids de l’origine dans le groupe d’origines pour l’équilibrage de charge. La valeur doit être comprise entre 1 et 1 000.	1 000
   --enabled-state	<origin-state>	Indiquez s’il faut activer cette origine pour recevoir le trafic.	Enabled
   --http-port	<origin-port>	Port utilisé pour les requêtes HTTP vers l’origine.	80
   --https-port	<origin-secure-port>	Port utilisé pour les requêtes HTTPS sécurisées vers l’origine.	443

   Pour plus d’informations, consultez la référence de commande az afd origin create .

2. Réexécutez la commande et ajoutez une origine pour l’application web de secours . La commande utilise les mêmes paramètres, mais avec les valeurs de paramètre uniques suivantes :

   Paramètre	Valeur	Descriptif	Exemple
   --host-name	<web-app-name>.azurewebsites.net	Nom d’hôte de votre application web de secours .	zava-standby-app.azurewebsites.net
   --origin-name	<web-app-origin-name>	Le nom attribué à l’origine de l’application web de secours.	standby-origin
   --origin-host-header	<web-app-name>.azurewebsites.net	L’en-tête d’hôte à inclure dans les requêtes destinées à l’origine de l’application web de secours.	zava-standby-app.azurewebsites.net
   --priority	<origin-priority>	Priorité de cette origine dans le groupe d’origines. Pour l’application web de secours , définissez la priorité sur 2. Azure Front Door tente de diriger tout le trafic vers l’origine principale. Lorsque l’origine principale n’est pas disponible, le trafic est acheminé vers l’origine de secours.	2

Ajouter une règle de routage

Ajoutez une règle de routage pour mapper le point de terminaison Azure Front Door au groupe d’origine. L’itinéraire transfère les requêtes du point de terminaison à votre groupe d’origine.

1. Créez une règle de routage pour mapper le point de terminaison Azure Front Door au groupe d’origine :

   az afd route create --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> `
      --forwarding-protocol <protocol-type> --route-name <route-rule-name> --https-redirect <secure-redirect> `
      --origin-group <front-door-origin-group> --supported-protocols <protocol-list> --link-to-default-domain <domain-link> 
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --profile-name	<front-door-profile>	Nom de votre profil Azure Front Door.	zava-profile
   --endpoint-name	<front-door-endpoint>	Nom du point de terminaison sous votre profil Azure Front Door.	zava-endpoint
   --forwarding-protocol	<protocol-type>	Protocole utilisé par cette règle de routage lors du transfert du trafic vers les applications back-end.	MatchRequest
   --route-name	<route-rule-name>	Nom de la règle d’itinéraire. Doit être unique dans le profil Azure Front Door.	zava-route-rule
   --https-redirect	<secure-redirect>	Indique s’il faut rediriger automatiquement le trafic HTTP vers le trafic HTTPS.	Enabled
   --origin-group-name	<front-door-origin-group>	Nom du groupe d’origines Azure Front Door.	zava-origin-group
   --supported-protocols	<protocol-list>	Liste des protocoles pris en charge pour cette règle de routage. Utilisez un espace pour séparer les types de protocole.	Http Https
   --link-to-default-domain	<domain-link>	Indiquez si cet itinéraire est lié au domaine de point de terminaison par défaut.	Enabled

   Pour plus d’informations, consultez la référence de commande az afd route create .

2. Laissez environ 15 minutes pour que le déploiement se termine. Il peut prendre un certain temps pour que les modifications se propagent globalement.

Restreindre l’accès via Azure Front Door uniquement

Vous pouvez accéder directement à vos applications web en entrant leurs noms d’hôte dans un navigateur. Si vous définissez des restrictions d’accès sur vos applications, vous pouvez vous assurer que le trafic atteint vos applications uniquement via Azure Front Door.

Azure Front Door fonctionnalités fonctionnent mieux lorsque le trafic transite uniquement par le service. Il est recommandé de configurer vos origines d'application web pour bloquer le trafic qui n'est pas envoyé via Azure Front Door. Sinon, le trafic peut contourner le pare-feu d’applications web Azure Front Door, la protection DDoS et d’autres fonctionnalités de sécurité.

Le trafic de Azure Front Door vers vos applications provient d’un ensemble connu de plages d’adresses IP définies dans la balise de service AzureFrontDoor.Backend. En utilisant une règle de restriction d’étiquette de service, vous pouvez restreindre le trafic pour qu'il provienne uniquement d’Azure Front Door.

1. Obtenez l’identificateur de votre profil Azure Front Door.

   Vous avez besoin de l’ID de profil pour vous assurer que le trafic provient uniquement de votre instance de Azure Front Door spécifique. La restriction d’accès filtre davantage les requêtes entrantes en fonction de l’en-tête HTTP unique envoyé à partir de votre profil Azure Front Door.

   az afd profile show --resource-group <resource-group> --profile-name <front-door-profile> --query "frontDoorId"
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --profile-name	<front-door-profile>	Nom de votre profil Azure Front Door.	zava-profile

   La sortie de la commande affiche l’ID de profil (valeur alphanumérique à 32 chiffres) :

   "0000aaaa-1b1b-2c2c-3d3d-444444eeeeee"
   

   À l’étape suivante, vous utilisez l’ID de profil pour la valeur <profile-identifier>.

2. Exécutez la commande suivante pour définir des restrictions d’accès sur votre application web principale, puis réexécutez la commande pour définir des restrictions sur l’application de secours.

   az webapp config access-restriction add --resource-group <resource-group> --name <web-app-name> `
      --priority <access-priority> --service-tag <tag-name> --http-header x-azure-fdid=<front-door-id>
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --name	<web-app-name>	Nom de l’application web pour laquelle vous définissez des restrictions d’accès.	zava-primary-app zava-standby-app
   --priority	<access-priority>	Spécifiez la priorité de la règle de restriction d’accès sur toutes les règles définies pour le profil. Une valeur inférieure équivaut à une priorité plus élevée.	100
   --service-tag	<tag-name>	Nom d’étiquette de service reconnu par Azure Front Door. Les restrictions d’accès s’appliquent à la plage d’adresses IP indiquée par la balise de service.	AzureFrontDoor.Backend
   --http-header	x-azure-fdid=<profile-identifier>	Spécifiez un ou plusieurs en-têtes HTTP uniques pour un filtrage supplémentaire du trafic entrant. Les restrictions d’accès filtrent les requêtes entrantes en fonction de l’en-tête HTTP unique envoyé à partir de votre profil Azure Front Door. L’en-tête combine le préfixe Azure Front Door et l’identificateur de profil de votre instance de Azure Front Door.	x-azure-fdid=0000aaaa-1b1b-2c2c-3d3d-444444eeeeee

   Pour davantage de détails, reportez-vous à la documentation de la commande « az webapp config access-restriction add ».

Tester les restrictions d’accès

Vérifiez que vos restrictions d’accès empêchent l’accès direct à vos applications.

1. Dans un navigateur, entrez le nom d’hôte de l’application web principale, tel que zava-primary-app.azurewebsites.net.

   La connexion doit échouer avec le message suivant :

   

2. Répétez le test avec le nom d’hôte de votre application web de secours, tel que zava-standby-app.azurewebsites.net.

Tester le déploiement de Azure Front Door

Lorsque vous créez le profil Azure Front Door Standard ou Premium, la configuration peut prendre un certain temps pour le déploiement global. Une fois le déploiement terminé, vous pouvez accéder à l’hôte frontal.

1. Obtenez le nom d’hôte de votre point de terminaison Azure Front Door :

   az afd endpoint show --resource-group <resource-group> --profile-name <front-door-profile> --endpoint-name <front-door-endpoint> --query "hostName"
   

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

   Paramètre	Valeur	Descriptif	Exemple
   --resource-group	<resource-group>	Groupe de ressources qui contient les ressources créées dans ce didacticiel.	zava-resource-group
   --profile-name	<front-door-profile>	Nom de votre profil Azure Front Door.	zava-profile
   --endpoint-name	<front-door-endpoint>	Nom du point de terminaison sous votre profil Azure Front Door.	zava-endpoint

   La sortie de commande affiche le nom d’hôte du point de terminaison :

   "zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net"
   

   Le nom d’hôte se compose du nom de point de terminaison, d’un hachage alphanumérique unique, d’un identificateur et du suffixe Azure Front Door. À l’étape suivante, vous utilisez le nom d’hôte du point de terminaison.

   Pour plus d’informations, consultez la référence de commande az afd endpoint show .

2. Dans un navigateur, entrez le nom d’hôte du point de terminaison, comme zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net, par exemple.

   Votre demande doit être automatiquement acheminée vers votre application principale dans la région active.

   Une fois la connexion établie, le message suivant s’affiche :

   

3. Testez le basculement global instantané entre les applications dans les régions jumelées.

   1. Dans un navigateur, entrez le nom d’hôte du point de terminaison, comme zava-endpoint-0a1b2c3d4e5f6g78.z00.azurefd.net, par exemple.

   2. Arrêtez l’application principale en exécutant la commande az webapp stop .

      Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

      az webapp stop --name <primary-web-app> --resource-group <resource-group>
      

   3. Actualisez votre navigateur.

      Si le trafic redirige correctement vers l’application de secours dans l’autre région, vous devez voir la même page et le même message.

      Conseil

      Vous devrez peut-être actualiser la page quelques fois pour que le basculement s’effectue.

      Vous pouvez confirmer que Azure Front Door redirige vers l’application de secours en vérifiant l’état des applications web dans le portail Azure. Dans la page Vue d’ensemble de l’application web principale, l’option Démarrer doit être disponible (pas grisée). Dans la page Vue d’ensemble de l’application web de secours, l’option Démarrer ne doit pas être disponible (grisée).

   4. Réexécutez la az webapp stop commande et arrêtez votre application de secours .

      Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

      az webapp stop --name <standby-web-app> --resource-group <resource-group>
      

   5. Actualisez à nouveau votre navigateur.

      Si l’application de secours devient indisponible, l’ensemble du routage du trafic doit être interrompu. Cette fois, un message d’erreur doit s’afficher :

      

   6. Exécutez la az webapp start commande et redémarrez votre application de secours .

      Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources :

      az webapp start --name <standby-web-app> --resource-group <resource-group>
      

   7. Actualisez votre navigateur et vous devriez voir une connexion d’application réussie.

La validation confirme que vous pouvez désormais accéder à vos applications via Azure Front Door, et que le basculement fonctionne comme prévu.

Si vous avez terminé le test de basculement, redémarrez votre application principale .

Nettoyer les ressources

Dans les étapes précédentes, vous avez créé Azure ressources dans un groupe de ressources. Si vous ne vous attendez pas à avoir besoin de ces ressources à l'avenir, supprimez le groupe de ressources en exécutant la commande suivante dans le Cloud Shell.

Remplacez la valeur du <placeholder> paramètre par les informations de votre propre ressource :

az group delete --name <resource-group>

Cette commande peut prendre quelques minutes pour s’exécuter.

Déployer à partir d’ARM ou de Bicep

Les ressources que vous avez créées dans ce didacticiel peuvent être déployées à l’aide d’un modèle Azure Resource Manager (modèle ARM) ou d’un modèle Bicep. Vous pouvez vous appuyer sur le fichier Bicep d’application web multirégionale hautement disponible disponible sur GitHub. Ce modèle vous permet de créer une solution de bout en bout sécurisée, hautement disponible et multirégion avec deux applications web dans différentes régions derrière Azure Front Door.

Pour savoir comment déployer des modèles ARM et Bicep, consultez Déployer des fichiers Bicep avec le Azure CLI.

Forum aux questions

Dans ce tutoriel, vous avez déployé une infrastructure de base pour activer une application web multirégion. App Service fournit des fonctionnalités qui peuvent vous aider à vous assurer que vous exécutez des applications qui suivent les meilleures pratiques et recommandations de sécurité.

Cette section contient des réponses aux questions fréquemment posées qui peuvent vous aider à sécuriser davantage vos applications et à déployer et gérer vos ressources en fonction des meilleures pratiques.

Gérer et déployer des ressources d’infrastructure et de Azure

Pour ce tutoriel, vous avez utilisé le Azure CLI pour déployer vos ressources d’infrastructure. Vous pouvez configurer un mécanisme de déploiement continu pour gérer votre infrastructure d’application. Étant donné que vous déployez des ressources dans différentes régions, vous devez gérer ces ressources indépendamment dans les régions. Pour garantir que les ressources sont identiques dans chaque région, infrastructure as code (IaC) telle qu’un modèle ARM ou Terraform doit être utilisé avec des pipelines de déploiement tels que Azure Pipelines ou GitHub Actions. Lorsque vous configurez cette configuration de manière appropriée, toute modification apportée aux ressources déclenche des mises à jour dans toutes les régions de déploiement. Pour plus d’informations, consultez Configurer le déploiement continu vers Azure App Service.

Utiliser des emplacements intermédiaires pour un déploiement sécurisé en production

Le déploiement direct du code applicatif vers les applications et les emplacements de production est déconseillé. Il est important d’avoir un endroit sûr pour tester vos applications et valider les modifications avant d’envoyer (push) à la production. Utilisez une combinaison d’emplacements intermédiaires et d’échange d’emplacements pour déplacer le code de l’environnement de test vers la production.

Dans ce tutoriel, vous avez créé l'infrastructure de référence qui prend en charge l'utilisation des slots de mise en scène. Vous pouvez créer des emplacements de déploiement pour chaque instance de votre application web et configurer le déploiement continu sur ces emplacements intermédiaires avec GitHub Actions. Comme pour la gestion de l’infrastructure, la configuration du déploiement continu pour le code source de votre application est également recommandée pour vous assurer que les modifications entre les régions restent synchronisées. Si vous ne configurez pas le déploiement continu, vous devez mettre à jour manuellement chaque application dans chaque région chaque fois qu’il existe une modification du code.

Pour utiliser des emplacements de mise en scène, procédez comme suit :

1. Pour cette procédure, vous avez besoin d’une application prête à être déployée sur votre application App Service.

   Si vous avez terminé le tutoriel, vous pouvez utiliser votre application web principale et votre application web de secours. Toutefois, vous avez besoin d’un plan App Service qui prend en charge des emplacements de déploiement suffisants. Pour plus d’informations, consultez Azure les limites d’abonnement et de service, les quotas et les contraintes.

   Si vous n'avez pas d'application, vous pouvez commencer par l'exemple d'application Node.js Hello World. Scindez le dépôt GitHub afin d'avoir votre propre copie pour apporter des modifications.

2. Configurez les paramètres de la stack App Service pour vos applications web.

   Les paramètres de stack font référence à la version de langue ou au runtime utilisé pour votre application.

   Vous pouvez configurer les paramètres dans le portail Azure ou utiliser la commande az webapp config set. Si vous utilisez l’exemple Node.js, définissez les paramètres de la pile sur Node 24 LTS.

   1. Dans le portail Azure, accédez à votre application web primary.

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

   3. Sous l’onglet Paramètres de la pile , configurez les paramètres suivants :

      1. Sélectionnez la valeur de la pile , telle que Node.

      2. Sélectionnez la valeur version , telle que Node 24 LTS.

      3. Sélectionnez Appliquer.

   4. Répétez la procédure afin de configurer les paramètres de la pile App Service pour l’application web de secours.

3. Configurez le déploiement continu dans le portail Azure. Pour obtenir des instructions détaillées sur la configuration du déploiement continu avec des fournisseurs tels que GitHub Actions, consultez Configurer le déploiement continu sur Azure App Service.

4. Exécutez la commande suivante pour créer un emplacement intermédiaire nommé stage pour votre application web principale .

   az webapp deployment slot create --resource-group <resource-group> --name <web-app-name> --slot stage --configuration-source <web-app-name>
   

5. Réexécutez la az webapp deployment slot create commande et créez un emplacement intermédiaire nommé stage pour l’application web de secours .

6. Configurez le déploiement continu avec GitHub Actions pour chaque emplacement intermédiaire :

   1. Dans le portail Azure, accédez à votre application web primary.

   2. Dans le menu de gauche, sélectionnez déploiement>Emplacements de déploiement.

   3. Repérez l’emplacement de préproduction dans la liste, puis sélectionnez-le afin d’afficher son panneau de détails.

   4. Dans le menu de gauche, sélectionnez Déploiement>Centre de déploiement.

   5. Sous l’onglet Settings, définissez l’option Source sur GitHub :

      

   6. Si vous effectuez le déploiement à partir de GitHub pour la première fois, sélectionnez Authorize et suivez les invites d'autorisation. Si vous souhaitez effectuer un déploiement à partir d’un autre dépôt d’utilisateur, sélectionnez Changer de compte.

   7. Après avoir autorisé votre compte Azure avec GitHub, sélectionnez le Organization, Repository et Branch pour configurer CI/CD. Si vous ne trouvez pas d’organisation ou de référentiel, vous devrez peut-être activer davantage d’autorisations sur GitHub. Pour plus d’informations, consultez Gérer l’accès utilisateur aux dépôts de votre organisation.

      Si vous utilisez l’exemple d’application Node.js, utilisez les paramètres suivants.

      Paramètre	Valeur
      Organisation	<your-GitHub-organization>
      Référentiel	nodejs-docs-hello-world
      Branche	main

   8. Sélectionnez Enregistrer.

Les nouveaux commits dans le dépôt et la branche sélectionnés se déploient désormais en continu sur votre emplacement d’application App Service. Vous pouvez suivre les validations et les déploiements sous l’onglet Journaux.

Un fichier de flux de travail par défaut qui utilise un profil de publication pour s’authentifier auprès d’App Service est ajouté à votre dépôt GitHub. Vous pouvez voir ce fichier en accédant au répertoire <repo-name>/.github/workflows/.

Désactiver l’authentification de base sur App Service

Vous pouvez limiter l'accès aux points de terminaison FTP et SCM aux utilisateurs gérés par Microsoft Entra ID en désactivant l'authentification de base.

Si vous utilisez un outil de déploiement continu pour déployer le code source de votre application, la désactivation de l’authentification de base nécessite des étapes supplémentaires pour configurer le déploiement continu. Par exemple, vous ne pouvez pas utiliser un profil de publication, car il n'utilise pas les informations d'identification Microsoft Entra. Il convient d’utiliser soit un principal de service, soit des identifiants OpenID Connect.

Les commandes suivantes désactivent l'authentification de base pour l'application web principale d'App Service et le slot de mise en scène, ainsi que pour l'application web de secours et le slot de mise en scène. Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources.

1. Désactivez l’accès FTP pour les sites de production et les emplacements intermédiaires pour votre application web principale :

   az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<web-app-name> --set properties.allow=false
   
   az resource update --resource-group <resource-group> --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<web-app-name>/slots/stage --set properties.allow=false
   

2. Réexécutez les commandes pour votre application web de secours .

3. Désactivez l’accès d’authentification de base au port WebDeploy et au site SCM pour les sites de production et les emplacements intermédiaires pour votre application web principale :

   az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<primary-web-app> --set properties.allow=false
   
   az resource update --resource-group <resource-group> --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies \
      --parent sites/<primary-web-app>/slots/stage --set properties.allow=false
   

4. Réexécutez les commandes pour votre application web de secours .

Pour plus d’informations sur la désactivation de l’authentification de base, notamment sur la façon de tester et de surveiller les connexions, consultez Désactiver l’authentification de base dans les déploiements App Service.

Utiliser le déploiement continu lorsque l’authentification de base est désactivée

Si vous choisissez d’autoriser l’authentification de base sur vos applications App Service, vous pouvez utiliser l’une des méthodes de déploiement disponibles sur App Service. Par exemple, vous pouvez utiliser le profil de publication que vous avez configuré dans la section emplacements de mise en scène .

Si vous désactivez l’authentification de base pour vos applications App Service, le déploiement continu nécessite un principal de service ou OpenID Connect pour l’authentification. Si vous utilisez GitHub Actions comme référentiel de code, consultez la Deploy to Azure App Service à l’aide de GitHub Actions. Le tutoriel fournit des instructions pas à pas pour créer un principal de service ou OpenID Connect à déployer sur App Service à l’aide de GitHub Actions. Vous pouvez également terminer le processus en suivant la procédure décrite dans la section suivante.

Créer un principal de service et des informations d’identification avec GitHub Actions

Configurez le déploiement continu avec GitHub Actions et un principal de service :

1. Créez un principal de service pour l’application web principale ainsi que pour l’application web de secours :

   Remplacez les valeurs de paramètre suivantes <placeholder> par les informations de vos propres ressources.

   az ad sp create-for-rbac --name <service-principal-name> --role contributor --scopes \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<primary-web-app> \
      /subscriptions/<subscription-ID>/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<standby-web-app>
   

   La sortie est un objet JSON avec les informations d’identification de l’attribution de rôle qui fournit l’accès à vos applications App Service.

   {
     "clientId": "00001111-aaaa-2222-bbbb-3333cccc4444",
     "clientSecret": "ffffffff-5a5a-6b6b-7c7c-888888888888",
     "subscriptionId": "cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a",
     "tenantId": "aaaabbbb-6666-cccc-7777-dddd8888eeee",
     "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
     "resourceManagerEndpointUrl": "https://management.azure.com/",
     "activeDirectoryGraphResourceId": "https://graph.windows.net/",
     "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
     "galleryEndpointUrl": "https://gallery.azure.com/",
     "managementEndpointUrl": "https://management.core.windows.net/"
   }
   

   Le code JSON inclut votre clé secrète client, qui n’est visible qu’à ce stade.

   Conseil

   Il est recommandé d’accorder un accès minimal. Dans cet exemple, l’étendue est limitée aux applications, et non à l’ensemble du groupe de ressources.

2. Copiez l’objet JSON afin d’avoir un enregistrement de votre secret client.

3. Transmettez les identifiants de votre principal de service à l’opération de connexion Azure dans votre workflow GitHub Action.

   Vous pouvez fournir les valeurs directement dans le flux de travail ou les stocker en tant que secrets GitHub référencés dans votre flux de travail. L’enregistrement des valeurs en tant que secrets GitHub est l’option la plus sécurisée.

   1. Ouvrez le référentiel GitHub pour votre application.

   2. Accédez aux Paramètres>Sécurité>Secrets et variables>Actions.

   3. Sélectionnez Nouveau secret de référentiel et créez un secret pour chacun des paramètres suivants. Utilisez les valeurs de votre sortie JSON.

      Paramètre	Valeur	Exemple
      AZURE_APP_ID	<application/client-id>	00001111-aaaa-2222-bbbb-3333cccc4444
      AZURE_PASSWORD	<client-secret>	ffffffff-5a5a-6b6b-7c7c-888888888888
      AZURE_TENANT_ID	<tenant-id>	aaaabbbb-6666-cccc-7777-dddd8888eeee
      AZURE_SUBSCRIPTION_ID	<subscription-id>	cccc2c2c-dd3d-ee4e-ff5f-aaaaaa6a6a6a

Créer un flux de travail GitHub Actions

Une fois que vous avez un principal de service qui peut accéder à vos applications App Service, modifiez les flux de travail par défaut pour vos applications. Ces flux de travail sont générés automatiquement lorsque vous configurez le déploiement continu.

L’authentification doit être réalisée via le principal de service plutôt qu’au moyen du profil de publication. Pour obtenir des exemples de flux de travail, consultez l’onglet Principal du service dans Ajoutez le fichier de flux de travail dans votre référentiel GitHub. L’exemple de flux de travail suivant peut être utilisé pour l’exemple d’applicationNode.js.

1. Ouvrez le référentiel GitHub pour votre application.

2. Accédez au répertoire <repo-name>/.github/workflows/. Vous devriez voir les workflows générés automatiquement.

3. Pour chaque fichier de flux de travail, sélectionnez Modifier (crayon).

4. Remplacez le contenu du fichier de flux de travail par le contenu suivant. Le code part du principe que vous avez déjà créé les secrets GitHub pour vos informations d’identification.

   Dans la env section, configurez les paramètres suivants :

   • AZURE_WEBAPP_NAME: remplacez l’espace <web-app-name> réservé par le nom de votre application web.
   • NODE_VERSION: spécifiez la version du nœud à utiliser. Pour l’exemple Node.js, la valeur est '24.x'.
   • AZURE_WEBAPP_PACKAGE_PATH: spécifiez le chemin d’accès à votre projet d’application web. La valeur par défaut est la racine du référentiel. '.'
   • AZURE_WEBAPP_SLOT_NAME : Indiquez le nom de votre emplacement d’application. Le nom commun est stage.

   
    name: Build and deploy Node.js app to Azure Web App
   
    on:
      push:
        branches:
          - main
      workflow_dispatch:
   
    env:
      AZURE_WEBAPP_NAME: <web-app-name>   # Your application name
      NODE_VERSION: '24.x'                # Node version to use
      AZURE_WEBAPP_PACKAGE_PATH: '.'      # Path to your web app project
      AZURE_WEBAPP_SLOT_NAME: stage       # Application slot name
   
    jobs:
      build:
        runs-on: ubuntu-latest
   
        steps:
          - uses: actions/checkout@v4
   
          - name: Set up Node.js version
            uses: actions/setup-node@v4
            with:
              node-version: ${{ env.NODE_VERSION }}
   
          - name: npm install, build
            run: |
              npm install
              npm run build --if-present
   
          - name: Upload artifact for deployment job
            uses: actions/upload-artifact@v4
            with:
              name: node-app
              path: .
   
      deploy:
        runs-on: ubuntu-latest
        needs: build
        environment:
          name: 'stage'
          url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
   
        steps:
          - name: Download artifact from build job
            uses: actions/download-artifact@v4
            with:
              name: node-app
   
          - uses: azure/login@v2
            with:
              creds: |
                {
                  "clientId": "${{ secrets.AZURE_APP_ID }}",
                  "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
                  "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
                  "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
                }
   
          - name: 'Deploy to Azure Web App'
            id: deploy-to-webapp
            uses: azure/webapps-deploy@v3
            with:
              app-name: ${{ env.AZURE_WEBAPP_NAME }}
              slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
              package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
   
          - name: logout
            run: |
              az logout
   

5. Enregistrez et validez les modifications apportées directement au fichier de flux de travail dans la branche principale de votre référentiel.

   La validation déclenche l’action de GitHub pour qu’elle s’exécute à nouveau et déploie votre code. Cette fois, le principal de service est utilisé pour s’authentifier.

Tester les mises à jour de l’application en utilisant le routage du trafic par slot

Le routage du trafic avec des emplacements vous permet de diriger une partie prédéfinie de votre trafic utilisateur vers chaque emplacement. Initialement, 100 % du trafic est dirigé vers le site de production. Il est toutefois possible d’acheminer 10 % du trafic vers l’emplacement de préproduction. Cette méthode de routage redirige automatiquement 10 % des utilisateurs tentant d’accéder à l’emplacement de préproduction. L’approche ne nécessite aucune modification de votre instance de Azure Front Door. Pour en savoir plus sur les échanges d’emplacements et les environnements intermédiaires dans App Service, consultez Configurer des environnements intermédiaires dans Azure App Service.

Déplacer le code du slot de staging vers le slot de production

Une fois que vous avez terminé le test et la validation dans vos emplacements intermédiaires, vous pouvez effectuer un échange d’emplacement de votre emplacement intermédiaire vers votre site de production. Vous terminez l’échange pour toutes les instances de votre application dans chaque région. Pendant un échange d’emplacement, la plateforme App Service garantit que l’emplacement cible ne subit pas de temps d’arrêt.

1. Effectuez l’échange pour votre application web principale :

   az webapp deployment slot swap --resource-group <resource-group> -name <primary-web-app-name> --slot stage --target-slot production
   

2. Procédez au remplacement de votre application web d'attente :

   az webapp deployment slot swap --resource-group <resource-group> -name <standby-web-app-name> --slot stage --target-slot production
   

3. Après quelques minutes, accédez à votre point de terminaison Azure Front Door dans le portail Azure, puis validez que l’échange d’emplacement a réussi.

À ce stade, vos applications sont opérationnelles et toutes les modifications apportées au code source de votre application déclenchent automatiquement une mise à jour vers les deux emplacements intermédiaires. Vous pouvez ensuite répéter le processus d’échange d’emplacement quand vous êtes prêt à déplacer ce code en production.

Éviter les interruptions et les problèmes de continuité à l’aide de déploiements multirégions

Vous pouvez éviter des interruptions potentielles ou des problèmes de continuité entre les régions en supprimant temporairement un site qui subit l'échange d'emplacement de votre groupe d'origine Azure Front Door. Cette action permet d’empêcher les clients de voir différentes versions de votre application en même temps. Il est également utile lorsque vous apportez des modifications significatives à vos applications. La suppression temporaire entraîne la redirection de tout le trafic vers l’autre origine.

1. Dans le portail Azure, accédez à votre instance Azure Front Door.

2. Dans le menu de gauche, sélectionnez Paramètres>Groupes d'origine.

3. Dans la liste des groupes d’origines, sélectionnez le groupe d’origines qui contient l’emplacement que vous souhaitez supprimer temporairement.

4. Dans le volet Mettre à jour le groupe d’origines , recherchez l’emplacement à supprimer dans la liste des noms d’hôte d’origine .

5. Sélectionner plus d’actions (...) >Supprimez, puis sélectionnez Mettre à jour.

   

   L’application de la modification peut prendre plusieurs minutes.

6. Lorsque vous êtes prêt à autoriser le trafic vers l'emplacement supprimé, revenez au volet Mettre à jour le groupe d'origine .

7. En haut, sélectionnez + Ajouter une origine pour réintégrer l’emplacement d’origine dans le groupe d’origines.

   

Créer des groupes d’origines supplémentaires et modifier des associations de routage

Si vous préférez ne pas supprimer et lire les origines, vous pouvez créer des groupes d'origines supplémentaires pour votre instance de Azure Front Door. Vous pouvez ensuite associer l’itinéraire au groupe d’origine qui pointe vers l’origine prévue.

Par exemple, vous pouvez créer deux groupes d’origine supplémentaires, un pour votre région principale (active) et un pour votre région de secours (passif). Si votre région primaire subit une modification, associez l’itinéraire à votre région de secours. Si votre région de secours subit une modification, associez l’itinéraire à votre région primaire. Une fois tous les changements effectués, vous pouvez associer la route à votre groupe d’origines initial qui contient les deux régions. Cette méthode fonctionne parce qu’une route peut être associée à un seul groupe d’origines à la fois.

Considérez une configuration avec trois groupes d’origines :

• Le groupe Main-Origin regroupe à la fois les applications web principale et de secours, chacune déployée dans sa région respective.
• Le Primary-Origin groupe contient uniquement l’application web principale dans la région active.
• Le Standby-Origin groupe contient uniquement l’application web de secours dans la région passive.

Supposons que l’application web principale subit une modification. Avant le début des modifications, l’association d’itinéraires du Main-Origin groupe est remplacée par le Secondary-Origin groupe. Cette action garantit que tout le trafic est redirigé vers l’application web de secours dans sa région respective, tandis que l’application web principale de sa région respective subit une mise à jour.

Procédez comme suit pour modifier l’association de routage pour un groupe d’origine :

1. Dans le portail Azure, accédez à votre instance Azure Front Door.

2. Dans le menu de gauche, sélectionnez Paramètres>Groupes d'origine.

3. Dans la liste des groupes d’origines, recherchez un groupe d’origines qui affiche l’indicateur non associé dans la colonne Routes .

4. Sélectionner plus d’actions (...) >Associer le point de terminaison et l’itinéraire.

   

5. Dans le volet Associer des itinéraires , sélectionnez un ou plusieurs itinéraires à associer au groupe d’origine, puis sélectionnez Associer.

   

Restreindre l’accès au site d’outils avancés

Avec Azure App service, le site des outils SCM/avancés est utilisé pour gérer vos applications et déployer le code source de l’application. Vous pouvez verrouiller le site SCM/des outils avancés, car il n’a probablement pas besoin d’être accessible par le biais de Front Door. Par exemple, vous pouvez configurer des restrictions d’accès qui vous permettent uniquement d’effectuer vos tests et d’activer le déploiement continu avec l’outil de votre choix. Si vous utilisez des emplacements de déploiement, pour les emplacements de production en particulier, vous pouvez refuser presque tout accès au site SCM, car vos tests et votre validation sont effectués avec vos emplacements de préproduction.

Contenu connexe

• Déployer une application web multirégion hautement disponible
• Examiner l'architecture de base d'une application Web hautement disponible avec redondance interzone