Empêcher et résoudre les problèmes causés par une migration automatique d’un App Service Environment

Si vous disposez d’un environnement App Service Environment v1 ou v2 qui a été migré automatiquement vers App Service Environment v3, vous pouvez rencontrer des problèmes avec vos applications ou services. Cet article fournit des conseils sur la façon de résoudre ces problèmes.

Vue d’ensemble

Après le 1er septembre 2024, tous les App Service Environment v1 et v2 peuvent être migrés automatiquement (migrés auto) vers App Service Environment v3 à tout moment donné, sauf indication contraire. La plateforme lance des migrations automatiques, qui sont nécessaires pour vous assurer que votre App Service Environment s’exécute sur une plateforme prise en charge.

Les migrations automatiques sont effectuées à l’aide de la fonctionnalité de migration sur place. Il y a environ une heure de temps d’arrêt pendant le processus de migration. Les adresses IP entrantes et sortantes de votre App Service Environment peuvent changer pendant le processus de migration. Le temps d’arrêt peut être plus long si vous avez des dépendances sur ces adresses IP. Les temps d’arrêt peuvent également être plus longs si vous utilisez des fonctionnalités qui ne sont pas prises en charge dans App Service Environment v3.

Période de grâce

Si vous avez besoin de plus de temps pour effectuer vos migrations, nous pouvons offrir une période de grâce unique de 30 jours. Votre App Service Environment n’est pas migré automatiquement ou supprimé pendant la période de grâce. Lorsque la période de grâce se termine, nous essayons de migrer automatiquement votre App Service Environment. Si la migration automatique n’est pas possible, vos ressources et données d’application associées sont supprimées.

Pour recevoir cette période de grâce, accédez à portail Azure et visitez la page Migration de votre App Service Environment. Si vous avez plusieurs App Service Environments, vous devez reconnaître et recevoir une période de grâce pour chacun de vos environnements qui nécessite plus de temps pour migrer.

Une fois la période de grâce reçues, la bannière située en haut de la page Migration affiche la date de fin de la période de grâce. Vous devrez peut-être actualiser la page pour afficher la bannière mise à jour. La mise à jour de la bannière avec la date peut prendre jusqu’à cinq minutes.

Si vous avez besoin d’un support supplémentaire ou avez des questions, contactez le support Azure à l’aide de l’option Ouvrir le ticket de support dans le portail Azure sur la page Migration. Il est important que vous reconnaissiez et receviez une période de grâce pour chacun de vos environnements qui nécessitent plus de temps pour migrer avant d’ouvrir la demande de support. La période d’accusé de réception et de grâce garantit que vos environnements ne sont pas migrés automatiquement pendant le traitement de la demande de support.

Limitations de la migration automatique

Les migrations automatiques sont effectuées à l’aide de la fonctionnalité de migration sur place. Les limitations suivantes s’appliquent aux migrations automatiques, similaires aux limitations des migrations sur place:

• Le nouvel App Service Environment v3 se trouve dans le sous-réseau existant utilisé pour votre ancien environnement.
• Le nouvel App Service Environment v3 se trouve dans la même région que votre ancien environnement.
• Le nouvel App Service Environment v3 se trouve dans le même groupe de ressources que votre ancien environnement.
• Toutes les ressources conservent les mêmes noms et ID de ressource.
• Les liaisons TLS/SSL basées sur IP ne sont pas prises en charge dans App Service Environment v3. Si vous avez des liaisons TLS/SSL basées sur IP, vous devez les supprimer une fois la migration terminée. Vos applications ne fonctionnent pas tant que vous ne supprimez pas les liaisons.
• App Service Environment v1 dans un réseau virtuel classique n’est pas pris en charge pour la migration. Si vous disposez d’un App Service Environment v1 dans un réseau virtuel classique, vous devez migrer manuellement. Votre App Service Environment est éligible à la suppression à tout moment si vous ne demandez pas de période de grâce de 30 jours.
• La fonctionnalité de migration sur place n’est pas disponible en Chine Est 2 et En Chine Nord 2. La fonctionnalité n’est pas prise en charge, car App Service Environment v3 n’est pas disponible dans ces régions. Par conséquent, la migration automatique n’est pas possible pour les App Service Environments dans ces régions. Si vous disposez d’un App Service Environment dans ces régions, vous devez migrer manuellement vers l’une des régions prises en charge, telles que la Chine Est 3 ou la Chine Nord 3. Votre App Service Environment est éligible à la suppression à tout moment si vous ne demandez pas de période de grâce de 30 jours.

Pour plus d’informations sur les migrations sur place et voir quel processus est suivi lors d’une migration automatique, consultez la Migration vers App Service Environment v3 à l’aide de la fonctionnalité de migration sur place.

Inéligible pour la migration automatique

Il existe deux scénarios où vous risquez d’être inéligible pour la migration automatique. Le premier scénario est si votre environnement actuel se trouve dans une région qui ne prend pas en charge App Service Environment v3. L’autre scénario est que vous disposez d’un App Service Environment v1 dans un réseau virtuel Classique. Si vous n’êtes pas éligible à la migration automatique et que vous ne pouvez jamais migrer automatiquement, le portail affiche un message pour la raison pour laquelle vous n’êtes pas éligible. Vous devez migrer manuellement. Votre App Service Environment est éligible à la suppression à tout moment si vous ne demandez pas de période de grâce de 30 jours.

Dans certains cas, vous pouvez être temporairement bloqué à partir de la migration automatique, mais vous pouvez résoudre le problème de blocage et activer la migration automatique. Par exemple, si vous disposez d’un verrou de ressource sur votre App Service Environment, vous pouvez supprimer le verrou de ressource pour activer la migration automatique. Une migration automatique bloquée par un verrou de ressource, Azure Policy ou une configuration réseau est automatiquement suspendue. Si vous devez annuler l’interruption de votre App Service Environment, ouvrez un ticket de support.

Les erreurs suivantes peuvent s’afficher dans le portail si vous n’êtes pas éligible à la migration automatique :

Que faire si votre App Service Environment est suspendu

Si votre App Service Environment est suspendu, vous avez deux options.

Annuler la migration et effectuer une migration automatique

Si vous souhaitez migrer vous-même, ouvrez un ticket de support à l’aide de l’option dans la page Migration pour voir si nous pouvons annuler l’interruption de votre App Service Environment. Nous ne garantissons pas que nous ne pouvons pas limiter votre environnement.

Resume/unsuspend as App Service Environment v3

Si vous souhaitez accélérer la migration, vous pouvez reprendre/annuler l’interruption de votre environnement en tant que App Service Environment v3. Pour reprendre votre App Service Environment en tant que v3, accédez au portail Azure et visitez la page Migration de votre App Service Environment. Pour reprendre votre environnement en tant que App Service Environment v3, sélectionnez le bouton « Migrer maintenant ». Ce bouton lance le même processus que celui utilisé pour les migrations automatiques. Les limitations, les temps d’arrêt et d’autres considérations sont les mêmes que pour les migrations automatiques. Si vous avez plusieurs App Service Environments, vous devez reprendre chacun de vos environnements suspendus.

Fonctionnalités permettant de limiter les effets des migrations automatiques

Pour limiter l’effet des migrations automatiques, nous avons implémenté les fonctionnalités suivantes à la fonctionnalité de migration automatique.

Conservation des adresses IP sortantes

Auparavant, l’adresse IP sortante de votre App Service Environment a toujours été modifiée pendant le processus de migration. À présent, l’adresse IP sortante de votre App Service Environment peut être conservée pendant le processus de migration. L’adresse IP publique v1/v2 d’App Service Environment peut être conservée et est utilisée comme adresse IP sortante de App Service Environment v3. Nous ne garantissons pas que nous pouvons conserver votre adresse IP sortante. Toutefois, App Service Environment v3 a deux adresses IP sortantes. Si vous disposez d’une configuration de suffixe de domaine personnalisé et que vous vous connectez à Azure Key Vault via l’Internet public, vous devrez peut-être toujours prendre en compte l’autre adresse IP sortante.

Pour les migrations App Service Environment (ILB) d’équilibreur de charge interne, l’adresse IP entrante est toujours conservée. Cette fonctionnalité reste la même pendant la migration automatique.

Pour les migrations de App Service Environment (ELB) de l’équilibreur de charge externe, l’adresse IP entrante change toujours. Cette modification peut vous affecter si vous utilisez des enregistrements A pour pointer vers l’adresse IP entrante de votre App Service Environment. Si vous utilisez des enregistrements A, vous devez mettre à jour les enregistrements A pour qu’ils pointent vers la nouvelle adresse IP entrante une fois le processus de migration terminé. Si vous utilisez des enregistrements CNAME, vous n’avez probablement pas besoin d’apporter de modifications DNS. Si vous avez d’autres dépendances sur l’adresse IP entrante, vous devez les mettre à jour en conséquence.

Compatibilité de la configuration du suffixe de domaine personnalisé App Service Environment v2

Le suffixe de domaine personnalisé sur App Service Environment v3 est implémenté différemment de celui sur App Service Environment v2. Sur App Service Environment v2, le certificat est chargé directement dans l’environnement App Service. De plus, les certificats non-wildcard sont autorisés. Sur App Service Environment v3, le certificat doit être stocké dans Azure Key Vault et l’environnement App Service doit être en mesure d’accéder au coffre de clés. En outre, les certificats non-wildcard ne sont pas autorisés.

Pour réduire l’effet des migrations automatiques, nous avons implémenté un mode de compatibilité limité pour les configurations de suffixe de domaine personnalisé App Service Environment v2 sur App Service Environment v3. Si vous avez une configuration de suffixe de domaine personnalisée sur App Service Environment v2, la configuration est migrée vers App Service Environment v3. Le certificat est chargé dans l’environnement App Service v3 et la configuration est mise à jour pour utiliser le certificat chargé. Ce processus est effectué en tant que mesure temporaire et n’est valide que jusqu’à l’expiration du certificat actuel. Vous devez mettre à jour la configuration pour utiliser Azure Key Vault une fois le processus de migration terminé et avant l’expiration du certificat. Si vous ne mettez pas à jour la configuration, une fois le certificat expiré, le suffixe de domaine personnalisé ne fonctionne pas. Pour plus d’informations, consultez Suffixe de domaine personnalisé sur App Service Environment v3.

Prise en charge de la migration pour les applications avec des liaisons TLS/SSL basées sur IP

Les liaisons TLS/SSL basées sur IP ne sont pas prises en charge dans App Service Environment v3. Auparavant, la fonctionnalité de migration vous permettait uniquement de migrer une fois que vous avez supprimé les liaisons. Pour activer les migrations automatiques, la validation automatique à vérifier pour les liaisons TLS/SSL basées sur IP est supprimée. Si vous avez des liaisons TLS/SSL basées sur IP, vous devez les supprimer une fois la migration terminée. Vos applications ne fonctionnent pas tant que vous ne supprimez pas les liaisons.

Résoudre les problèmes causés par une migration automatique

Voici des problèmes que vous pouvez rencontrer avec vos applications ou services après une migration automatique. Si votre problème n’est pas répertorié ici et que vous avez besoin d’aide, contactez support Azure.

Problème : App Service Environment v3 utilise l’ancienne configuration de suffixe de domaine personnalisé

Si vous avez une configuration de suffixe de domaine personnalisée sur App Service Environment v2, la configuration est migrée vers App Service Environment v3. Le certificat est chargé dans l’environnement App Service v3 et la configuration est mise à jour pour utiliser le certificat chargé. Ce processus est effectué en tant que mesure temporaire et n’est valide que jusqu’à l’expiration du certificat actuel. Nous ne garantissons pas que votre ancienne configuration de suffixe de domaine personnalisé fonctionnera après la migration automatique.

Pour résoudre cette incompatibilité, vous devez mettre à jour la configuration pour utiliser azure Key Vault une fois le processus de migration terminé et avant l’expiration du certificat. Si vous ne mettez pas à jour la configuration, une fois le certificat expiré, le suffixe de domaine personnalisé ne fonctionne pas. Pour mettre à jour la configuration du suffixe de domaine personnalisé, suivez les étapes décrites dans suffixe de domaine personnalisé sur App Service Environment v3.

Problème : les applications sur App Service Environment v3 ont des liaisons TLS/SSL basées sur IP

Les liaisons TLS/SSL basées sur IP ne sont pas prises en charge dans App Service Environment v3. Vous devez supprimer les liaisons une fois la migration terminée. Vos applications ne fonctionnent pas tant que vous ne supprimez pas les liaisons.

Problème : les ressources dépendantes ne sont pas mises à jour pour utiliser la nouvelle adresse IP entrante

Les migrations App Service Environment ILB conservent l’adresse IP entrante. Aucune action n’est donc nécessaire.

Les migrations d’environnement App Service ELB modifient l’adresse IP entrante. Si vous utilisez des enregistrements A pour pointer vers l’adresse IP entrante de votre App Service Environment, vous devez mettre à jour les enregistrements A pour qu’ils pointent vers la nouvelle adresse IP entrante une fois le processus de migration terminé. Si vous utilisez des enregistrements CNAME, vous n’avez probablement pas besoin d’apporter de modifications DNS. Si vous avez d’autres dépendances sur l’adresse IP entrante, vous devez les mettre à jour en conséquence. L’ancienne adresse IP entrante n’est plus valide une fois le processus de migration terminé.

Problème : les ressources dépendantes ne sont pas mises à jour pour utiliser la nouvelle adresse IP entrante

App Service Environment v3 a deux adresses IP sortantes. Une fois le processus de migration terminé, votre adresse IP sortante existante peut être conservée, mais une autre adresse IP sortante est créée. Vous devrez peut-être prendre en compte cette autre nouvelle adresse IP sortante si vous disposez d’une configuration de suffixe de domaine personnalisé et que vous vous connectez à votre Azure Key Vault via l’Internet public. Si votre adresse IP sortante d’origine n’est pas conservée, vous devez également tenir compte de cette modification.

Problème : modification ou incompatibilité des fonctionnalités avec App Service Environment v3

En général, App Service Environment v3 est compatible avec App Service Environment v1 et v2. Il y a cependant quelques différences. Pour voir les différences entre les versions, consultez la comparaison des versions App Service Environment. Si vous utilisez une fonctionnalité qui n’est pas prise en charge ou se comporte différemment sur App Service Environment v3, vous devez mettre à jour vos applications en conséquence.

Les modifications suivantes sont notables dans App Service Environment v3 :

• Les liaisons TLS/SSL basées sur IP ne sont pas prises en charge.
• La configuration du suffixe de domaine personnalisé est différente.
• Le domaine par défaut est toujours conservé même si vous disposez d’un suffixe de domaine personnalisé.
• Les certificats non-wildcard pour le suffixe de domaine personnalisé ne sont pas autorisés.
• App Service Environment v3 a deux adresses IP sortantes.
• Les références SKU disponibles sont différentes tailles.
• Le modèle de tarification est différent.
• Le modèle de mise en réseau est différent.
• La structure de point de terminaison FTPS est différente. L’accès au point de terminaison FTPS à l’aide d’un suffixe de domaine personnalisé n’est pas pris en charge.
• 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.

Tarification

Il n’y a aucun coût associé à la migration automatique de votre App Service Environment. Vous arrêtez 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.

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.

Stratégie de support après la mise hors service pour App Service Environment v1 et v2

L’instruction suivante représente la stratégie de prise en charge d’Azure App Service Environment v1 et v2 à compter du 1er septembre 2024. Elle n’affecte pas vos charges de travail s’exécutant sur App Service Environment v3.

Cette stratégie de support expire à la fin de toute extension ou période de grâce que vous avez reçu l’approbation écrite de Microsoft pour exécuter les services au-delà de la date de mise hors service planifiée. L’échec de la migration à cette date entraîne la mise hors service de tous les App Service Environments Azure v1 et v2 restants, notamment la suppression des applications et des données, la migration automatisée sur place et d’autres procédures de mise hors service.

La stratégie de prise en charge étendue inclut les éléments suivants :

• Depuis le 1er septembre 2024, le contrat de niveau de service (SLA ) n’est plus applicable pour App Service Environment v1 et v2. Grâce à l’utilisation continue du produit au-delà de la date de mise hors service, vous reconnaissez qu’Azure ne s’engage pas sur le contrat SLA de 99,95 % pour l’environnement supprimé.
• Nous nous engageons à maintenir la plateforme et à effectuer vos migrations. Par conséquent, les canaux de support technique (CSS) et PG (Product Group) continueront de gérer les cas de support et les incidents de réponse critique (CRI) de manière commercialement raisonnable. Aucun nouvel investissement en matière de sécurité et de conformité n’est effectué dans App Service Environment v1 et v2.
• App Service continuera à corriger le système d’exploitation et les runtimes de langage conformément aux processus de mise à jour de la plateforme documentés ici.
• App Service continuera à tester et valider les mises à jour d’Azure App Service avant le déploiement et continuera à suivre les procédures de déploiement sécurisées pour les mises à jour de la plateforme.
• App Service continuera à surveiller activement l’empreinte de production d’Azure App Service Environment v1/v2 et continuera à répondre aux problèmes détectés via cette surveillance avec la même urgence que aujourd’hui.
• Microsoft continuera à accepter les cas de support Azure App Service et à résoudre les problèmes d’Azure App Service en temps opportun.
• App Service continuera d’appliquer des correctifs et correctifs logiciels pour les bogues critiques de la plateforme Azure App Service qui peuvent survenir.
• Toutefois, la possibilité d’atténuer efficacement les problèmes qui peuvent provenir de dépendances Azure de niveau inférieur peut être altérée en raison de la mise hors service affectant tous les composants Cloud Services et Azure Service Management (ASM)/RedDog Front End (RDFE).

Nous vous encourageons à effectuer la migration vers Azure App Service Environment v3 dès que possible pour éviter toute interruption de vos services. Notre équipe est disponible pour vous aider dans le processus de migration et répondre à toutes les questions que vous pourriez avoir. Pour plus d’informations sur les étapes de mise hors service et de migration, les ressources disponibles et les avantages de la migration, consultez la documentation produit.

Forum aux questions

• Pourquoi suis-je confronté à des pannes d’application temporaires sur mon App Service Environment v1/v2 ?
  La plateforme Azure prépare la mise hors service des services cloud (classique), qui est l’infrastructure sur laquelle App Service Environment v1 et v2 s’exécutent. Dans le cadre de cette préparation, vous devez vous attendre à des interruptions temporaires et à des interruptions de service. Pour réduire l’effet de ces interruptions, nous vous recommandons de migrer vers App Service Environment v3 dès que possible.
• Pourquoi mon App Service Environment a-t-il été migré automatiquement ?
  App Service Environment v1 et v2 sont supprimés et ne sont plus pris en charge. L’infrastructure de prise en charge pour App Service Environment v1 et v2 est en cours de mise hors service. Pour vous assurer que votre App Service Environment s’exécute sur une plateforme prise en charge, Microsoft lance les migrations automatiques vers App Service Environment v3.
• Pourquoi mes applications ne fonctionnent-elles pas après la migration automatique ?
  Après une migration automatique, vous pouvez rencontrer des problèmes avec vos applications ou services en raison de mises à jour de fonctionnalités ou d’incompatibilités. Pour résoudre ces problèmes, consultez Résoudre les problèmes causés par une migration automatique.
• Quel est le temps d’arrêt pendant le processus de migration automatique ?
  Il y a environ une heure de temps d’arrêt pendant le processus de migration automatique. Les adresses IP entrantes et sortantes de votre App Service Environment peuvent changer pendant le processus de migration. Le temps d’arrêt peut être plus long si vous avez des dépendances sur ces adresses IP. Les temps d’arrêt peuvent également être plus longs si vous utilisez des fonctionnalités qui ne sont pas prises en charge dans App Service Environment v3.
• Est-ce que je serai facturé pour les migrations automatiques ?
  Il n’y a aucun coût associé à la migration automatique de votre App Service Environment. Vous arrêtez 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é.
• Pourquoi mon App Service Environment a-t-il été supprimé ?
  Si la migration automatique n’est pas possible, vos ressources et données d’application associées sont supprimées. Nous vous recommandons vivement d’agir maintenant pour éviter ce scénario. Si vous avez besoin de plus de temps pour effectuer vos migrations, nous pouvons offrir une période de grâce unique de 30 jours. Votre App Service Environment n’est pas supprimé pendant la période de grâce. Lorsque la période de grâce se termine, nous pouvons supprimer votre App Service Environment et toutes les données associées.