Migrer vers App Service Environment v3

Article
03/06/2024

Remarque

Il existe deux fonctionnalités de migration automatisées disponibles pour vous permettre de mettre à niveau vers App Service Environment v3. Pour découvrir plus d’informations sur ces fonctionnalités et vous aider à déterminer l’option de migration appropriée, consultez Arbre de décision du chemin de migration. Envisagez l’une des options automatisées pour bénéficier d’un chemin d’accès plus rapide vers App Service Environment v3.

Si vous utilisez actuellement App Service Environment v1 ou v2, vous avez la possibilité de migrer vos charges de travail vers App Service Environment v3. App Service Environment v3 présente des avantages et des différences de fonctionnalités permettant d’améliorer la prise en charge de vos charges de travail et de réduire les coûts globaux. Envisagez d’utiliser les fonctionnalités de migration automatisées si votre environnement répond aux critères décrits dans l’arbre de décision du chemin de migration.

Si votre fonctionnalité App Service Environment n’est pas prise en charge pour les fonctionnalités de migration, vous devez utiliser l’une des méthodes manuelles de migration vers App Service Environment v3.

Prérequis

Scénario : Vous disposez d’une application qui s’exécute sur App Service Environment v1 ou App Service Environment v2, et vous avez besoin que cette application s’exécute sur App Service Environment v3.

Pour toute méthode de migration qui n’utilise pas les fonctionnalités de migration, vous devez créer la ressource App service Environment v3 et un nouveau sous-réseau en utilisant la méthode de votre choix.

Les différences de mise en réseau entre App Service Environment v1/v2 et App Service Environment v3 impliquent de nouvelles adresses IP (et des adresses IP supplémentaires pour les environnements accessibles via Internet). Vous devez mettre à jour les infrastructures qui s’appuient sur ces adresses IP. Veillez à prendre en compte les modifications de dépendance entrantes, telles que le port Azure Load Balancer.

Plusieurs environnements App Service Environment ne peuvent pas exister dans un même sous-réseau. Si vous devez utiliser votre sous-réseau existant pour votre nouvelle ressource App Service Environment v3, vous devez supprimer la version existante d’App Service Environment avant d’en créer une nouvelle. Pour ce scénario, nous vous recommandons de sauvegarder vos applications, puis de les restaurer dans le nouvel environnement après la création et la configuration de l’environnement. Ce processus entraîne un temps d’arrêt de l’application en raison du temps nécessaire pour :

Supprimer l’ancienne version de l’environnement.
Créer la ressource App Service Environment v3.
Configurer toutes les ressources connectées et d’infrastructure pour qu’elles fonctionnent avec le nouvel environnement.
Déployer vos applications sur le nouvel environnement.

Check-list avant la migration des applications

Créer une ressource App Service Environment v3.
Mettez à jour les dépendances réseau avec les adresses IP associées au nouvel environnement.
Planifiez les temps d’arrêt (le cas échéant).
Décidez d’un processus de recréation de vos applications dans votre nouvel environnement.

Dimensionner et mettre à l’échelle l’environnement

App Service Environment v3 utilise des plans Azure App Service Isolé v2 qui sont tarifés et dimensionnés différemment de ceux des plans Isolé. Passez en revue les détails de tarification pour comprendre comment votre nouvel environnement doit être dimensionné et mis à l’échelle pour garantir une capacité appropriée. Il n’existe aucune différence dans la façon dont vous créez des plans App Service pour App Service Environment v3 par rapport aux versions précédentes.

Évaluer la sauvegarde et la restauration

Vous pouvez utiliser la fonctionnalité de sauvegarde et de restauration pour conserver la configuration de vos applications, le contenu des fichiers et la base de données connectés à votre application lorsque vous migrez vers le nouvel environnement.

Vous devez configurer des sauvegardes personnalisées pour vos applications afin de les restaurer dans App Service Environment v3. La sauvegarde automatique ne prend pas en charge la restauration sur différentes versions d’App Service Environment. Pour plus d’informations sur les sauvegardes personnalisées, consultez Sauvegardes automatiques et personnalisées. Capture d’écran montrant les options pour la configuration de sauvegardes personnalisées pour une application App Service.

Vous pouvez sélectionner une sauvegarde personnalisée et la restaurer sur App Service dans votre ressource App Service Environment v3. Vous devez créer le plan App Service que vous allez restaurer avant de restaurer l’application. Vous pouvez choisir de restaurer la sauvegarde à l’emplacement de production, un emplacement existant ou un nouvel emplacement que vous créez pendant le processus de restauration.

Capture d’écran montrant comment utiliser une sauvegarde pour restaurer une application App Service dans l’environnement App Service Environment v3.

Avantages	Limites
Rapide – doit prendre seulement 5 à 10 minutes par application.	La prise en charge limitée à certains types de base de données.
Vous pouvez restaurer plusieurs applications en même temps. (Vous devez configurer la restauration pour chaque application individuellement.)	L’ancien et le nouvel environnement, ainsi que les ressources de prise en charge (par exemple, les applications, les bases de données, les comptes de stockage et les conteneurs) doivent tous se trouver dans le même abonnement.
Les bases de données MySQL in-app sont automatiquement sauvegardées sans aucune configuration.	Les sauvegardes peuvent contenir jusqu’à 10 Go de contenu d’applications et de bases de données. Jusqu’à 4 Go de ce contenu peuvent constituer la sauvegarde de la base de données. Une erreur se produit si la taille de la sauvegarde dépasse cette limite.
Vous pouvez restaurer l’application à un instantané d’un état précédent.	L’utilisation d’un compte de stockage avec pare-feu comme destination de vos sauvegardes n’est pas prise en charge.
Vous pouvez vous intégrer à Azure Traffic Manager et à Azure Application Gateway pour répartir le trafic entre les anciens et les nouveaux environnements.	L’utilisation d’un compte de stockage avec points de terminaison privés pour la sauvegarde et la restauration n’est pas prise en charge.
Vous pouvez créer des applications web vides comme destination de restauration dans votre nouvel environnement avant de lancer la restauration, afin d’accélérer le processus.	Seuls les sauvegardes personnalisées sont prises en charge.

Cloner votre application vers App Service Environment v3

Le clonage de vos applications est une autre fonctionnalité que vous pouvez utiliser pour placer vos applications Windows dans App Service Environment v3. Les limitations pour le clonage d’applications sont identiques à celles de la fonctionnalité de sauvegarde d’App Service. Pour plus d’informations, consultez Sauvegarder une application dans Azure App Service.

Remarque

Le clonage d’applications est pris en charge uniquement pour les plans App Service sur Windows.

Nous recommandons cette solution pour les utilisateurs qui utilisent App Service sur Windows et qui ne peuvent pas migrer à l’aide de la fonctionnalité de migration. Vous devez configurer votre nouvelle ressource App Service Environment v3 avant de cloner des applications. Le clonage d’une application peut prendre jusqu’à 30 minutes.

Pour cloner une application à l’aide de PowerShell, consultez les instructions.

Pour cloner une application à l’aide du Portail Azure :

Dans le Portail Azure, accédez à votre plan App Service existant. Sous Outils de développement, sélectionnez Cloner une application.
Renseignez les champs obligatoires à l’aide des détails relatifs à votre nouvelle ressource App Service Environment v3 :
1. Pour Groupe de ressources, sélectionnez un groupe de ressources existant ou créez-en un.
2. Pour Nom, donnez un nom à votre application. Ce nom peut être identique à celui de l’ancienne application, mais l’URL par défaut du site pour le nouvel environnement sera différente. Vous devez mettre à jour les ressources DNS ou connectées personnalisées pour qu’elles pointent vers la nouvelle URL.
3. Pour Région, utilisez le nom de votre ressource App Service Environment v3.
4. Si vous souhaitez cloner votre source de déploiement, cochez la case Cloner la source de déploiement.
5. Pour Plan Windows, vous pouvez utiliser un plan App Service existant à partir de votre nouvel environnement si vous en avez déjà créé un, ou vous pouvez créer un nouveau plan. Les plans App Service disponibles dans votre nouvelle ressource App Service Environment v3 s’affichent dans la liste déroulante.
6. Pour Référence SKU et taille, modifiez la mémoire et le processeur en fonction des besoins en utilisant l’une des options Isolé v2 si vous créez un nouveau plan App Service. App Service Environment v3 utilise des plans Isolé v2, qui proposent plus de mémoire et de processeur par taille d’instance correspondante que les plans Isolé. Pour plus d’informations, consultez Détails de tarification d’App Service Environment v3.

Capture d’écran montrant les options pour le clonage d’une application sur App Service Environment v3 à l’aide du portail.

Avantages	Limites
Vous pouvez automatiser le clonage à l’aide de PowerShell.	Pris en charge uniquement pour les plans App Service sur Windows.
Vous pouvez cloner plusieurs applications en même temps. (Le clonage doit être configuré pour chaque application individuellement ou via un script.)	La prise en charge limitée à certains types de base de données.
Vous pouvez vous intégrer à Azure Traffic Manager et à Azure Application Gateway pour répartir le trafic entre les anciens et les nouveaux environnements.	L’ancien et le nouvel environnement, ainsi que les ressources de prise en charge (par exemple, les applications, les bases de données, les comptes de stockage et les conteneurs) doivent tous se trouver dans le même abonnement.

Créer manuellement vos applications dans App Service Environment v3

Si la fonctionnalité de migration ne prend pas en charge vos applications ou si vous préférez opérer manuellement, vous pouvez déployer vos applications en suivant le même processus que celui utilisé pour votre ressource App Service Environment existante.

Vous pouvez exporter des modèles Azure Resource Manager (modèles ARM) de vos applications existantes, des plans App service et de toutes les autres ressources prises en charge, et les déployer dans ou avec votre nouvel environnement. Pour exporter un modèle pour une seule application, accédez à votre plan App Service. Sous Automation, sélectionnez Exporter le modèle.

Capture d'écran de l'option d'exportation d'un modèle dans le volet gauche du Portail Microsoft Azure.

Vous pouvez également exporter des modèles pour plusieurs ressources directement à partir de votre groupe de ressources. Accédez à votre groupe de ressources, sélectionnez les ressources pour lesquelles vous souhaitez un modèle, puis sélectionnez Exporter le modèle.

Capture d’écran de l’option pour l’exportation d’un modèle pour les ressources d’un groupe de ressources.

Les changements initiaux suivants sont nécessaires dans vos modèles ARM pour faire passer vos applications à App Service Environment v3 :

Mettre à jour les paramètres sku d’un plan App Service vers un plan Isolé v2 :

"type": "Microsoft.Web/serverfarms",
"apiVersion": "2021-02-01",
"name": "[parameters('serverfarm_name')]",
"location": "East US",
"sku": {
    "name": "I1v2",
    "tier": "IsolatedV2",
    "size": "I1v2",
    "family": "Iv2",
    "capacity": 1
},

Mettez à jour le paramètre de plan App Service (serverfarm) dans lequel l’application doit être déployée en spécifiant le plan associé à App Service Environment v3.
Mettez à jour le paramètre de profil d’environnement d’hébergement (hostingEnvironmentProfile) en spécifiant le nouvel ID de ressource d’App Service Environment v3.

Une exportation de modèle ARM inclut toutes les propriétés exposées par les fournisseurs de ressources pour les ressources. Supprimez toutes les propriétés non requises, telles que les propriétés qui pointent vers le domaine de l’ancienne application. Par exemple, vous pourriez simplifier la ressource sites à l’aide de l’exemple suivant :

"type": "Microsoft.Web/sites",
"apiVersion": "2021-02-01",
"name": "[parameters('site_name')]",
"location": "East US",
"dependsOn": [
    "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]"
],
"properties": {
    "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('serverfarm_name'))]",
    "siteConfig": {
        "linuxFxVersion": "NODE|14-lts"
     },
    "hostingEnvironmentProfile": {
        "id": "[parameters('hostingEnvironments_externalid')]"
    }
}

D’autres modifications peuvent être nécessaires en fonction de la manière dont vous avez configuré votre application. Par exemple, si vous utilisez des identités managées affectées par le système et les mêmes noms d’application pour vos anciens et nouveaux environnements, vous risquez de rencontrer un conflit. Pour résoudre ce conflit et éviter un temps d’arrêt, vous pouvez utiliser une identité managée affectée par l’utilisateur.

Vous pouvez déployer des modèles ARM à partir du Portail Azure, d’Azure CLI ou de PowerShell.

Migrer manuellement

La fonctionnalité de migration en place automatise la migration vers App Service Environment v3 et transfère toutes vos applications vers le nouvel environnement. Il y a environ une heure de temps d’arrêt pendant cette migration. Si vos applications ne peuvent subir aucun temps d'arrêt, nous vous recommandons d'utiliser la fonctionnalité de migration côte à côte, qui est une option de migration sans temps d'arrêt puisque le nouvel environnement est créé dans un sous-réseau différent. Si vous choisissez également de ne pas utiliser la fonctionnalité de migration côte à côte, vous pouvez utiliser l’une des options manuelles pour recréer vos applications dans App Service Environment v3.

Vous pouvez répartir le trafic entre les anciens et les nouveaux environnement à l’aide d’Application Gateway. Si vous utilisez une ressource App Service Environment d’équilibreur de charge interne (ILB), créez une instance Azure Application Gateway avec un pool de back-end supplémentaire pour répartir le trafic entre vos environnements. Pour plus d’informations sur les ressources App Service Environment ILB et les ressources App Service Environment accessibles sur Internet, consultez Intégration d’Application Gateway.

Vous pouvez également utiliser des services tels qu’Azure Front Door, Azure Content Delivery Network et Azure Traffic Manager pour répartir le trafic entre les environnements. L’utilisation de ces services permet de tester votre nouvel environnement de manière contrôlée et vous permet de passer à votre nouvel environnement à votre rythme.

Après avoir terminé votre migration et les tests avec votre nouvel environnement, supprimez votre ancienne version d’App Service Environment, les applications qui y figurent et toutes les ressources de prise en charge dont vous n’avez plus besoin. Toutes les ressources que vous n’avez pas supprimées continuent de vous être facturées.

Forum aux questions

Comment puis-je savoir si je dois migrer vers App Service Environment v3 en utilisant l’une des options manuelles ?
Pour vous aider à déterminer l’option de migration appropriée, consultez Arbre de décision du chemin de migration. Si votre environnement répond aux critères décrits dans l’arbre de décision du chemin de migration, envisagez d’utiliser l’une des fonctionnalités de migration automatisées pour bénéficier d’un chemin plus rapide vers App Service Environment v3. La migration manuelle est recommandée si vous devez déplacer lentement vos applications vers votre nouvel environnement et valider tout au long du processus.
Vais-je subir des temps d’arrêt pendant la migration ?
Le temps d’arrêt dépend de votre processus de migration. Si vous disposez d’une ressource App Service Environment différente dans laquelle vous pouvez faire pointer le trafic pendant la migration, ou si vous pouvez utiliser un autre sous-réseau pour créer votre nouvel environnement, vous n’aurez pas de temps d’arrêt. Si vous devez utiliser le même sous-réseau, il y a un temps d’arrêt résultant du temps nécessaire à la suppression de l’ancien environnement, à la création de la ressource App Service Environment v3, à la création des nouveaux plans App Service, à la recréation des applications et à la mise à jour des ressources qui utilisent les nouvelles adresses IP.
Dois-je modifier quoi que ce soit sur mes applications pour qu’elles s’exécutent sur App Service Environment v3 ?
Non. Les applications qui s’exécutent sur App Service Environment v1 et v2 n’ont pas besoin d’être modifiées pour s’exécuter sur App Service Environment v3. Si vous utilisez IP SSL, vous devez supprimer les liaisons IP SSL avant la migration.
Que se passe-t-il si mon environnement App Service Environment a un suffixe de domaine personnalisé ?
La fonctionnalité de migration prend en charge ce scénario de migration. Vous pouvez migrer à l’aide d’une méthode manuelle si vous ne souhaitez pas utiliser la fonctionnalité de migration. Vous pouvez configurer votre suffixe de domaine personnalisé lors de la création de votre ressource App Service Environment v3 ou à tout moment ultérieurement.
Que se passe-t-il si ma ressource App Service Environment v2 est épinglée à une zone ?
L’épinglage de zone n’est pas une fonctionnalité prise en charge sur App Service Environment v3. Vous pouvez choisir d’activer la redondance de zone lors de la création de votre ressource App Service Environment v3.
Quelles propriétés de mon environnement App Service Environment vont changer ?
Passez en revue les différences de fonctionnalités entre App Service Environment v3 et les versions précédentes. Pour les ressources App Service Environment ILB, vous conservez la même adresse IP ILB. Pour les ressources App Service Environment accessibles via Internet, l’adresse IP publique et l’adresse IP sortante sont modifiées.

Pour les ressources App Service Environment accessibles via Internet, 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.
La sauvegarde et la restauration sont-elles prises en charge pour déplacer des applications d’App Service Environment v2 vers la v3 ? La fonctionnalité de sauvegarde et restauration prend en charge la restauration des applications entre les versions d’App Service Environment, à condition que vous utilisiez une sauvegarde personnalisée pour la restauration. La sauvegarde automatique ne prend pas en charge la restauration sur différentes versions d’App Service Environment.
Que se passe-t-il pour mes ressources App Service Environment v1 et 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, vos ressources App Service Environment v1 et v2 et les applications qui y sont déployées ne seront plus disponibles.

App Service Environment v1 et v2 sont hébergés sur des unités d’échelle App Service s’exécutant sur une architecture Azure Cloud Services (classic). Étant donné que cette architecture sera mise hors service le 31 août 2024, App Service Environment v1 et v2 ne seront pas disponibles après cette date. Migrez vers App Service Environment v3 pour que vos applications continuent de s’exécuter, ou enregistrez ou sauvegardez les ressources ou les données que vous devez conserver.