Partager via

Migration vers App Service Environment v3 en utilisant la fonctionnalité de migration côte à côte

  • Article

Remarque

La fonctionnalité de migration décrite dans cet article est utilisée pour la migration automatisée côte à côte (dans un autre sous-réseau) d’App Service Environment v2 vers App Service Environment v3. Si vous n’avez pas demandé de période de grâce de 30 jours, passez en revue la vue d’ensemble de la période de grâce, puis demandez une période de grâce en accédant au portail Azure et en visitant le panneau Migration pour chacun de vos environnements App Service.

Si vous recherchez des informations sur la fonctionnalité de migration sur place, consultez Migrer vers App Service Environment v3 à l’aide de la fonctionnalité de migration sur place. Si vous recherchez des informations sur les options de migration manuelle, consultez Options de migration manuelle. Pour vous aider à déterminer l’option de migration appropriée, consultez Arbre de décision du chemin de migration. Pour obtenir plus d’informations sur App Service Environment v3, consultez Vue d’ensemble d’App Service Environment v3.

La migration côte à côte s’accompagne de défis supplémentaires par rapport à une migration sur place. Pour les clients devant décider entre les deux options, nous recommandons d’utiliser la migration sur place, car il y a moins d’étapes et elle est peu complexe. Si vous décidez d’utiliser la migration côte à côte, passez en revue la section Sources courantes de problèmes lors de la migration à l’aide de la fonctionnalité de migration côte à côte pour éviter les pièges courants.

App Service peut automatiser la migration de votre environnement App Service Environment v1 et v2 vers un environnement App Service Environment v3. Il existe différentes options de migration. Passez en revue l’arbre de décision du chemin de migration pour déterminer quelle option convient le mieux à votre cas d’usage. App Service Environment v3 offre des avantages et des différences de fonctionnalités par rapport aux versions antérieures. Veillez à passer en revue les fonctionnalités prises en charge d’App Service Environment v3 avant de migrer pour réduire le risque d’un problème d’application inattendu.

La fonctionnalité de migration côte à côte automatise votre migration vers App Service Environment v3. La fonctionnalité de migration côte à côte crée un nouvel environnement App Service Environment v3 avec toutes vos applications dans un autre sous-réseau. Votre App Service Environment existant n’est pas supprimé tant que vous n’avez pas lancé sa suppression à la fin du processus de migration. Cette option de migration est optimale pour les clients qui souhaitent migrer vers App Service Environment v3 sans temps d’arrêt et peuvent prendre en charge l’utilisation d’un autre sous-réseau pour leur nouvel environnement. Si vous avez besoin d'utiliser le même sous-réseau et que vous pouvez prendre en charge environ une heure de temps d’arrêt de l’application, consultez la fonctionnalité de migration sur place. Pour connaître les options de migration manuelle qui vous permettent de migrer à votre propre rythme, consultez les options de migration manuelle.

Important

Si vous ne parvenez pas à effectuer toutes les étapes décrites dans ce tutoriel, vous rencontrerez des temps d’arrêt. Par exemple, si vous ne mettez pas à jour toutes les ressources dépendantes avec les nouvelles adresses IP ou que vous n’autorisez pas l’accès vers/à partir de votre nouveau sous-réseau, comme le cas pour votre coffre de clés de suffixe de domaine personnalisé, vous rencontrerez un temps d’arrêt jusqu’à ce que cela soit résolu.

Il est recommandé d’utiliser cette fonctionnalité pour les environnements de développement avant de migrer des environnements de production, afin de répéter le processus et de vous assurer de l’absence de problèmes imprévus. Veuillez nous faire part de vos commentaires sur cet article ou cette fonctionnalité à l’aide des boutons situés en bas de la page.

Scénarios pris en charge

Pour le moment, la fonctionnalité de migration sur place ne prend pas en charge les migrations vers App Service Environment v3 dans les régions suivantes :

Azure (public)

  • Émirats arabes unis Centre

Azure Government

  • Centre des États-Unis – US DoD
  • Est des États-Unis – US DoD
  • Gouvernement des États-Unis – Arizona
  • Gouvernement des États-Unis – Texas
  • Gouvernement américain - Virginie

Microsoft Azure géré par 21Vianet

  • Chine orientale 2
  • Chine Nord 2

Les configurations App Service Environment suivantes peuvent être migrées en utilisant la fonctionnalité de migration côte à côte. Le tableau indique la configuration App Service Environment v3 lors de l’utilisation de la fonctionnalité de migration côte à côte en fonction de votre environnement App Service Environment existant.

Configuration Configuration d’App Service Environment v3
App Service Environment v2 avec Internal Load Balancer (ILB)) Environnement App Service v3 avec ILB
App Service Environment v2 avec équilibreur externe (ELB/internet accessible avec adresse IP publique) App Service Environment v3 avec ELB
App Service Environment v2 avec ILB et un suffixe de domaine personnalisé App Service Environment v3 avec ILB et un suffixe de domaine personnalisé

App Service Environment v3 peut être déployé en tant que redondant interzone. La redondance de zone peut être activée tant que votre App Service Environment v3 est dans une région qui prend en charge la redondance de zone.

Si vous souhaitez que votre nouvel App Service Environment v3 utilise un suffixe de domaine personnalisé et que vous n’en utilisez pas actuellement, le suffixe de domaine personnalisé peut être configuré à tout moment une fois la migration terminée. Pour plus d’informations, consultez Configurer le suffixe de domaine personnalisé pour App Service Environment. Si votre environnement existant a un suffixe de domaine personnalisé et que vous ne souhaitez plus l’utiliser, vous devez configurer un suffixe de domaine personnalisé pour la migration. Vous pouvez supprimer le suffixe de domaine personnalisé une fois la migration terminée.

Limitations de la fonctionnalité de migration côte à côte

Les limitations suivantes s’appliquent lors de l’utilisation de la fonction de migration côte à côte :

  • Votre nouvel App Service Environment v3 se trouve dans un sous-réseau différent, mais dans le même réseau virtuel que votre environnement existant.
  • Vous ne pouvez pas changer la région dans laquelle se trouve votre App Service Environment.
  • L’environnement App Service Environment avec ELB accessible via Internet ne peut pas être migré vers l’environnement App Service Environment v3 avec ILB, et vice versa.
  • Si votre App Service Environment existant utilise un suffixe de domaine personnalisé, vous devez configurer le suffixe de domaine personnalisé pour votre App Service Environment v3 pendant le processus de migration.
    • Si vous ne souhaitez plus utiliser un suffixe de domaine personnalisé, vous pouvez le supprimer une fois la migration terminée.
  • La fonctionnalité de migration côte à côte est disponible seulement en utilisant l’interface CLI ou via l’API REST. La fonctionnalité n’est pas disponible dans le portail Azure.

App Service Environment v3 ne prend pas en charge les fonctionnalités suivantes que vous utilisez peut-être avec votre instance App Service Environment v2 actuelle.

  • Configuration d’une liaison TLS/SSL basée sur une adresse IP avec vos applications
  • App Service Environment v3 ne revient pas à Azure DNS si vos serveurs DNS personnalisés configurés dans le réseau virtuel ne sont pas en mesure de résoudre un nom donné. Si ce comportement est nécessaire, veillez à disposer d’un redirecteur vers un DNS public ou à inclure Azure DNS dans la liste des serveurs DNS personnalisés.

La fonctionnalité de migration côte à côte ne prend pas en charge les scénarios suivants. Consultez les options de migration manuelle si votre environnement App Service Environment figure dans l’une de ces catégories.

  • Environnement App Service v1
    • Vous pouvez trouver la version de votre environnement App Service Environment en y accédant dans le portail Azure et en sélectionnant Configuration sous Paramètres sur le côté gauche. Vous pouvez également utiliser Azure Resource Explorer et vérifier la valeur de la propriété kind pour votre environnement App Service Environment.
    • Si vous disposez d’un App Service Environment v1, vous pouvez migrer à l’aide de la fonctionnalité de migration sur place ou l’une des options de migration manuelle.
  • App Service Environment v2 avec ELB et des adresses IP SSL
  • Environnement App Service Environment v2 épinglé à la zone
  • App Service Environment avec un nom qui ne respecte pas la limite de caractères. Le nom entier (y compris le suffixe de domaine) doit être de 64 caractères maximum. Par exemple : my-ase-name.appserviceenvironment.net pour ILB et my-ase-name.p.azurewebsites.net pour ELB doivent comporter au plus 64 caractères. Si vous ne respectez pas la limite de caractères, vous devez effectuer une migration manuelle. La limite de caractères spécifique au nom d’un App Service Environment est les suivantes :
    • La limite de caractères du nom d’un App Service Environment ILB est de 36 caractères
    • La limite de caractères du nom App Service Environment ELB est de 42 caractères

La plateforme App Service évalue votre App Service Environment pour vérifier la prise en charge de la migration côte à côte. Si votre scénario ne passe pas avec succès toutes les vérifications de validation, vous ne pouvez pas migrer en utilisant la fonctionnalité de migration côte à côte pour le moment. Si votre environnement est dans un état non sain ou suspendu, vous ne pouvez pas effectuer la migration tant que vous n’aurez pas effectué les mises à jour nécessaires.

Notes

App Service Environment v3 ne prend pas en charge IP SSL. Si vous utilisez IP SSL, vous devez supprimer toutes les liaisons SSL IP avant de migrer vers App Service Environment v3. La fonctionnalité de migration prend en charge votre environnement une fois toutes les liaisons IP SSL supprimées.

Dépannage

Si votre App Service Environment échoue aux vérifications de validation ou vous essayez d’effectuer une étape de migration dans le mauvais ordre, l’un des messages d’erreur suivants s’affiche :

Message d’erreur Description Recommandation
La migration ne peut être appelée que sur un ASE dans un réseau virtuel ARM, et cet ASE est dans un réseau virtuel classique. Les environnements App Service Environment dans des réseaux virtuels classiques ne peuvent pas migrer en utilisant la fonctionnalité de migration côte à côte. Faites la migration en utilisant une des options de migration manuelle.
La migration ASEv3 n’est pas encore prête. L’infrastructure sous-jacente n’est pas prête à prendre en charge App Service Environment v3. Faites la migration en utilisant une des options de migration manuelle si vous voulez migrer immédiatement. Sinon, attendez que la fonctionnalité de migration côte à côte soit disponible dans votre région.
Impossible d’activer la redondance de zone pour cet ASE. La région dans laquelle App Service Environment se trouve ne prend pas en charge la redondance de zone. Si vous devez activer la redondance de zone, utilisez l’une des options de migration manuelle pour migrer vers une région qui prend en charge la redondance de zone.
La migration ne peut pas être appelée sur le suffixe DNS personnalisé de cet ASE pour l’instant. La migration de suffixe de domaine personnalisé est bloquée. Ouvrez un cas de support pour solliciter la résolution de votre problème.
La migration d’ASE avec redondance de zone ne peut pas être effectuée pour l’instant. La migration d’App Service Environment avec redondance de zone est bloquée. Ouvrez un cas de support pour solliciter la résolution de votre problème.
La migration ne peut pas être effectuée sur ASE v2 épinglé à une zone. Un environnement App Service Environment v2 qui est épinglé à une zone ne peut pas être migré en utilisant la fonctionnalité de migration côte à côte pour le moment. Faites la migration en utilisant une des options de migration manuelle si vous voulez migrer immédiatement.
Une opération de restauration de migration existante est en cours, veuillez réessayer plus tard. Une tentative de migration précédente est restaurée. Attendez que la restauration en cours se termine avant de tenter de redémarrer la migration.
Properties.VirtualNetwork.Id doit contenir l’ID de la ressource du sous-réseau. L’erreur s’affiche si vous tentez de migrer sans fournir de nouveau sous-réseau pour le placement de votre App Service Environment v3. Veillez à suivre les instructions et à effectuer l’étape afin d’identifier le sous-réseau que vous utiliserez pour votre App Service Environment v3.
Impossible de passer à <requested phase> depuis la phase actuelle <previous phase> de la migration sans temps d’arrêt. Cette erreur s’affiche si vous tentez d’effectuer une étape de migration dans un ordre incorrect. Veillez à suivre les étapes de migration dans l’ordre.
Échec du démarrage de l’opération de restauration sur ASE dans l’état hybride, veuillez réessayer plus tard. Cette erreur s’affiche si vous essayez de restaurer la migration, mais qu’une erreur se produit. Cette erreur n’affecte pas votre ancien ou votre nouvel environnement. Ouvrez un cas de support pour solliciter la résolution de votre problème.
Cet ASE ne peut pas être migré sans temps d’arrêt. Cette erreur s’affiche si vous essayez d’utiliser la fonctionnalité de migration côte à côte sur un environnement App Service Environment v1. La fonctionnalité de migration côte à côte ne prend pas en charge App Service Environment v1. Migrez à l’aide de la fonctionnalité de migration sur place ou l’une des options de migration manuelle.
La migration n’est pas disponible pour cet abonnement. Le support doit être impliqué pour la migration de cet App Service Environment. Ouvrez un cas de support pour solliciter la résolution de votre problème.
La migration avec redondance de zone ne peut pas être effectuée, car les adresses IP créées au cours de la pré-migration ne sont pas redondantes interzone. Cette erreur apparaît si vous tentez une migration redondante de zone mais que les adresses IPs générées lors de l'étape de génération d'adresses IPs n'ont pas été créées comme redondantes de zone. La plate-forme tente de rendre toutes les zones IPs redondantes pour garantir la résilience du backend. Ouvrez un dossier de support pour engager le support si vous avez besoin d’activer la redondance de zone. Les ingénieurs annuleront la migration et autoriseront une autre tentative de création des adresses IPs. Sinon, vous pouvez migrer sans activer la redondance de zone.
La migration ne peut pas être appelée si SSL IP est activé sur l’un des sites Les environnements App Service Environment qui ont des sites où SSL IP est activé ne peuvent pas être migrés en utilisant la fonctionnalité de migration côte à côte. Supprimez IP SSL de toutes vos applications dans l’environnement ASE pour activer la fonctionnalité de migration.
Impossible de migrer au sein du même sous-réseau. L’erreur s’affiche si vous spécifiez le même sous-réseau que votre environnement actuel pour le placement de votre App Service Environment v3. Vous devez spécifier un sous-réseau différent pour votre environnement App Service v3. Si vous devez utiliser le même sous-réseau, migrez à l’aide de la fonctionnalité de migration sur place.
L’abonnement comporte trop d’environnements ASE Supprimez-en quelques-uns avant d’essayer d’en créer davantage. Le quota App Service Environment pour votre abonnement est atteint. Supprimez les environnements inutiles ou contactez le support pour passer en revue vos options.
La migration ne peut pas être appelée sur cet ASE tant que la mise à niveau active n’a pas terminé. Les instances App Service Environnement ne peuvent pas être migrées pendant les mises à niveau de la plateforme. Vous pouvez définir votre préférence de mise à niveau à partir du portail Azure. Les mises à niveau prennent 8 à 12 heures ou plus selon la taille (nombre d’instances/cœurs) d’App Service Environment. Attendez que la mise à niveau se termine, puis migrez.
Opération de gestion App Service Environment en cours. Votre environnement ASE subit une opération de gestion. Ces opérations peuvent inclure des activités telles que des déploiements ou des mises à niveau. La migration est bloquée jusqu’à ce que ces opérations soient terminées. Vous pouvez migrer une fois ces opérations terminées.
Votre InteralLoadBalancingMode n’est pas actuellement pris en charge. Les environnements App Service Environments avec InternalLoadBalancingMode réglé sur certaines valeurs ne peuvent pas être migrés à l’aide de la fonctionnalité de migration à ce stade. L’équipe Microsoft doit changer manuellement InternalLoadBalancingMode. Ouvrez un cas de support pour solliciter la résolution de votre problème. Demandez une mise à jour de InternalLoadBalancingMode.
La migration complète ne peut pas être appelée avant la génération d’adresses IP Cette erreur s’affiche si vous tentez de migrer avant la fin des étapes de prémigration. Assurez-vous d’avoir effectué toutes les étapes de prémigration avant d’essayer une migration. Consultez le guide pas à pas pour la migration.
La migration complète ne peut pas être appelée sur Ase avec un jeu de suffixes dns personnalisé, mais sans configuration de suffixe Dns personnalisé AseV3 configurée. Votre ASE existant utilise un suffixe de domaine personnalisé. Vous devez configurer le suffixe de domaine personnalisé pour votre ASE v3 pendant le processus de migration. Configurer un suffixe de domaine personnalisé. Si vous ne souhaitez plus utiliser un suffixe de domaine personnalisé, vous pouvez le supprimer une fois la migration terminée.

Vue d’ensemble du processus de migration en utilisant la fonctionnalité de migration côte à côte

La migration côte à côte se compose d’une série d’étapes qui doivent être suivies dans l’ordre. Les points clés sont fournis pour un sous-ensemble des étapes. Il est important de comprendre ce qui se passe pendant ces étapes et comment votre environnement et vos applications sont affectés. Après avoir consulté les informations suivantes et lorsque vous êtes prêt à effectuer la migration, suivez le guide pas à pas.

Valider le fait que la migration est prise en charge à l’aide de la fonctionnalité de migration côte à côte pour votre ASE

La plateforme valide que votre ASE peut être migré en utilisant la fonctionnalité de migration côte à côte. Si votre ASE ne passe pas avec succès toutes les vérifications de validation, vous ne pouvez pas migrer en utilisant la fonctionnalité de migration côte à côte pour le moment. Consultez la section Résolution des problèmes pour plus d’informations sur les causes possibles de l’échec de validation. Si votre environnement est dans un état non sain ou suspendu, vous ne pouvez pas effectuer la migration tant que vous n’aurez pas effectué les mises à jour nécessaires. Si vous ne pouvez pas effectuer une migration à l’aide de la fonctionnalité de migration côte à côte, consultez les options de migration manuelle.

La validation vérifie également si votre ASE est sur la build minimale requise pour la migration. Cette build peut être plus récente que la build standard qui est déployée lors du cycle de mise à jour/maintenance de routine de la plateforme. La build minimale est mise à jour régulièrement pour vous assurer que les derniers correctifs et améliorations des bogues sont disponibles. Si votre ASE ne se trouve pas sur la build minimale, vous devez démarrer la mise à niveau vous-même. Cette mise à niveau est un processus standard qui n’affecte pas votre ASE, mais vous ne pouvez pas mettre à l’échelle ou apporter des modifications à votre ASE pendant la mise à niveau. Vous ne pouvez effectuer une migration avant la fin de la mise à niveau. Les mises à niveau peuvent prendre 8 à 12 heures ou plus en fonction de la taille de votre environnement. Si vous planifiez une fenêtre de temps spécifique pour votre migration, vous devez exécuter la vérification de validation 24 à 48 heures avant votre heure de migration planifiée, afin de vous assurer que vous disposez du temps nécessaire pour une mise à niveau s’il est nécessaire d’en réaliser une.

Sélectionnez et préparez le sous-réseau pour votre nouvel App Service Environment v3

La plateforme crée votre nouvel App Service Environment v3 dans un sous-réseau différent de celui de votre App Service Environment existant. Vous devez sélectionner un sous-réseau qui remplit les conditions suivantes :

  • Le sous-réseau doit se trouver dans le même réseau virtuel, et par conséquent, dans votre App Service Environment existant.
    • Si votre réseau virtuel n’a pas de sous-réseau disponible, vous devez en créer un. Vous devrez peut-être augmenter l’espace d’adressage de votre réseau virtuel pour créer un sous-réseau. Pour plus d’informations, consultez Créer un réseau virtuel.
  • Le sous-réseau doit pouvoir communiquer dans les deux sens avec le sous-réseau dans lequel se trouve votre environnement App Service existant. Vérifiez qu’il n’existe pas de groupes de sécurité réseau ou d’autres configurations réseau qui empêchent la communication entre les sous-réseaux.
  • Le sous-réseau doit avoir une seule délégation de Microsoft.Web/hostingEnvironments.
  • Le sous-réseau doit avoir suffisamment d’adresses IP disponibles pour prendre en charge votre nouvel App Service Environment v3. Le nombre d’adresses IP nécessaires dépend du nombre d’instances que vous souhaitez utiliser pour votre nouvel App Service Environment v3. Pour plus d’informations, consultez Mise en réseau d’App Service Environment v3.
  • Le sous-réseau ne doit pas avoir de verrous appliqués à celui-ci. S’il existe des verrous, ils doivent être supprimés avant la migration. Les verrous peuvent être lus si nécessaire une fois la migration terminée. Pour plus d’informations sur les verrous et l’héritage des verrous, consultez Verrouiller vos ressources pour protéger votre infrastructure.
  • Il ne doit y avoir aucune stratégie Azure bloquant la migration ou les actions associées. S’il existe des stratégies qui bloquent la création d’App Service Environment ou la modification des sous-réseaux, elles doivent être supprimées avant la migration. Les stratégies peuvent être lues si nécessaire une fois la migration terminée. Pour plus d’informations sur Azure Policy, consultez Vue d’ensemble d’Azure Policy.

Générer des adresses IP sortantes pour votre nouvel App Service Environment v3

La plateforme crée les nouvelles adresses IP sortantes. Les activités avec votre App Service Environment existant ne seront pas interrompues pendant que ces adresses IP sont en cours de création. Toutefois, vous ne pouvez pas mettre à l’échelle ni modifier votre environnement existant. Ce processus prend environ 15 minutes.

Une fois l’opération terminée, les nouvelles adresses IP sortantes utilisées par votre future instance App Service Environment v3 sont créées. Ces nouvelles adresses IP n’ont aucun effet sur votre environnement existant.

Vous recevez la nouvelle adresse IP entrante une fois la migration terminée, mais avant d’effectuer la modification du DNS pour rediriger le trafic client vers votre nouvel App Service Environment v3. Vous n’obtenez pas l’adresse IP entrante à ce stade du processus, car il existe des dépendances sur les ressources App Service Environment v3 qui sont créées pendant l’étape de migration. Vous avez la possibilité de mettre à jour toutes les ressources qui dépendent de la nouvelle adresse IP entrante avant de rediriger le trafic vers votre nouvel App Service Environment v3.

Mettre à jour les ressources dépendantes avec les nouvelles adresses IP sortantes

Les nouvelles adresses IP sortantes sont créées et vous sont fournies avant que vous ne commenciez la migration réelle. La nouvelle sortie par défaut vers les adresses publiques Internet vous permet d’ajuster les pare-feu externes, le routage DNS et toutes les autres ressources qui s’appuient sur ces adresses IP avant d’effectuer la migration. Il vous incombe de mettre à jour toutes les ressources qui seront affectées par la modification de l’adresse IP associée au nouvel environnement App Service Environment v3. Ne passez pas à l’étape suivante tant que vous n’avez pas effectué toutes les mises à jour requises. Vous risquez de subir des temps d’arrêt pendant et après l’étape de migration s’il existe des dépendances par rapport aux adresses IP sortantes, et si vous n’arrivez pas à effectuer toutes les mises à jour nécessaires. En effet, une fois la migration démarrée, même si le trafic est toujours dirigé vers vos front-ends App Service Environment v2, le calcul sous-jacent correspond à votre nouvel environnement App Service Environment v3 dans le nouveau sous-réseau.

Cette étape est également un bon moment pour passer en revue les modifications des dépendances des réseaux entrantes et sortantes lors du passage à App Service Environment v3, notamment le changement de port pour la sonde d'intégrité Azure Load Balancer qui utilise désormais le port 80.

Déléguer votre sous-réseau d’App Service Environment

L’environnement App Service Environment v3 exige que le sous-réseau où il se trouve dispose d’une seule délégation de Microsoft.Web/hostingEnvironments. La migration échoue si le sous-réseau d’App Service Environment n’est pas délégué ou s’il est délégué à une autre ressource. Vérifiez que le sous-réseau que vous sélectionnez pour votre nouvel App Service v3 a une seule délégation de Microsoft.Web/hostingEnvironments.

Prendre connaissance des changements de taille d’instance

Vos plans App Service sont créés avec la référence SKU v2 isolée correspondante dans le cadre de la migration. Par exemple, les plans I2 correspondent à I2v2. Vos applications peuvent être surprovisionnées après la migration, car le niveau Isolated v2 dispose de plus de mémoire et d’UC par taille d’instance correspondante. Vous avez la possibilité de faire évoluer votre environnement selon vos besoins une fois la migration terminée. Pour plus d’informations, consultez les détails de la référence SKU.

Vérifiez qu’il n’y a pas de verrous sur vos ressources

Les verrous de réseau virtuel bloquent les opérations de plateforme pendant la migration. Si votre réseau virtuel a des verrous, vous devez les supprimer avant la migration. Les verrous peuvent être lus si nécessaire une fois la migration terminée. Les verrous peuvent exister dans trois étendues différentes : abonnement, groupe de ressources et ressource. Lorsque vous appliquez un verrou à une étendue parente, toutes les ressources de cette étendue héritent du même verrou. Si vous avez des verrous appliqués à l’étendue de l’abonnement, de la ressource ou du groupe de ressources, ils doivent être supprimés avant la migration. Pour plus d’informations sur les verrous et l’héritage des verrous, consultez Verrouiller vos ressources pour protéger votre infrastructure.

Assurez-vous qu’aucune stratégie Azure ne bloque la migration

Azure Policy peut être utilisé pour refuser la création et la modification de ressources à certains principaux. Si une stratégie bloque la création d’App Service Environments ou la modification des sous-réseaux, vous devez la supprimer avant de migrer. La stratégie peut être lue si nécessaire une fois la migration terminée. Pour plus d’informations sur Azure Policy, consultez Vue d’ensemble d’Azure Policy.

Ajouter un suffixe de domaine personnalisé (facultatif)

Si votre ASE existant utilise un suffixe de domaine personnalisé, vous devez en configurer un pour votre nouvel App Service Environment v3. Le suffixe de domaine personnalisé sur App Service Environment v3 est implémenté différemment que sur App Service Environment v2. Vous devez fournir le nom de domaine personnalisé, l’identité managée et le certificat, qui doivent être stockés dans Azure Key Vault. Pour plus d’informations sur le suffixe de domaine personnalisé App Service Environment v3, notamment les exigences, les instructions pas à pas et les bonnes pratiques, consultez Configurer un suffixe de domaine personnalisé pour App Service Environment. Si votre ASE v2 a un suffixe de domaine personnalisé, vous devez configurer un suffixe de domaine personnalisé pour votre nouvel environnement, même si vous ne souhaitez plus l’utiliser. Une fois la migration terminée, vous pouvez supprimer la configuration du suffixe de domaine personnalisé si nécessaire.

Si votre migration inclut un suffixe de domaine personnalisé pour App Service Environment v3, le domaine personnalisé n’apparaît plus dans la section Essentials de la page Vue d’ensemble du portail, car il concerne App Service Environment v1/v2. Au lieu de cela, pour App Service Environment v3, accédez à la page Suffixe de domaine personnalisé dans laquelle vous pouvez confirmer que votre suffixe de domaine personnalisé est configuré correctement. En outre, sur App Service Environment v2, si vous avez un suffixe de domaine personnalisé, le nom d’hôte par défaut inclut votre suffixe de domaine personnalisé et est sous la forme APP-NAME.internal.contoso.com. Sur App Service Environment v3, le nom d’hôte par défaut utilise toujours le suffixe de domaine par défaut et est sous la forme APP-NAME.ASE-NAME.appserviceenvironment.net. Cette différence est due au fait qu’App Service Environment v3 conserve le suffixe de domaine par défaut quand vous ajoutez un suffixe de domaine personnalisé. Avec App Service Environment v2, il n’existe qu’un seul suffixe de domaine.

Migrer vers App Service Environment v3

Après avoir effectué les étapes précédentes, vous devez poursuivre la migration dès que possible.

Il n’y a aucun temps d’arrêt de l’application pendant la migration, mais comme lors de l’étape de génération d’adresses IP, vous ne pouvez pas mettre à l’échelle, modifier votre App Service Environment existant ou déployer des applications sur celui-ci pendant ce processus.

Important

Comme la mise à l’échelle est bloquée pendant la migration, vous devez mettre à l’échelle votre environnement avec la taille souhaitée avant de commencer la migration. Si la mise à l’échelle automatique est activée et qu’un événement de mise à l’échelle se produit avant le début de la migration, vous devez attendre que l’événement de mise à l’échelle se termine avant de démarrer la migration. Vous devez désactiver la mise à l’échelle automatique avant de démarrer la migration pour éviter ce problème. Si vous devez mettre à l’échelle votre environnement après la migration, vous pouvez le faire dès la fin de la migration.

C’est également lors de cette étape que vous décidez si vous souhaitez activer la redondance de zone pour votre nouvel App Service Environment v3. La redondance de zone peut être activée tant que votre App Service Environment v3 est dans une région qui prend en charge la redondance de zone.

La migration côte à côte nécessite une fenêtre de service de trois à six heures pour les migrations d’App Service Environment v2 vers App Service Environment v3. Pendant la migration, les configurations de mise à l’échelle et d’environnement sont bloquées et les événements suivants se produisent :

  • Le nouvel App Service Environment v3 est créé dans le sous-réseau que vous avez sélectionné.
  • Vos nouveaux plans App Service sont créés dans le nouvel App Service Environment v3 avec le niveau Isolé v2 correspondant.
  • Vos applications sont créées dans le nouvel App Service Environment v3.
  • Les calculs/Workers sous-jacents de vos applications sont déplacés vers le nouvel environnement App Service Environment v3, ce qui signifie que vos applications s’exécutent désormais dans votre environnement App Service Environment v3. Toutefois, par défaut, vos front-ends App Service Environment v2 continuent de s’exécuter et de gérer le trafic. Votre ancienne adresse IP entrante reste utilisée, mais vos nouvelles IP sortantes sont utilisées. De plus, vos nouveaux front-ends App Service Environment v3 sont créés, et prêts à gérer le trafic.
    • Pour les ASE ILB, vos serveurs front-end ASE v3 ne sont pas utilisés tant que vous n’avez pas mis à jour vos zones DNS privées avec la nouvelle adresse IP entrante.
    • Pour les ASE ELB, le processus de migration ne redirige pas le trafic vers les serveurs front-end ASE v3 tant que vous n’avez pas terminé la dernière étape de la migration.

Une fois cette étape terminée, le trafic de votre application va toujours à vos anciens front-ends App Service Environment v2 et à l’adresse IP qui leur a été attribuée. Toutefois, vos applications s’exécutent en réalité sur les Workers de votre nouvel environnement App Service Environment v3.

Remarque

En raison d’un bogue connu, les travaux web risquent de ne pas démarrer pendant l’étape de déploiement hybride. Si vous utilisez des travaux web, ce bogue peut entraîner des problèmes/temps d’arrêt au niveau des applications. Ouvrez une demande de support si vous avez des questions ou des préoccupations concernant ce problème.

Obtenir une adresse IP entrante pour votre nouvel App Service Environment v3 et mettre à jour les ressources dépendantes

La nouvelle adresse IP entrante est fournie pour vous permettre de configurer de nouveaux points de terminaison avec des services tels que Traffic Manager ou Azure Front Door, et de mettre à jour vos zones DNS privées. Ne passez pas à l’étape suivante tant que vous n’avez pas effectué ces modifications. Il y a un temps d’arrêt si vous ne mettez pas à jour les ressources dépendantes avec la nouvelle adresse IP entrante. Il vous incombe de mettre à jour toutes les ressources qui sont affectées par la modification de l’adresse IP associée au nouvel environnement App Service Environment v3. Ne passez pas à l’étape suivante tant que vous n’avez pas effectué toutes les mises à jour requises.

Rediriger le trafic client, valider votre ASE v3 et effectuer la migration

La dernière étape consiste à rediriger le trafic vers vos nouveaux front-ends App Service Environment v3, et à effectuer la migration. Avant d’effectuer cette étape, vous devez passer en revue votre nouvel App Service Environment v3 et effectuer les tests nécessaires pour vérifier qu’il fonctionne comme prévu. Par défaut, le trafic va vers vos front-ends App Service Environment v2. Si vous utilisez un ILB App Service Environment v3, vous pouvez tester votre serveur front-end App Service Environment v3 en mettant à jour votre zone DNS privée avec la nouvelle adresse IP entrante. Si vous utilisez un ELB App Service Environment v3, le processus de test dépend de votre configuration réseau spécifique. Une méthode simple pour tester les environnements ELB consiste à mettre à jour votre fichier hôtes pour utiliser votre nouvelle adresse IP entrante App Service Environment v3. Si certains de vos domaines personnalisés sont attribués à vos applications individuelles, vous pouvez également mettre à jour leur DNS pour les faire pointer vers la nouvelle adresse IP entrante. Tester cette modification vous permet de valider entièrement votre environnement ASE v3 avant de lancer l’étape finale de la migration où votre ancien ASE est supprimé.

Une fois que vous êtes prêt à rediriger le trafic, vous pouvez effectuer l’étape finale de la migration. Cette étape met à jour les enregistrements DNS internes/de plateforme pour qu’ils pointent vers l’adresse IP de l’équilibreur de charge de votre nouvel environnement App Service Environment v3 ainsi que vers les front-ends créés durant la migration. Les changements prennent effet en quelques minutes. Il vous appartient de mettre à jour vos enregistrements DNS pour qu’ils pointent vers la nouvelle adresse IP entrante. Si vous êtes confronté à des problèmes ou des temps d’arrêt d’application, vérifiez vos paramètres de cache et TTL (durée de vie). Cette étape arrête également votre ancien App Service Environment et le supprime. Votre nouvel App Service Environment v3 est maintenant votre environnement de production.

Important

La plateforme garantit une expérience de migration sans temps d’arrêt. Toutefois, vos paramètres DNS peuvent entraîner un temps d’arrêt durant l’étape de changement de DNS. Cela peut être dû à des problèmes liés aux paramètres TTL (durée de vie) et de cache, car le trafic est peut-être toujours redirigé vers votre ancien environnement App Service Environment après le changement de DNS. Vous devez passer en revue vos paramètres DNS, vérifier que votre paramètre TTL est faible, et que votre fournisseur DNS prend en charge la propagation rapide. Si votre paramètre TTL est élevé, vous risquez de subir un temps d’arrêt durant l’étape de changement de DNS.

Remarque

Il est important de terminer cette étape dès que possible. Lorsque votre App Service Environment est en état hybride, il ne pourra pas y avoir de mise à niveau de plateforme ni de correctifs de sécurité, ce qui le rend plus vulnérable à l’instabilité et aux menaces de sécurité.

Vous avez 14 jours pour effectuer cette étape. Après 14 jours, la plateforme effectue automatiquement la migration et supprime votre ancien environnement. Si vous avez besoin de plus de temps, vous pouvez ouvrir un cas de support pour discuter de vos options.

Si vous rencontrez des problèmes avec votre nouvel App Service Environment v3, n’exécutez pas la commande pour rediriger le trafic client. Cette commande lance également la suppression de votre App Service Environment v2. Si vous rencontrez un problème, contactez le support.

Utiliser la fonctionnalité de migration côte à côte

Prérequis

Assurez-vous de comprendre comment la migration vers un environnement App Service Environment v3 affecte vos applications. Passez en revue le processus de migration dans son intégralité pour comprendre la chronologie du processus, et savoir quand et où vous devez intervenir. Passez également en revue les FAQ qui peuvent répondre à certaines de vos questions.

Vérifiez qu’il n’existe aucun verrou sur votre réseau virtuel, vos groupes de ressources, ressources ou votre abonnement. Les verrous bloquent les opérations de plateforme pendant la migration.

Vérifiez qu’aucune stratégie Azure ne bloque les actions qui sont requises pour la migration, notamment les modifications de sous-réseau et les créations de ressources Azure App Service. Les stratégies bloquant des créations et des modifications de ressources peuvent entraîner l’échec ou le blocage d’une migration.

Du fait que votre App Service Environment v3 se trouve dans un autre sous-réseau de votre réseau virtuel, vous devez vérifier que vous avez un sous-réseau disponible dans votre réseau virtuel qui répond aux exigences de sous-réseau pour App Service Environment v3. Le sous-réseau que vous sélectionnez doit également être en mesure de communiquer avec le sous-réseau dans lequel se trouve votre fonctionnalité App Service Environment existante. Vérifiez que rien ne bloque la communication entre les deux sous-réseaux. Si vous ne disposez pas d’un sous-réseau disponible, vous devez en créer un avant de migrer. Il est possible que la création d’un sous-réseau implique l’augmentation de l’espace d’adressage de votre réseau virtuel. Si vous souhaitez obtenir plus d’informations, consultez Créer un réseau virtuel et un sous-réseau.

Comme la mise à l’échelle est bloquée pendant la migration, vous devez mettre à l’échelle votre environnement avec la taille souhaitée avant de commencer la migration. Si vous devez mettre à l’échelle votre environnement après la migration, vous pouvez le faire dès la fin de la migration. Si la mise à l’échelle automatique est activée, si un événement de mise à l’échelle se produit avant que la migration commence, votre migration est bloquée jusqu’à ce que l’événement de mise à l'échelle se termine. Vous devez désactiver la mise à l’échelle automatique avant de démarrer la migration pour éviter ce problème.

Suivez les étapes décrites ici dans l’ordre et telles qu’elles sont écrites, car vous effectuez des appels d’API REST Azure. Nous vous recommandons d’utiliser Azure CLI pour effectuer ces appels d’API. Pour obtenir des informations sur les autres méthodes, consultez Informations de référence sur l’API REST Azure.

Pour ce guide, installez Azure CLI ou utilisez Azure Cloud Shell et utilisez un interpréteur de commandes Bash.

Remarque

Nous vous recommandons d’utiliser un interpréteur de commandes Bash pour exécuter les commandes fournies dans ce guide. Les commandes peuvent ne pas être compatibles avec les caractères d’échappement et les conventions PowerShell.

Important

Pendant la migration, le portail Azure peut afficher des informations incorrectes sur votre environnement App Service et vos applications. N’accédez pas à l’expérience de migration dans le portail Azure, car la fonctionnalité de migration côte à côte n’est pas disponible. Nous vous recommandons d’utiliser Azure CLI pour vérifier l’état de votre migration. Si vous avez des questions sur l’état de votre migration ou de vos applications, contactez le support technique.

1. Sélectionnez le sous-réseau pour votre nouvel App Service Environment v3

Sélectionnez un sous-réseau dans votre App Service Environment v3 qui respecte les exigences de sous-réseau pour App Service Environment v3. Notez le nom du sous-réseau que vous sélectionnez. Ce sous-réseau doit être différent du sous-réseau dans lequel se trouve votre fonctionnalité App Service Environment existante.

2. Obtenir votre ID App Service Environment

Exécutez les commandes suivantes pour obtenir votre ID App Service Environment et le stocker en tant que variable d’environnement. Remplacez les espaces réservés du nom et des groupes de ressources par vos valeurs pour l’environnement App Service que vous voulez migrer. ASE_RG et VNET_RG sont les mêmes si votre réseau virtuel et App Service Environment se trouvent dans le même groupe de ressources.

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

3. Confirmer que la migration est prise en charge

La commande suivante vérifie si votre environnement App Service Environment est pris en charge pour la migration. Cette commande valide également que votre ASE se trouve sur la version de build prise en charge pour la migration. Si votre ASE ne se trouve pas sur la version de build prise en charge, vous devez démarrer la mise à niveau vous-même. Pour plus d’informations sur la mise à niveau de la pré-migration, consultez Valider le fait que la migration est prise en charge à l’aide de la fonctionnalité de migration côte à côte pour votre ASE.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

S’il n’y a pas d’erreurs, votre migration est prise en charge et vous pouvez passer à l’étape suivante.

Si vous devez démarrer une mise à niveau pour mettre à niveau votre environnement App Service vers la version de build prise en charge, ce qui peut prendre 8 à 12 heures ou plus en fonction de la taille de votre environnement, exécutez la commande suivante. Exécutez cette commande uniquement si vous ne parvenez pas effectuer l’étape de validation et que vous êtes invité à mettre à niveau votre ASE.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

4. Générer des adresses IP sortantes pour votre nouvelle fonctionnalité App Service Environment v3

Exécutez la commande suivante pour créer des adresses IP sortantes. Cette étape prend environ 15 minutes. N’effectuez pas de mise à l’échelle et n’apportez pas de modifications à votre environnement App Service Environment existant pendant cette période.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01"

Exécutez la commande suivante pour vérifier l’état de cette étape :

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status

Si elle est en cours, vous obtenez l’état Migrating. Après avoir obtenu l’état Ready, exécutez la commande suivante pour voir vos nouvelles adresses IP sortantes. Si les nouvelles adresses IP ne s’affichent pas immédiatement, patientez quelques minutes, puis réessayez.

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5. Mettre à jour les ressources dépendantes avec les nouvelles adresses IP sortantes

En utilisant les nouvelles IP sortantes, mettez à jour vos ressources ou composants réseau pour vérifier que le nouvel environnement fonctionne comme prévu après le démarrage de la migration. Il vous incombe d’effectuer toutes les mises à jour nécessaires. Les nouvelles IP sortantes sont utilisées une fois l’environnement App Service Environment v3 créé durant l’étape de migration. Par exemple, si vous avez un suffixe de domaine personnalisé et un coffre de clés Azure et que vous gérez les restrictions d’accès avec un pare-feu, vous devez mettre à jour le pare-feu du coffre de clés Azure pour autoriser uniquement les nouvelles adresses IP sortantes ou l’ensemble du nouveau sous-réseau.

6. Déléguer votre sous-réseau d’App Service Environment

L’environnement App Service Environment v3 exige que le sous-réseau où il se trouve dispose d’une seule délégation de Microsoft.Web/hostingEnvironments. Les versions précédentes n’exigeaient pas cette délégation. Vous devez vérifier que votre sous-réseau est délégué correctement et mettre à jour la délégation (si nécessaire) avant de procéder à la migration. Vous pouvez mettre à jour la délégation en exécutant la commande suivante ou en accédant au sous-réseau dans le portail Azure.

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

7. Vérifier qu’il n’existe aucun verrou sur le réseau virtuel

Les verrous de réseau virtuel bloquent les opérations de plateforme pendant la migration. Si votre réseau virtuel a des verrous, vous devez les supprimer avant la migration. Si nécessaire, vous pouvez rajouter les verrous une fois la migration terminée.

Utilisez la commande suivante pour vérifier si votre réseau virtuel dispose de verrous :

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Supprimez les verrous existants à l’aide de la commande suivante :

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

Pour connaître les commandes associées pour vérifier si votre abonnement ou groupe de ressources dispose de verrous, consultez la référence Azure CLI pour les verrous.

8. Préparer vos configurations

Si votre environnement App Service Environment existant utilise un suffixe de domaine personnalisé, vous devez en configurer un pour votre nouvelle ressource App Service Environment v3 pendant le processus de migration. La migration échoue si vous ne configurez pas de suffixe de domaine personnalisé alors que vous en utilisez un actuellement. Pour plus d’informations sur les suffixes de domaine personnalisé App Service Environment v3, notamment les exigences, les instructions pas à pas et les bonnes pratiques, consultez Suffixe de domaine personnalisé pour les environnements App Service Environment.

Remarque

Si vous configurez un suffixe de domaine personnalisé, lors de l’ajout des autorisations réseau sur votre instance Azure Key Vault, vérifiez que votre coffre de clés autorise l’accès depuis le nouveau sous-réseau de votre App Service Environment v3. Si vous accédez à votre coffre de clés à l’aide d’un point de terminaison privé, assurez-vous d’avoir correctement configuré l’accès privé avec le nouveau sous-réseau. Vous rencontrez un temps d’arrêt si vous ne parvenez pas à définir correctement cet accès avant la migration.

Votre nouvel environnement App Service v3 peut être redondant interzone si votre environnement existant se trouve dans une région qui prend en charge la redondance interzone. Vous pouvez configurer la redondance de zone en définissant la propriété zoneRedundant sur true. La redondance interzone est une configuration facultative. Cette configuration peut être définie seulement pendant la création de votre environnement App Service v3 et ne peut pas être supprimée par la suite.

Pour définir ces configurations, notamment l’identification du sous-réseau que vous avez sélectionné précédemment, créez un fichier appelé parameters.json avec les détails suivants en fonction de votre scénario. Veillez à utiliser le nouveau sous-réseau sélectionné pour votre nouvelle fonctionnalité App Service Environment v3. N’ajoutez pas les propriétés de suffixe de domaine personnalisé si cette fonctionnalité ne s’applique pas à votre migration. Attention à la valeur de la propriété zoneRedundant et définissez-la en fonction de vos besoins de résilience.

Si vous migrez sans suffixe de domaine personnalisé, utilisez ce code :

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

Si vous utilisez une identité managée affectée par l’utilisateur pour votre configuration de suffixe de domaine personnalisé, utilisez ce code :

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

Si vous utilisez une identité managée affectée par le système pour votre configuration de suffixe de domaine personnalisé, utilisez ce code :

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

9. Migrer vers App Service Environment v3 et vérifier l’état

Une fois toutes les étapes précédentes effectuées, vous pouvez démarrer la migration. Assurez-vous de bien comprendre les implications de la migration.

L’achèvement de cette étape prend entre trois et six heures. Pendant ce temps, il n’y a aucun temps d’arrêt d’application si vous avez suivi les étapes précédentes. La mise à l’échelle, les déploiements et les modifications apportées à votre environnement App Service Environment existant sont bloqués pendant cette étape.

Remarque

En raison d’un bogue connu, les travaux web risquent de ne pas démarrer pendant l’étape de déploiement hybride. Si vous utilisez des travaux web, ce bogue risque d’entraîner des problèmes/temps d’arrêt au niveau des applications. Ouvrez une demande de support si vous avez des questions ou des préoccupations concernant ce problème.

Exécutez la commande suivante pour démarrer la migration :

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

Exécutez la commande suivante pour vérifier l’état de votre migration :

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Une fois que vous obtenez l’état MigrationPendingDnsChange, la migration est effectuée et vous avez une ressource App Service Environment v3. Vos applications s’exécutent désormais dans votre nouvel environnement et dans votre ancien environnement.

Obtenez les détails de votre nouvel environnement en exécutant la commande suivante :

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Important

Pendant la migration et pendant l’étape MigrationPendingDnsChange, le portail Azure affiche des informations incorrectes sur votre App Service Environment et vos applications. Utilisez l’interface de ligne de commande Azure pour vérifier l’état de votre migration. Si vous avez des questions sur l’état de votre migration ou de vos applications, contactez le support technique.

Remarque

Si votre migration inclut un suffixe de domaine personnalisé, une fois la migration terminée, la configuration de suffixe du domaine personnalisé peut sembler altérée en raison d’un bogue connu. Votre environnement App Service devrait toujours fonctionner comme prévu. L’état altéré devrait se résoudre dans un délai de six à huit heures. Si la configuration est toujours altérée au bout de huit heures ou si le suffixe de votre domaine personnalisé ne fonctionne pas, contactez le support.

Capture d’écran d’un exemple de configuration de suffixe de domaine personnalisé altérée.

10. Obtenir les adresses IP entrantes pour votre nouvel App Service Environment v3 et mettre à jour les ressources dépendantes

À ce stade du processus de migration, vous disposez de deux ensembles de front-ends App Service Environment, capables de gérer le trafic d’application. Votre DNS n’ayant pas changé, le trafic est envoyé par défaut vers les anciens front-ends App Service Environment. Vous devez mettre à jour toute les ressources dépendantes afin d’utiliser la nouvelle adresse IP entrante pour votre nouvelle fonctionnalité App Service Environment v3. Pour les fonctionnalités App Service Environment en interne (ILB), vous devez mettre à jour vos zones DNS privées pour qu’elles pointent vers la nouvelle adresse IP entrante.

Vous pouvez obtenir l’adresse IP entrante de votre nouvelle fonctionnalité App Service Environment v3 en exécutant la commande suivante qui correspond à votre type d’équilibreur de charge App Service Environment. Il vous incombe d’effectuer toutes les mises à jour nécessaires.

Pour les environnements App Service ILB, obtenez l’adresse IP entrante privée en exécutant la commande suivante :

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

Pour les environnements App Service ELB, obtenez l’adresse IP entrante publique en exécutant la commande suivante :

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

Important

Si votre migration inclut un suffixe de domaine personnalisé, le comportement du nom d’hôte par défaut pour App Service Environment v3 est différent de celui d’App Service Environment v2. Pour App Service Environment v3, le nom d’hôte par défaut utilise toujours le suffixe de domaine par défaut et est au format NOM_APP.NOM_ASE.appserviceenvironment.net. Passez en revue toutes vos ressources dépendantes, telles que App Gateway, qui utilisent les noms d’hôte de vos applications pour vous assurer qu’elles sont mises à jour pour prendre en compte ce comportement. Pour plus d’informations sur les différences de fonctionnalités App Service Environment entre les différentes versions, consultez l’article Comparaison des versions d’App Service Environment.

11. Rediriger le trafic client, valider votre ASE v3 et effectuer la migration

Cette étape constitue votre opportunité de tester et de valider votre nouvelle fonctionnalité App Service Environment v3.

Important

Vous avez 14 jours pour effectuer cette étape. Après 14 jours, la plateforme effectue automatiquement la migration et supprime votre ancien environnement. Si vous avez besoin de plus de temps, vous pouvez ouvrir un cas de support pour discuter de vos options.

Une fois que vous avez vérifié que vos applications fonctionnent comme prévu, vous pouvez finaliser la migration en exécutant la commande suivante. Cette commande supprime également votre ancien environnement.

Si vous détectez des problèmes ou décidez à ce stade que vous ne souhaitez plus poursuivre la migration, contactez le support afin de discuter de vos options. N’exécutez pas la commande de modification DNS, car cette commande termine la migration.

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

Exécutez la commande suivante pour vérifier l’état de cette étape :

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

Pendant cette étape, vous obtenez l’état CompletingMigration. Quand vous obtenez l’état MigrationCompleted, l’étape de redirection du trafic est effectuée et votre migration est terminée.

Sources courantes de problèmes lors de la migration à l'aide de la fonctionnalité de migration côte à côte

Voici des exemples de sources courantes de problèmes rencontrés par les clients lors de la migration à l’aide de la fonctionnalité de migration côte à côte. Vous devez examiner ces zones pour vous assurer que vous ne subirez pas de temps d’arrêt ou de pannes de service pendant ou après le processus de migration.

  • Azure Key Vault doit autoriser le trafic provenant des nouvelles adresses IP/sous-réseaux sortants.
  • Les deux sous-réseaux doivent pouvoir communiquer entre eux dans les deux sens. Les clients autorisent généralement le trafic de l’ancien vers le nouveau sous-réseau, mais oublient d’autoriser le trafic du nouveau vers l’ancien sous-réseau.
  • App Gateway doit être mis à jour avec les nouvelles adresses IP.
  • Les enregistrements DNS doivent être mis à jour avec les nouvelles adresses IP.
  • Si vous avez codé en dur des adresses IP dans vos applications, vous devez les mettre à jour avec les nouvelles adresses IP.
  • Les tables de routage doivent être mises à jour avec tous les nouveaux itinéraires.

Tarification

La migration de votre environnement App Service Environment ne génère pas de frais. Toutefois, vous êtes facturé pour votre App Service Environnement v2 et votre nouvel App Service Environment v3 une fois que vous avez démarré le processus de migration. Vous cessez d’être facturé pour votre ancien environnement App Service Environment v2 une fois que vous avez effectué l’étape finale de migration au cours de laquelle l’ancien environnement est supprimé. Vous devez effectuer votre validation le plus rapidement possible pour empêcher l’accumulation de frais excédentaires. Pour plus d’informations sur les tarifs d’App Service Environment v3, consultez les détails de la tarification.

Lorsque vous migrez depuis des versions précédentes vers App Service Environment v3, vous devez envisager des scénarios susceptibles de réduire votre coût mensuel. Envisagez des réservations et des plans d’économies pour réduire davantage vos coûts. Pour plus d’informations sur les opportunités d’économie de coûts, consultez Opportunités d’économie de coûts après la mise à niveau vers App Service Environment v3.

Remarque

En raison des différences entre les niveaux tarifaires isolé et isolé v2, vos applications peuvent être surprovisionnés après la migration, car le niveau v2 isolé a plus de mémoire et de processeur par taille d’instance correspondante. Une fois la migration terminée, vous aurez la possibilité de mettre à l’échelle votre environnement en fonction des besoins. Pour plus d’informations, consultez les détails de la référence SKU.

Réduire vos plans App Service

Les références SKU des plans App Service disponibles pour App Service Environment v3 s’exécutent sur le niveau de service v2 (Iv2) isolé. Le nombre de cœurs et la quantité de RAM sont effectivement doublés à chaque niveau correspondant par rapport au niveau de service isolé. Vos plans App Service sont convertis vers le niveau de service correspondant lors de la migration. Par exemple, vos instances I2 sont converties à I2v2. Alors que I2 a deux cœurs et 7 Go de RAM, I2v2 a quatre cœurs et 16 Go de RAM. Si vous vous attendez à conserver les mêmes exigences de capacité, vous êtes surapprovisionné et vous payez pour du calcul et de la mémoire que vous n’utilisez pas. Dans ce cas, vous pouvez réduire votre instance I2v2 vers I1v2 et avoir un nombre de cœurs et une quantité de RAM similaires à ce que vous aviez avant.

Forum aux questions

  • Qu’en est-il si la migration de mon environnement App Service Environment n’est pas prise en charge actuellement ?
    Vous ne pouvez pas migrer en utilisant la fonctionnalité de migration côte à côte pour le moment. Si vous avez un environnement non pris en charge et que vous souhaitez migrer immédiatement, consultez les options de migration manuelle.
  • Comment choisir l’option de migration qui me convient le mieux ?
    Passez en revue l’arbre de décision du chemin de migration pour déterminer quelle option convient le mieux à votre cas d’usage.
  • Comment savoir si je dois utiliser la fonctionnalité de migration côte à côte ?
    La fonctionnalité de migration côte à côte est idéale pour les clients qui veulent migrer vers App Service Environment v3, mais dont les applications ne peuvent pas subir de temps d’arrêt. Étant donné qu’un nouveau sous-réseau est utilisé pour votre nouvel environnement, il existe des considérations réseau à prendre en compte, y compris les nouvelles adresses IP. Si vous pouvez prendre en charge les temps d’arrêt,consultez la fonctionnalité de migration sur place, ce qui entraîne des modifications de configuration minimales ou les options de migration manuelle. La fonctionnalité de migration sur place crée votre environnement App Service Environment v3 dans le même sous-réseau que votre environnement existant et utilise la même infrastructure réseau.
  • Vais-je subir des temps d’arrêt pendant la migration ?
    La plateforme garantit l’absence de temps d’arrêt durant le processus de migration côte à côte. Toutefois, vos paramètres DNS peuvent entraîner un temps d’arrêt durant l’étape de changement de DNS. Cela peut être dû à des problèmes liés aux paramètres TTL (durée de vie) et de cache, car le trafic est peut-être toujours redirigé vers votre ancien environnement App Service Environment après le changement de DNS. Vous devez passer en revue vos paramètres DNS, vérifier que votre paramètre TTL est faible, et que votre fournisseur DNS prend en charge la propagation rapide.
  • Dois-je effectuer certaines opérations sur mes applications après la migration pour pouvoir les exécuter dans le nouvel environnement App Service Environment ?
    Non. Toutes vos applications qui s’exécutent dans l’ancien environnement sont automatiquement migrées vers le nouvel environnement et s’exécutent comme avant. Aucune entrée utilisateur n’est requise.
  • Que se passe-t-il si mon environnement App Service Environment a un suffixe de domaine personnalisé ?
    La fonctionnalité de migration côte à côte prend en charge ce scénario de migration.
  • Que se passe-t-il si mon environnement App Service Environment est épinglé à une zone ?
    La fonctionnalité de migration côte à côte ne prend pas en charge ce scénario de migration pour le moment. Si vous avez un App Service Environment non pris en charge épinglé à une zone et que vous souhaitez migrer immédiatement, consultez les options de migration manuelle.
  • Que se passe-t-il si mon App Service Environment a des adresses IP SSL ?
    IP SSL n’est pas pris en charge sur App Service Environment v3. Vous devez supprimer toutes les liaisons IP SSL avant d’effectuer une migration en utilisant la fonctionnalité de migration ou de l’une des options manuelles. Si vous envisagez d’utiliser la fonctionnalité de migration côte à côte, une fois que vous avez supprimé toutes les liaisons SSL IP, vous passez cette vérification de validation et vous pouvez effectuer la migration automatisée.
  • Quelles propriétés de mon environnement App Service Environment vont changer ?
    Vous utilisez App Service Environment v3. Veillez donc à consulter les fonctionnalités et les différences de fonctionnalités par rapport aux versions précédentes. Vos adresses IP entrantes et sortantes changent lors de l’utilisation de la fonctionnalité de migration côte à côte. Notez que pour l’environnement App Service Environment avec ELB, il existait auparavant une adresse IP unique pour le trafic entrant et le trafic sortant. Pour App Service Environment v3, ils sont séparés. Pour plus d’informations, consultez Mise en réseau d’App Service Environment v3. Pour une comparaison exhaustive des versions d’App Service Environment, consultez l’article Comparaison de versions d’App Service Environment.
  • Que se passe-t-il si la migration échoue ou qu’un problème inattendu survient pendant la migration ?
    Des équipes de support sont disponibles en cas de problème inattendu. Nous vous recommandons de migrer les environnements de développement avant de toucher les environnements de production pour en savoir plus sur le processus de migration et voir comment il affecte vos charges de travail.
  • Qu’advient-il de mon ancien environnement App Service Environment ?
    Si vous décidez de migrer un environnement App Service Environment en utilisant la fonctionnalité de migration côte à côte, votre ancien environnement est utilisé jusqu’à la dernière étape du processus de migration. Une fois l’étape finale terminée, l’ancien environnement et toutes les applications hébergées dessus sont arrêtées et supprimées. Votre ancien environnement n’est plus accessible. Il est impossible de revenir à l’ancien environnement à ce stade.
  • Que se passe-t-il pour mes ressources App Service Environment v1/v2 après le 31 août 2024 ?
    Après le 31 août 2024, si vous n’avez pas migré vers App Service Environment v3, votre App Service Environment v1/v2 et les applications qui y sont déployées ne seront plus disponibles. App Service Environment v1/v2 est hébergé sur des unités d’échelle App Service s’exécutant sur une architecture Cloud Services (classic) qui sera supprimée le 31 août 2024. Pour cette raison, App Service Environment v1/v2 ne sera plus disponible après cette date. Effectuez une migration vers App Service Environment v3 pour que vos applications restent en cours d’exécution ou pour enregistrer ou sauvegarder des ressources ou des données que vous devez conserver.

Étapes suivantes

Mise en réseau d’App Service Environment v3

Utilisation d’un environnement App Service Environment v3

Suffixe de domaine personnalisé