Migration vers App Service Environment v3 à l’aide de la fonctionnalité de migration sur place
Remarque
La fonctionnalité de migration décrite dans cet article est utilisée pour la migration automatisée sur place (même sous-réseau) d’App Service Environment v1 et 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 côte à côte, consultez Migrer vers App Service Environment v3 à l’aide de la fonctionnalité de migration côte à côte. 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 sur place automatise votre migration vers App Service Environment v3 en mettant à niveau votre App Service Environment existant dans le même sous-réseau. Cette option de migration est idéale pour les clients qui souhaitent migrer vers App Service Environment v3 avec des modifications minimales apportées à leurs configurations réseau. Vous devez également être en mesure de supporter environ une heure de temps d’arrêt de l’application. Si vous ne pouvez pas prendre en charge les temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou 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 :
Microsoft Azure géré par 21Vianet
- Chine orientale 2
- Chine Nord 2
Les configurations App Service Environment suivantes peuvent être migrées à l’aide de la fonctionnalité de migration sur place. Le tableau fournit la configuration App Service Environment v3 lors de l’utilisation de la fonctionnalité de migration sur place selon votre App Service Environment (ASE) existant. Tous les environnements ASE pris en charge peuvent être migrés vers un App Service Environment v3 redondant interzone à l’aide de la fonctionnalité de migration sur place tant que l’environnement se trouve dans une région qui prend en charge la redondance de zone. Vous pouvez configurer la redondance de zone pendant le processus de migration.
| 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 v1 avec ILB | App Service Environment v3 avec ILB |
| App Service Environment v1 avec ELB | App Service Environment v3 avec ELB |
| App Service Environment v1 avec ILB et un suffixe de domaine personnalisé | App Service Environment v3 avec ILB et un suffixe de domaine personnalisé |
| Environnement App Service Environment v2 épinglé à la zone | App Service Environment v3 avec une configuration facultative de 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.
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.
Limitations de la fonctionnalité de migration sur place
Voici des limitations lors de l’utilisation de la fonctionnalité de migration sur place :
- Votre nouvel App Service Environment v3 se trouve dans le sous-réseau existant utilisé pour votre ancien environnement.
- Vous ne pouvez pas changer la région dans laquelle se trouve votre App Service Environment.
- ELB App Service Environment ne peut pas être migré vers ILB App Service Environment v3 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.
App Service Environment v3 ne prend pas en charge les fonctionnalités suivantes que vous utilisez peut-être avec votre instance App Service Environment v1 ou 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 sur place 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.
- App Service Environment v1 dans un réseau virtuel classique
- App Service Environment v2 avec ELB et des adresses IP SSL
- App Service Environment v1 avec ELB et des adresses IP SSL
- 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 d’un App Service Environment ELB est de 42 caractères
La plateforme App Service évalue votre App Service Environment pour confirmer la prise en charge de la migration sur place. Si votre scénario ne passe pas toutes les vérifications de validation, vous ne pouvez pas migrer à l’aide de la fonctionnalité de migration sur place 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 peut s’afficher :
| 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 ASE dans les réseaux virtuels classiques ne peuvent pas migrer à l’aide de la fonctionnalité de migration sur place. | 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 sur place soit disponible dans votre région. |
| La migration ne peut pas être appelée sur cet ASE. Contactez le support technique pour obtenir de l’aide sur la migration. | Le support doit être impliqué pour la migration de cet App Service Environment. Ce problème est potentiellement dû aux paramètres personnalisés utilisés par cet environnement. | Ouvrez un cas de support pour solliciter la résolution de votre problème. |
| La migration ne peut pas être appelée si SSL IP est activé sur l’un des sites | Vous ne pouvez pas migrer d’environnements ASE comprenant des sites avec IP SSL activé à l’aide de la fonctionnalité de migration. | Supprimez IP SSL de toutes vos applications dans l’environnement ASE pour activer la fonctionnalité de migration. |
| 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 vers ASEv3 n’est pas autorisée pour cet ASE. | Vous ne pouvez pas migrer à l’aide de la fonctionnalité de migration. | Faites la migration en utilisant une des options de migration manuelle. |
| 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. |
<ZoneRedundant><DedicatedHosts><ASEv3/ASE> n’est pas disponible à cet emplacement. |
Cette erreur s’affiche si vous essayez de migrer un environnement App Service Environment dans une région qui ne prend pas en charge l’une de vos fonctionnalités demandées. | Faites la migration en utilisant une des options de migration manuelle si vous voulez migrer immédiatement. Sinon, attendez que la fonctionnalité de migration prenne en charge cette configuration App Service Environment. |
| 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. |
| 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. |
| Votre InternalLoadBalancingMode n’est actuellement pas 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. |
Vue d’ensemble du processus de migration sur place à l’aide de la fonctionnalité de migration
La migration sur place 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 en place pour votre ASE
La plateforme valide que votre ASE peut être migré en utilisant la fonctionnalité de migration en place. 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 en place 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 en place, 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.
Générer des adresses IP pour votre nouvel environnement App Service Environment v3
La plateforme crée la nouvelle adresse IP entrante (si vous migrez un App Service Environment avec ELB) et 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, vous recevez les nouvelles adresses IP utilisées par votre futur App Service Environment v3. Ces nouvelles adresses IP n’ont aucun effet sur votre environnement existant. Les adresses IP utilisées par votre environnement existant continuent d’être utilisées jusqu’à ce que votre environnement existant soit arrêté pendant l’étape de migration.
Mettre à jour les ressources dépendantes avec les nouvelles adresses IP
Vous disposez de la nouvelle adresse sortante par défaut vers les adresses publiques Internet une fois les nouvelles adresses IP créées. Pour préparer la migration, vous pouvez ajuster les pare-feux externes, le routage DNS, les groupes de sécurité réseau et toute autre ressource s’appuyant sur ces adresses IP. Pour l’App Service Environment avec ELB, vous disposez également de la nouvelle adresse IP entrante que vous pouvez utiliser pour configurer de nouveaux points de terminaison avec des services comme Traffic Manager ou Azure Front Door. 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. 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.
Prendre connaissance des changements de taille d’instance
Vos plans App Service sont convertis de la catégorie Isolé à la catégorie Isolé v2 correspondante dans le cadre de la migration. Par exemple, I2 est converti en 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.
Choisir vos configurations d’App Service Environment v3
Votre environnement ASE v3 peut être déployé à travers des zones de disponibilité dans les régions qui le prennent en charge. Cette architecture est appelée redondance de zone. La redondance de zone ne peut être configurée que pendant la création de l’environnement ASE. Si vous souhaitez que votre nouvel environnement ASE v3 soit redondant interzone, activez la configuration pendant le processus de migration. Tout environnement ASE qui utilise la fonctionnalité de migration sur place pour migrer peut être configuré en tant que redondant interzone tant que vous utilisez une région qui prend en charge la redondance de zone pour App Service Environment v3. Si votre environnement existant est dans une région qui ne prend pas en charge la redondance de zone, l’option de configuration est désactivée et vous ne pouvez pas la configurer. La fonctionnalité de migration sur place ne prend pas en charge le changement de régions. Si vous souhaitez utiliser une autre région, choisissez l’une des options de migration manuelle.
Notes
L’activation de la redondance de zone peut entraîner des frais supplémentaires. Pour plus d’informations, consultez le modèle de tarification de redondance de zone.
Si votre App Service Environment existant utilise un suffixe de domaine personnalisé, vous êtes invité à en configurer un pour votre nouvel ASE v3. Vous devez fournir le nom de domaine personnalisé, l’identité managée et le certificat. 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. 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.
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.
La migration nécessite une fenêtre de service de trois à six heures pour les migrations App Service Environment v2 vers v3. Une fenêtre de service allant jusqu’à six heures est requise en fonction de la taille d’environnement pour les migrations de v1 vers v3. La fenêtre du service peut être étendue dans de rares cas où une intervention manuelle de l’équipe de service est nécessaire. Pendant la migration, les configurations de mise à l’échelle et d’environnement sont bloquées et les événements suivants se produisent :
- L’environnement App Service Environment existant est arrêté et remplacé par le nouvel environnement App Service Environment v3.
- Tous les plans App Service figurant dans l’environnement App Service Environment sont convertis de la catégorie Isolé à la catégorie Isolé v2.
- Toutes les applications figurant dans votre environnement App Service Environment sont momentanément indisponibles. Vous devez vous attendre à environ une heure de temps d’arrêt.
- Si vous ne pouvez pas subir de temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou les alternatives de migration.
- Les adresses publiques utilisées par l’App Service Environment sont remplacées par les adresses IP générées au cours de l’étape de génération d’adresses IP.
Les états suivants sont disponibles pendant le processus de migration :
| Statut | Description |
|---|---|
| Validation et préparation de la migration. | La plateforme valide la prise en charge de la migration et effectue les vérifications nécessaires. |
| Déploiement de l’infrastructure App Service Environment v3. | Votre nouvelle infrastructure App Service Environment v3 est en approvisionnement. |
| En attente de l’achèvement de l’infrastructure. | La plateforme valide votre nouvelle infrastructure et effectue les vérifications nécessaires. |
| Configuration de la mise en réseau. La période du temps d’arrêt de la migration a démarré. Les applications ne sont pas accessibles. | La plateforme supprime votre ancienne infrastructure et déplace toutes vos applications vers votre nouvel App Service Environment v3. Vos applications sont indisponibles et n’acceptent pas de trafic. |
| Exécution des validations post-migration. | La plateforme effectue des vérifications nécessaires pour s’assurer de la réussite de la migration. |
| Finalisation de la migration. | La plateforme finalise la migration. |
Comme dans l’étape de génération d’adresses IP, vous ne pouvez pas mettre à l’échelle ni modifier votre App Service Environment, ni y déployer des applications au cours de ce processus. Une fois la migration terminée, les applications qui figuraient dans l’ancien App Service Environment s’exécutent dans le nouvel App Service Environment v3.
Utiliser la fonctionnalité de migration sur place
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 pour comprendre la chronologie du processus, ainsi que l’emplacement et le moment où vous devez vous impliquez. Passez également en revue les FAQ qui peuvent répondre à certaines de vos questions.
Vérifiez qu’il n’y a aucun verrou sur votre réseau virtuel, ressource, groupe de ressources ou 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.
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.
Nous vous recommandons d’utiliser le portail Azure pour l’expérience de migration sur place. Si vous décidez d’utiliser Azure CLI pour effectuer la migration, vous devez suivre 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 conventions PowerShell et les caractères d’échappement.
1. 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)
2. 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 et si la version de sa build est prise en charge pour la migration.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"
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 ASE vers la version de build prise en charge, 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}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"
3. Générer des adresses IP pour votre nouvel ressource App Service Environment v3
Exécutez la commande suivante pour créer les nouvelles adresses IP. 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}/migrate?api-version=2021-02-01&phase=premigration"
Exécutez la commande suivante pour vérifier l’état de cette étape :
az rest --method get --uri "${ASE_ID}?api-version=2021-02-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 IP. 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=2021-02-01"
4. Mettre à jour les ressources dépendantes avec les nouvelles adresses IP
En utilisant les nouvelles IP, mettez à jour les ressources et les composants réseau pour que votre nouvel environnement fonctionne comme prévu après la migration. Il vous incombe d’effectuer toutes les mises à jour nécessaires.
5. Déléguer votre sous-réseau 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
6. Vérifiez qu’il n’y a pas de verrous 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.
7. Préparer vos configurations
Vous pouvez rendre votre nouvelle ressource App Service Environment v3 redondante 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.
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. La migration échoue également si vous tentez d’ajouter un suffixe de domaine personnalisé pendant la migration vers un environnement qui n’en a pas. 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, assurez-vous que votre coffre de clés autorise l’accès à partir des nouvelles adresses IP sortantes de votre App Service Environment qui ont été générées à l’étape 3. Si vous accédez à votre coffre de clés à l’aide d’un point de terminaison privé, vérifiez que vous avez configuré correctement l’accès privé avec le nouveau sous-réseau.
Si votre migration n’a pas de suffixe de domaine personnalisé et que vous n’activez pas la redondance interzone, vous pouvez passer à la migration.
Pour définir ces configurations, créez un fichier appelé parameters.json avec les détails suivants en fonction de votre scénario. N’ajoutez pas les propriétés de suffixe de domaine personnalisé si cette fonctionnalité ne s’applique pas à votre migration. Faites attention à la valeur de la propriété zoneRedundant, car cette configuration est irréversible après la migration. Définissez la valeur de la propriété kind est définie en fonction de la version existante de votre environnement App Service. Les valeurs possibles pour la propriété kind sont ASEV1 et ASEV2.
Si vous migrez sans suffixe de domaine personnalisé et que vous activez la redondance de zone, utilisez ce code :
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true
}
}
Si vous utilisez une identité managée affectée par l’utilisateur pour votre configuration de suffixe de domaine personnalisé et que vous activez la redondance de zone, utilisez ce code :
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true,
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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é et que vous n’activez pas la redondance de zone, utilisez ce code :
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
8. 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.
Cette étape prend de trois à six heures pour les migrations v2 vers v3 et jusqu’à six heures pour les migrations v1 vers v3, en fonction de la taille de l’environnement. Pendant ce temps, comptez environ une heure de temps d’arrêt de l’application. La mise à l’échelle, les déploiements et les modifications apportées à votre environnement App Service Environment existant sont bloqués pendant cette étape.
Ajoutez le paramètre body dans la commande suivante si vous activez la redondance de zone et/ou configurez un suffixe de domaine personnalisé. Si aucune de ces configurations ne s’applique à votre migration, vous pouvez supprimer le paramètre de la commande.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json
Exécutez les commandes suivantes pour vérifier l’état détaillé de votre migration. Pour obtenir des informations sur les états, consultez les descriptions des états de la migration.
La première commande obtient l’ID d’opération pour la migration. Copiez la valeur de la propriété ID.
az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"
Remplacez l’espace réservé de l’ID d’opération dans la commande suivante par la valeur copiée. Cette commande renvoie l’état détaillé de votre migration. Vous pouvez exécuter cette commande aussi souvent que nécessaire pour obtenir le dernier état.
az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"
Une fois que vous obtenez l’état Ready, 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.
Obtenez des informations détaillées sur votre nouvel environnement en exécutant la commande suivante ou en accédant au portail Azure.
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
1. Confirmer que la migration est prise en charge
Dans le portail Azure, accédez à la page Migration de l’environnement App Service Environment que vous migrez. Pour accéder à la page de Migration, sélectionnez la bannière en haut de la page Vue d’ensemble de votre environnement App Service Environment ou sélectionnez l’élément Migration sur le menu gauche.
Sélectionnez l’option de migration « Sur place » pour démarrer le processus de migration sur place. Si vous sélectionnez l’option de migration côte à côte, vous êtes redirigé vers la documentation de ce processus de migration. Ne sélectionnez pas l’option de migration côte à côte si vous souhaitez utiliser la fonctionnalité de migration sur place.
Sur la page Migration, la plateforme vérifie si la migration est prise en charge pour votre environnement App Service Environment. Sélectionnez Valider, puis confirmez que vous souhaitez poursuivre la validation. Le processus de validation prend généralement quelques secondes.
Si votre environnement n’est pas pris en charge pour la migration, une bannière s’affiche en haut de la page et inclut un message d’erreur avec un motif. Pour obtenir des descriptions des messages d’erreur que vous pouvez voir si vous n’êtes pas éligible à la migration, consultez la section Résolution des problèmes.
Si vous devez démarrer une mise à niveau pour mettre à niveau votre environnement App Service vers la version de build prise en charge, vous êtes invité à démarrer la mise à niveau, ce qui peut prendre 8 à 12 heures ou plus en fonction de la taille de votre environnement. Sélectionnez Mettre à niveau pour commencer la mise à niveau. Une fois la mise à niveau terminée, vous passez la validation et vous pouvez utiliser la fonctionnalité de migration pour démarrer votre migration.
Si la migration est prise en charge pour votre App Service Environment, passez à l’étape suivante du processus. La page Migration vous guide tout au long des étapes à suivre pour réaliser la migration.
2. Générer des adresses IP pour votre nouvel ressource App Service Environment v3
Sous Obtenir de nouvelles adresses IP, confirmez que vous comprenez les implications et sélectionnez le bouton Démarrer. Cette étape prend environ 15 minutes. Vous ne pouvez pas effectuer de mise à l’échelle ou apporter des modifications à votre environnement App Service Environment existant pendant cette période.
3. Mettre à jour les ressources dépendantes avec les nouvelles adresses IP
À l’issue de l’étape précédente, les adresses IP de votre nouvel environnement App Service Environment v3 s’affichent. Avec ces nouvelles adresses IP, mettez à jour les ressources et les composants réseau pour vous assurer que votre nouvel environnement fonctionne comme prévu une fois que la migration est réalisée. Il vous incombe d’effectuer toutes les mises à jour nécessaires.
4. Déléguer votre sous-réseau 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. Le portail affiche un lien vers votre sous-réseau, afin que vous puissiez le confirmer et le mettre à jour le cas échéant.
5. Confirmez les changements de taille d’instance
Sélectionnez le bouton Confirmer pour confirmer que vous comprenez que vos plans App Service sont convertis du niveau Isolé au niveau Isolé v2 correspondant dans le cadre de la migration.
6. Vérifiez que le réseau virtuel n’a pas de verrous
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. Pour plus d’informations sur la façon de vérifier si votre abonnement ou groupe de ressources a des verrous, consultez Configurer les verrous.
7. Choisissez vos configurations
Vous pouvez rendre votre nouvelle ressource App Service Environment v3 redondante interzone si votre environnement existant se trouve dans une région qui prend en charge la redondance interzone.
Cochez la case Activé si vous souhaitez configurer la redondance de zone.
Si votre environnement est dans une région qui ne prend pas en charge la redondance de zone, la case est décochée. Si vous avez besoin d’une ressource App Service Environment v3 redondant interzone, utilisez l’une des options de migration manuelles et créez la ressource dans l’une des régions prenant en charge la redondance de zone.
Si votre environnement App Service Environment existant utilise un suffixe de domaine personnalisé, vous devez en configurer un pour votre nouvel environnement App Service v3. Les options de configuration du suffixe de domaine personnalisé s’affichent si cette situation s’applique à votre cas. Vous ne pouvez pas lancer la migration tant que vous ne fournissez pas les informations nécessaires.
Si vous voulez utiliser un suffixe de domaine personnalisé, mais que vous n’en avez pas un actuellement configuré, vous pouvez le configurer une fois la migration terminée. 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, assurez-vous que votre coffre de clés autorise l’accès à partir des nouvelles adresses IP sortantes de votre App Service Environment qui ont été générées à l’étape 2. Si vous accédez à votre coffre de clés à l’aide d’un point de terminaison privé, vérifiez que vous avez configuré correctement l’accès privé avec le nouveau sous-réseau.
Une fois que vous avez ajouté les détails pour le suffixe de domaine personnalisé, le bouton Migrer est disponible.
8. Migrer vers App Service Environment v3
Une fois toutes les étapes précédentes effectuées, vous pouvez démarrer la migration. Veillez à bien comprendre les implications de la migration, notamment ce qui se passe pendant cette période.
Cette étape prend de trois à six heures pour les migrations v2 vers v3 et jusqu’à six heures pour les migrations v1 vers v3, en fonction de la taille de l’environnement. La mise à l’échelle et les modifications apportées à votre environnement App Service Environment existant sont bloquées au cours de cette étape.
Remarque
Dans de rares cas, vous pouvez voir une notification sur le portail indiquant « Échec de la migration vers App Service Environment v3 » après avoir démarré la migration. Il existe un bug connu qui pourrait déclencher cette notification même si la migration progresse. Consultez le journal d’activité de l’environnement App Service pour déterminer la validité de ce message d’erreur. Dans la plupart des cas, l’actualisation de la page résout le problème et le message d’erreur disparaît. Si le message d’erreur persiste, contactez le support pour obtenir de l’aide.
À ce moment, les états détaillés de migration sont uniquement disponibles lors de l’utilisation de l’interface de ligne de commande Azure. Pour obtenir plus d’informations, consultez la section Azure CLI pour migrer vers App Service Environment v3. Vous pouvez vérifier l’état de la migration à l’aide de la CLI même si vous utilisez le Portail pour effectuer la migration.
Une fois la migration terminée, vous avez une ressource App Service Environment v3 et toutes vos applications s’exécutent dans votre nouvel environnement. Vous pouvez vérifier la version de l’environnement en consultant la page Configuration de votre environnement App Service Environment.
Si votre migration comprend un suffixe de domaine personnalisé, le domaine ne s’affiche plus dans App Service Environment v3, contrairement à App Service Environment v1/v2 où il s’affichait dans la section Éléments principaux de la page Vue d’ensemble du portail. Au lieu de cela, pour App Service Environment v3, accédez à la page Suffixe de domaine personnalisé pour confirmer que votre suffixe de domaine personnalisé est configuré correctement. Vous pouvez également supprimer la configuration si vous n’en avez plus besoin ou en configurer un si vous n’en avez pas.
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.
Tarification
La migration de votre environnement App Service Environment ne génère pas de frais. Lorsque vous utilisez la fonctionnalité de migration sur place, vous cessez d’être facturé pour votre App Service Environment précédent dès qu’il s’arrête pendant le processus de migration. Vous commencez à être facturé pour votre nouveau App Service Environnement v3 dès qu’il est déployé. 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 de la conversion des plans App Service de Isolé vers Isolé v2, vos applications peuvent être surprovisionnées après la migration, car le niveau Isolé v2 offre 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 sur place 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 sur place ?
La fonctionnalité de migration sur place est idéale pour les clients qui souhaitent migrer vers App Service Environment v3 avec des modifications minimales apportées à leurs configurations réseau et peuvent prendre en charge environ une heure de temps d’arrêt de l’application. Si vous ne pouvez pas prendre en charge les temps d’arrêt, consultez la fonctionnalité de migration côte à côte 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. Vous devrez peut-être tenir compte des changements d'adresses IP entrantes et sortantes si vous avez des dépendances sur ces adresses IP spécifiques. - Vais-je subir des temps d’arrêt pendant la migration ?
Oui, vous devez vous attendre à environ une heure de temps d’arrêt pendant la fenêtre de service de trois à six heures au cours de l’étape de migration, alors adaptez votre planification en conséquence. Si vous disposez d’un autre App Service Environment vers lequel vous pouvez diriger le trafic pendant la migration à l’aide de la fonctionnalité de migration sur place, vous pouvez éliminer les temps d’arrêt de l’application. Si vous n’avez pas d’autre App Service Environment et que vous ne pouvez pas prendre en charge les temps d’arrêt, consultez la fonctionnalité de migration côte à côte ou les options de migration manuelle. - 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 sur place prend en charge ce scénario de migration. - Que se passe-t-il si mon environnement App Service Environment est épinglé à une zone ?
App Service Environment v2 épinglé à une zone est maintenant un scénario pris en charge pour la migration au moyen de la fonctionnalité de migration. App Service Environment v3 ne prend pas en charge l’épinglage de zone. Quand vous migrez vers App Service Environment v3, vous pouvez choisir de configurer ou non la redondance de zone. - 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 sur place, une fois que vous avez supprimé toutes les liaisons IP SSL, vous allez effectuer cette vérification de validation et pouvoir 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. Pour App Service Environment avec ILB, vous conservez la même adresse IP ILB. Pour l’App Service Environment accessible via Internet, l’adresse IP publique et l’adresse IP sortante sont modifiées. 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. Vous devez 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 à l’aide de la fonctionnalité de migration sur place, l’ancien environnement est arrêté, supprimé, tandis que toutes vos applications sont migrées vers un nouvel environnement. Votre ancien environnement n’est plus accessible. Une restauration vers l’ancien environnement n’est pas possible. - 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.