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 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 en savoir plus sur App Service Environment v3, consultez Vue d’ensemble de App Service Environment v3.

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. En raison de ce processus, il existe une option de restauration si vous devez annuler votre 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

Il est recommandé d’utiliser cette fonctionnalité pour les environnements de développement avant de migrer des environnements de production, afin 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

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 s’affiche si vous tentez une migration redondante interzone, mais que vous n’avez pas créé d’adresses IP redondantes interzone pendant l’étape de génération d’adresses IP. Ouvrez un dossier de support pour engager le support si vous avez besoin d’activer la redondance de zone. 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. Dans certains cas, une mise à niveau est lancée en visitant la page de migration si votre App Service Environment n’est pas sur la build actuelle. 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. InternalLoadBalancingMode doit être modifié manuellement par l’équipe Microsoft. Ouvrez un cas de support pour solliciter la résolution de votre problème. Demandez une mise à jour à InternalLoadBalancingMode pour autoriser la migration.
La migration n’est pas valide. Votre ASE doit être mis à niveau vers la dernière build pour garantir la réussite de la migration. Nous allons mettre à niveau votre ASE maintenant. Réessayez de migrer dans quelques heures une fois la mise à niveau de la plateforme terminée. Votre environnement App Service n'est pas sur la version minimale requise pour la migration. Une mise à niveau est lancée. Votre App Service Environment ne sera pas impactée, mais vous ne pourrez pas mettre à l’échelle ou apporter des modifications à votre App Service Environment tant que la mise à niveau est en cours. Vous ne pourrez pas migrer tant que la mise à niveau n’est pas terminée. Attendez que la mise à niveau se termine, puis migrez.
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. 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 être en mesure de communiquer avec le sous-réseau dans lequel se trouve votre App Service Environment 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.

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.

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 rencontrer un temps d’arrêt après l’étape de migration si vous avez des dépendances avec les adresses IP sortantes et que vous ne parvenez pas à effectuer toutes les mises à jour nécessaires. C’est parce qu’une fois la migration terminée, même si le trafic va toujours à vos front-ends App Service Environment v2, votre calcul sous-jacent est votre nouvelle instance App Service Environment v3.

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.

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.
  • Le calcul sous-jacent de vos applications est déplacé vers la nouvelle instance App Service Environment v3. Vos front-ends App Service Environment v2 continuent de traiter le trafic. Votre ancienne adresse IP entrante reste utilisée.
    • 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, vous disposez désormais d’un App Service Environment v3 avec toutes vos applications.

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 votre nouvel App Service Environment v3 et à terminer la migration. La plateforme effectue cette modification pour vous, mais uniquement lorsque vous la lancez. 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 pour qu’ils pointent vers l’adresse IP de l’équilibreur de charge de votre nouvelle instance App Service Environment v3 et les front-ends créés pendant la migration. Les changements prennent effet en quelques minutes. Si vous rencontrez des problèmes, vérifiez vos paramètres de cache et de 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.

Remarque

Vous avez 14 jours pour effectuer cette étape. Si vous n’effectuez pas cette étape dans les 14 jours, votre migration est automatiquement rétablie en un environnement App Service Environment v2. Si vous avez besoin de plus de 14 jours pour effectuer cette étape, contactez le support technique.

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, vous pouvez rétablir toutes les modifications et revenir à votre ancien App Service Environment v2. Le processus de restauration prend 3 à 6 heures. Aucun temps d’arrêt n’est associé à ce processus. Une fois le processus de restauration terminé, votre ancien App Service Environment est de nouveau en ligne et votre nouvel App Service Environment v3 est supprimé. Vous pouvez ensuite réessayer la migration une fois que vous avez résolu tous les problèmes.

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 arrêtez d’être facturé pour votre ancien App Service Environment v2 lorsque vous effectuez la dernière étape de migration où votre DNS est mis à jour et que 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 ?
    Non, il n’y a pas de temps d’arrêt pendant le processus de migration côte à côte. Vos applications continuent à s’exécuter sur votre App Service Environment existant jusqu’à ce que vous mettiez fin à l’étape finale de la migration où les modifications du DNS sont effectives immédiatement. Une fois l’étape finale terminée, votre ancien App Service Environment est arrêté et supprimé. Votre nouvel App Service Environment v3 est maintenant votre environnement de production.
  • 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. Avec la fonctionnalité de migration côte à côte, vous pouvez rétablir toutes les modifications en cas de problème.
  • 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. Une restauration vers l’ancien environnement n’est pas possible à 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

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

Mise en réseau d’App Service Environment v3

Utilisation d’un environnement App Service Environment v3

Suffixe de domaine personnalisé