Partage via

Déplacer Azure App Services vers une autre région

  • Article

Cet article décrit comment déplacer vos ressources App Service vers une autre région Azure.

Il existe différentes raisons pour lesquelles vous pouvez avoir besoin de déplacer vos ressources Azure existantes d’une région à une autre. Vous pouvez :

  • Tirer parti d’une nouvelle région Azure.
  • Déployer des fonctionnalités ou des services disponibles uniquement dans des régions spécifiques.
  • Respecter les exigences de gouvernance et de stratégie internes.
  • Être en phase avec les fusions et acquisitions de l’entreprise
  • Répondre à la planification de la capacité requise.

Les ressources App Service sont spécifiques à une région et ne peuvent pas être déplacées d’une région à l’autre. Vous devez créer une copie de vos ressources App Service existantes dans la région cible, puis déplacer votre contenu vers la nouvelle application. Si votre application source utilise un domaine personnalisé, vous pouvez le migrer vers la nouvelle application dans la région cible une fois la relocalisation terminée.

Pour faciliter la copie de votre application, vous pouvez sauvegarder et restaurer une application App Service individuelle dans un plan App Service dans une autre région.

Prérequis

  • Vérifiez que l’application App Service se trouve dans la région Azure à partir de laquelle vous souhaitez effectuer le déplacement.
  • Assurez-vous que la région cible prend en charge App Service et tout service associé dont vous souhaitez déplacer les ressources.
  • Validez que des autorisations suffisantes existent pour déployer des ressources App Service dans l'abonnement et la région cibles.
  • Validez si une politique Azure est affectée d'une restriction régionale.
  • Tenez compte des coûts d'exploitation, car les prix des ressources informatiques peuvent varier d'une région à l'autre. Pour estimer vos coûts éventuels, utilisez Calculatrice de prix.

Préparer

Identifiez toutes les ressources App Service que vous utilisez actuellement. Par exemple :

Certaines ressources, telles que les certificats importés ou les connexions hybrides, contiennent une intégration avec d’autres services Azure. Pour plus d’informations sur la façon de déplacer ces ressources d’une région à l’autre, consultez la documentation des services respectifs.

Plan

Cette section est une liste de contrôle pour la planification dans les domaines suivants :

  • État, stockage et dépendances en aval
  • Certificats
  • Configuration
  • Connectivité VNet / Noms personnalisés / DNS
  • Identités
  • Points de terminaison de service

État, stockage et dépendances en aval

  • Déterminez si votre application App Service est avec ou sans état. Bien que nous vous recommandons d’utiliser App Service Apps sans état et que les fichiers sur le lecteur %HOME%\site doivent être uniquement ceux requis pour exécuter l’application déployée avec des fichiers temporaires, il est toujours possible de stocker l’état de l’application runtime sur le lecteur virtuel %HOME%\site. Si votre application écrit un état sur le chemin de stockage partagé de l'application, veillez à planifier la gestion de cet état lors d'un déplacement de ressources.

    Conseil

    Vous pouvez utiliser Kudu pour fournir une API d’accès aux fichiers (Virtual File System (VFS)) qui peut lire ou écrire des fichiers sous le répertoire %HOME%\site. Pour plus d’informations, consultez Wiki Kudu.

  • Recherchez la mise en cache interne et l’état dans le code de l’application.

  • Désactiver le paramètre d’affinité de session. Dans la mesure du possible, nous vous recommandons de désactiver le paramètre d'affinité de session. La désactivation de l'affinité de session améliore l'équilibrage de la charge dans le cadre d'un scale-out horizontal. Tout état interne peut avoir un impact sur la planification de la réduction d'une charge de travail ; en particulier si un temps d'arrêt nul est exigé. Dans la mesure du possible, il peut être utile de remanier l'état de l'application pour la rendre apatride en prévision du transfert.

  • Analyser les chaînes de connexions aux bases de données. Les chaînes de connexions aux bases de données se trouvent dans les paramètres de l'application. Toutefois, ils peuvent également être codés en dur ou gérés dans des fichiers de configuration livrés avec l'application. Analyser et planifier la migration ou la réplication des données dans le cadre de la planification de haut niveau du déplacement de la charge de travail. Pour les applications bavardes ou critiques en termes de latence, il n'est pas performant pour l'application dans la région cible d'accéder aux sources de données dans la région source.

  • Analyser la mise en cache externe (par exemple Redis). Les caches d'application doivent être déployés aussi près que possible de l'application. Analyser la manière dont les caches sont remplis, les politiques d'expiration ou d’éviction et l'impact éventuel d'un cache froid sur les premiers utilisateurs à accéder à la charge de travail après le basculement.

  • Analyser et planifier les dépendances d’API (ou d’application) La communication entre régions est nettement moins performante si l’application de la région cible revient aux dépendances qui se trouvent toujours dans la région source. Nous vous recommandons de relocaliser toutes les dépendances en aval dans le cadre de la relocalisation de la charge de travail. Cependant, les ressources *sur site* sont l'exception, en particulier celles qui sont géographiquement plus proches de la région cible (comme cela peut être le cas pour les scénarios de rapatriement).

    Azure Container Registry peut être une dépendance en aval (exécution) pour App Service qui est configuré pour fonctionner avec des images de conteneurs personnalisés. Il est plus logique que Azure Container Registry se trouve dans la même région que l'application elle-même. Envisagez de télécharger les images requises vers un nouvel ACR dans la région d’obtention cible. Sinon, envisagez d’utiliser la fonctionnalité de géo-réplication si vous envisagez de conserver les images dans la région source.

  • Analyser et planifier les services régionaux. Les données relatives à l'analyse des applications et des journaux sont des services régionaux. Envisagez la création de nouveaux espaces de stockage Application Insights et Log Analytics dans la région cible. Pour App Insights, une nouvelle ressource a également un impact sur la chaîne de connexion qui doit être mise à jour dans le cadre de la modification dans Azure App Configuration.

Certificats

Les ressources App Service Certificate peuvent être déplacées vers un nouveau groupe de ressources ou un nouvel abonnement, mais pas entre différentes régions. Les certificats exportables peuvent également être importés dans l’application ou dans Key Vault dans la nouvelle région. Ce processus d’exportation et d’importation équivaut à un déplacement entre les régions.

Il existe différents types de certificats qui doivent être pris en considération lorsque vous planifiez le déplacement de votre service :

Type de certificat Exportable Commentaires
Géré par App Service Non Recréez ces certificats dans la nouvelle région.
Géré par Azure Key Vault Oui Ces certificats peuvent être exportés à partir de Key Vault, puis importés dans Key Vault dans la nouvelle région.
Clé privée (auto-gérée) Oui Les certificats que vous avez acquis en dehors d’Azure peuvent être exportés à partir d’App Service, puis importés dans la nouvelle application ou dans Key Vault dans la nouvelle région.
Clé publique Non Votre application peut avoir des certificats avec uniquement une clé publique et aucun secret, qui sont utilisés pour accéder à d’autres points de terminaison sécurisés. Obtenez les fichiers de certificat de clé publique requis et importez-les dans l’application dans la nouvelle région.

Quelques éléments supplémentaires à prendre en considération :

  • Les adresses assignées aux applications, où la connexion SSL d'une application App Service est liée à une IP spécifique désignée par l'application, peuvent être utilisées pour autoriser la mise sur liste d'appels de réseaux tiers dans App Service. Par exemple, un administrateur de réseau ou informatique peut vouloir verrouiller les appels sortants d'un réseau sur site ou d'un réseau virtuel pour qu'ils utilisent une adresse statique bien connue. Ainsi, si la fonction App Assigned Address est utilisée, les règles de pare-feu en amont (internes, externes ou tierces parties) pour les appelants de l'application doivent être vérifiées et informées de la nouvelle adresse. Les règles de pare-feu peuvent être internes, externes ou de tiers, tels que des partenaires ou des clients connus.

  • Considérez n'importe quel Network Virtual Appliance (NVA) ou Reverse Proxy en amont. La configuration de la NVA devra peut-être être modifiée si vous réécrivez l'en-tête de l'hôte ou si SSL se termine.

Remarque

App Service Environment est la seule offre App Service qui autorise les appels en aval aux dépendances d’application en aval sur SSL, où le protocole SSL s’appuie sur l’infrastructure auto-signée/PKI avec des certificats d’autorité de certification racine non standard. Le service multi-tenant ne permet pas aux clients de télécharger vers le magasin de certificats de confiance.

Aujourd'hui, App Service Environment ne permet pas d'acheter des certificats SSL, mais seulement d'apporter ses propres certificats. IP-SSL n'est pas possible (et n'a pas de sens), mais SNI l'est. Azure App Service Environment interne n'est pas associé à un domaine public et les certificats SSL utilisés doivent donc être fournis par le client et sont donc transportables, par exemple des certificats à usage interne générés à l'aide d'une infrastructure à clé publique (PKI). App Service Environment v3 en mode externe partage les mêmes caractéristiques que App Service multi-tenant normal.

Configuration

  • Vous pouvez capturer un instantané des paramètres d’application existants et des chaînes de connexion à partir du Portail Azure. Développez Paramètres>Variables d’environnement, sélectionnez Modification avancée sous Paramètres de l’application ou Chaînes de connexion et enregistrez la sortie JSON contenant les paramètres ou connexions existants. Vous devez recréer ces paramètres dans la nouvelle région, mais les valeurs elles-mêmes sont susceptibles de changer en raison des modifications de région suivantes dans les services connectés.

  • Les références Key Vault existantes ne peuvent pas être exportées au-delà d’une limite géographique Azure. Vous devez recréer toutes les références requises dans la nouvelle région.

  • Votre configuration d’application peut être gérée par Azure App Configuration ou à partir d’une autre dépendance de base de données centrale (en aval). Passez en revue les magasins App Configuration ou les magasins similaires pour les paramètres spécifiques à l’environnement et à la région susceptibles de nécessiter des modifications.

  • Veillez à vérifier toute configuration de fichier de disque, qui peut ou non être remplacée par les paramètres de l’application.

Connectivité VNet / Noms personnalisés / DNS

  • Azure App Service Environment est un service à locataire unique injecté par le réseau VNet. La mise en réseau de App Service Environment diffère de App Service multi-tenant, qui nécessite un ou plusieurs « points de terminaison privés » ou « intégration au réseau virtuel régionale ». D'autres options peuvent être envisagées, notamment l'intégration VNet basée sur le VPN P2S et Hybrid Connections (un service Azure Relay).

    Remarque

    La mise en réseau ASEv3 est simplifiée ; le trafic de gestion Azure et les dépendances en aval des environnements de services applicatifs ne sont pas visibles par le réseau virtuel du client, ce qui simplifie grandement la configuration requise lorsque le client utilise un tunnel forcé pour l'ensemble du trafic, ou envoie un sous-ensemble du trafic sortant, par le biais d'un appareil virtuel de réseau ou de pare-feu.

    Les connexions hybrides (Azure Relay) sont régionales. Si des connexions hybrides sont utilisées et bien qu'un espace de noms Azure Relay puisse être déplacé vers une autre région, il serait plus simple de redéployer la connexion hybride (s'assurer que la connexion hybride est configurée dans la nouvelle région lors du déploiement des ressources cibles) et de la relier à nouveau au gestionnaire de connexions hybrides. L'emplacement de Microsoft Azure Hybrid Connection Manager doit être soigneusement étudié.

  • Suivre la stratégie pour une région chaude en attente. S'assurer que le réseau central et la connectivité, le réseau Hub, les contrôleurs de domaine, le DNS, le VPN ou l'Express Route, etc. sont présents et testés avant le déplacement des ressources.

  • Validez les listes de contrôle d’accès et la configuration réseau en amont ou en aval. Prenons l'exemple d'un service externe en aval qui n'autorise que le trafic de votre application. Un déménagement vers un nouveau plan d'application pour un Azure App Service multilocataire constituerait alors également un changement dans les adresses IP sortantes.

  • Dans la plupart des cas, il est préférable de s’assurer que les réseaux virtuels de la région cible disposent d’un espace d’adressage unique. Un espace d'adressage unique facilite la connectivité VNet si elle est nécessaire, par exemple, pour répliquer des données. Par conséquent, dans ces scénarios, il existe une exigence implicite à modifier :

    • DNS privé
    • Toute configuration codée en dur ou externe qui référence des ressources par une adresse IP (sans nom d'hôte)
    • ACL de réseau, y compris les groupes de sécurité de réseau et la configuration du pare-feu (tenir compte de l'impact sur les ANV sur place)
    • Toutes les règles d’acheminement, les tables de routage définies par l'utilisateur

    Veillez également à vérifier la configuration, y compris les plages d'adresses IP spécifiques à la région et les balises de service, si vous reprenez des ressources de déploiement DevOps existantes.

  • Moins de changements sont nécessaires pour le DNS privé déployé par le client qui est configuré pour transférer vers Azure pour les domaines Azure et Azure DNS Private Zones. Toutefois, étant donné que les points de terminaison privés sont basés sur un nom de domaine complet de ressource et qu’il s’agit souvent du nom de la ressource (qui peut être supposé être différent dans la région cible), n’oubliez pas de vérifier de manière croisée la configuration pour vous assurer que les noms de domaine complets référencés dans la configuration sont mis à jour en conséquence.

  • Recréez les points de terminaison privés, le cas échéant, dans la région cible. Il en va de même pour l'intégration du réseau régional VNet.

  • Le DNS pour l'environnement App Service est généralement géré par la solution DNS privée du client (il existe un réglage manuel disponible pour chaque application). L'environnement du service applicatif fournit un équilibreur de charge pour les entrées et sorties, tandis que Azure App Service lui-même filtre les en-têtes de l'hôte. Par conséquent, plusieurs noms personnalisés peuvent être dirigés vers le même point d'entrée de Azure App Service Environment. App Service Environment ne nécessite pas de validation de domaine.

    Remarque

    Le point de terminaison Kudu pour App Service Environment v3 n’est disponible qu’à {resourcename}.scm.{asename}.appserviceenvironment.net. Pour obtenir plus d’informations sur App Service Environment v3 DNS et Mise en réseau etc, consultez Mise en réseau App Service Environment.

    Dans le cas de l'environnement App Service, le client est propriétaire de l'acheminement et donc des ressources utilisées pour le transfert. Lorsque l'accès à l'environnement du service d'application est autorisé de l'extérieur ; généralement via un NVA de couche 7 ou un Reverse Proxy ; le Traffic Manager, ou Azure Front Door ou un autre service d'équilibrage de la charge globale de couche 7 peut être utilisé.

  • Pour la version mutualisée publique du service, un nom par défaut {resourcename}.azurewebsites.net est provisionné pour les points de terminaison du plan de données, ainsi qu’un nom par défaut pour le point de terminaison Kudu (SCM). Comme le service fournit un point final public par défaut, la liaison doit être vérifiée pour prouver la propriété du domaine. Cependant, une fois que la liaison est en place, une nouvelle vérification n'est pas nécessaire, pas plus qu'il n'est nécessaire que les enregistrements DNS publics pointent vers le point de terminaison de App Service.

  • Si vous utilisez un domaine personnalisé, liez-le de manière préemptive à l’application cible. Vérifiez et activez le domaine dans l’application cible.

Identités

  • Vous devez recréer toutes les identités managées affectées par le système, ainsi que votre application dans la nouvelle région cible. En règle générale, une application Microsoft Entra ID créée automatiquement (utilisée par EasyAuth) utilise par défaut le nom de la ressource d’application.

  • Les identités managées affectées par l’utilisateur ne peuvent pas non plus être déplacées entre les régions. Pour conserver les identités managées affectées par l’utilisateur dans le même groupe de ressources que votre application, vous devez les recréer dans la nouvelle région. Pour plus d’informations, consultez Relocaliser des identités managées pour les ressources Azure vers une autre région.

  • Accordez aux identités managées les mêmes autorisations dans vos services déplacés que les identités d’origine qu’elles remplacent, y compris les appartenances au groupe.

  • Planifiez le déplacement du fournisseur d’identité (IDP) vers la région cible. Bien que Microsoft Entra ID soit un service global, certaines solutions s'appuient sur un IDP local (ou en aval dans les locaux).

  • Mettez à jour toutes les ressources vers App Service qui peuvent s’appuyer sur les informations d’identification FTP Kudu.

Points de terminaison de service

Les points de terminaison de service de réseau virtuel pour Azure App Service limitent l’accès à un réseau virtuel spécifié. Les points de terminaison limitent également l’accès à une liste de plages d’adresses IPv4 (Internet Protocol version 4). L’accès est refusé à tout utilisateur se connectant au Event Hubs en dehors de ces sources. Si les points de terminaison de service ont été configurés dans la région source de la ressource Event Hubs, la même chose doit être effectuée dans la région cible.

Pour recréer l’instance Azure App Service dans la région cible, vous devez créer le VNet et le sous-réseau au préalable. Si le déplacement de ces deux ressources est effectué avec l’outil Azure Resource Mover, les points de terminaison de service ne sont pas configurés automatiquement. Par conséquent, ils doivent être configurés manuellement, ce qui peut être effectué dans le portail Azure, Azure CLI ou Azure PowerShell.

Relocaliser

Pour déplacer les ressources App Service, vous pouvez utiliser le Portail Microsoft Azure ou Infrastructure as Code (IaC).

Déplacer en utilisant le Portail Microsoft Azure

Le plus grand avantage de l'utilisation du Portail Microsoft Azure pour la relocalisation est sa simplicité. L'application, le plan et le contenu, ainsi que de nombreux paramètres sont clonés dans la nouvelle ressource et le nouveau plan App Service.

Gardez à l'esprit que pour les niveaux de Azure App Service Environment (isolé), vous devez d'abord redéployer l'ensemble de l'environnement de service applicatif dans une autre région, puis vous pouvez commencer à redéployer les plans individuels dans le nouvel environnement de service applicatif dans la nouvelle région.

Pour déplacer vos ressources App Service vers une nouvelle région à l’aide du Portail Microsoft Azure :

  1. Créez une sauvegarde de l’application source.
  2. Créez une application dans un nouveau plan App Service, dans la région cible.
  3. Restaurez la sauvegarde dans l’application cible.
  4. Si vous utilisez un domaine personnalisé, liez-le de manière préventive à l’application cible avec asuid. et activez le domaine dans l’application cible.
  5. Configurez tout le reste dans votre application cible pour qu’elle soit identique à l’application source et vérifiez votre configuration.
  6. Lorsque vous êtes prêt pour que le domaine personnalisé soit dirigé vers l’application cible, remappez le nom de domaine.

Relocalisation à l'aide de IaC

Utilisez IaC lorsqu'un pipeline d'intégration et de livraison ou déploiement continus (CI/CD) existe ou peut être créé. Avec un pipeline CI/CD en place, votre ressource App Service peut être créée dans la région cible au moyen d'une action de déploiement ou d'un déploiement Kudu zip.

Les exigences en matière de contrat de niveau de service doivent déterminer l'ampleur des efforts supplémentaires à fournir. Par exemple : s’agit-il d’un redéploiement avec un temps d’arrêt limité ou s’il s’agit d’un basculement en temps quasi réel nécessaire avec un temps d’arrêt minimal ou sans temps d’arrêt ?

L'inclusion de services externes d'acheminement du trafic global, tels que Traffic Manager ou Azure Front Door, permet de faciliter le basculement pour les utilisateurs et les applications externes.

Conseil

Il est possible d'utiliser Microsoft Azure Traffic Manager (ATM) lors du basculement de App Services derrière des points de terminaison privés. Bien que les points de terminaison privés ne soient pas accessibles par les sondes Traffic Manager : si tous les points de terminaison sont détériorés, ATM autorise le routage. Pour en savoir plus, voir Contrôle du trafic Azure App Service avec Azure Traffic Manager.

Valider

Une fois la réinstallation terminée, testez et validez Azure App Service avec les instructions recommandées :

  • Une fois Azure App Service relocalisé dans la région cible, exécutez un test d'intégration et un test de fumée. Vous pouvez tester manuellement ou exécuter un test à l'aide d'un script. Veillez à valider que toutes les configurations et les ressources dépendantes sont correctement liées et que toutes les données configurées sont accessibles.

  • Valider tous les composants et l'intégration de Azure App Service.

  • Effectuer des tests d'intégration sur le déploiement de la région cible, y compris tous les tests de régression formels. Les tests d'intégration doivent s'aligner sur le rythme habituel des processus de déploiement et de test applicables à la charge de travail.

  • Dans certains scénarios, en particulier lorsque la relocalisation comprend des mises à jour, des modifications des applications ou des ressources Azure, ou un changement de profil d'utilisation, utilisez des tests de charge pour valider que la nouvelle charge de travail est adaptée à l'usage prévu. Les tests de charge sont également l'occasion de valider les opérations et la couverture de surveillance. Par exemple, les tests de charge permettent de vérifier que les journaux d'infrastructure et d'application nécessaires sont générés correctement. Les tests de charge doivent être mesurés par rapport à des normes de performance établies pour la charge de travail.

Conseil

Le déménagement de Azure App Service est également l'occasion de réévaluer la planification de la disponibilité et de la reprise après sinistre. App Service et App Service Environment (App Service Environment v3) prennent en charge les zones de disponibilité et il est recommandé de configurer avec une configuration de zone de disponibilité. Gardez à l'esprit les conditions préalables au déploiement, la tarification et les limitations, et tenez-en compte dans la planification du déplacement des ressources. Si vous souhaitez en savoir plus sur la prise en charge des zones de disponibilité App Service, veuillez consulter la rubrique Fiabilité dans Azure App Service.

Nettoyage

Supprimez l’application source et le plan App Service. Un plan App Service appartenant à un niveau tarifaire non gratuit comporte des frais, même si aucune application ne s’exécute dans celui-ci.

Étapes suivantes

Clonage de l’application Azure App Service à l’aide de PowerShell