Utiliser la fonctionnalité de migration côte à côte pour migrer App Service Environment v2 vers App Service Environment v3
Remarque
La fonctionnalité de migration décrite dans cet article est utilisée pour la migration automatisée côte à côte (dans un autre sous-réseau) d’App Service Environment v2 vers App Service Environment v3.
Si vous recherchez des informations sur la fonctionnalité de migration sur place, consultez Migrer vers App Service Environment v3 à l’aide de la fonctionnalité de migration sur place. Si vous recherchez des informations sur les options de migration manuelle, consultez Options de migration manuelle. Pour vous aider à déterminer l’option de migration appropriée, consultez Arbre de décision du chemin de migration. Pour obtenir plus d’informations sur App Service Environment v3, consultez Vue d’ensemble d’App Service Environment v3.
Vous pouvez migrer automatiquement App Service Environment v2 vers App Service Environment v3 en utilisant la fonctionnalité de migration côte à côte. Pour découvrir plus d’informations sur le processus de migration et voir si votre App Service Environment prend en charge la migration à ce stade, consultez la Vue d’ensemble de la fonctionnalité de migration côte à côte.
Important
Nous vous recommandons d’utiliser cette fonctionnalité pour les environnements de développement avant de migrer des environnements de production, afin d’éviter des problèmes inattendus. Veuillez nous faire part de vos commentaires sur cet article ou cette fonctionnalité en utilisant les boutons situés en bas de la page.
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’existe aucun verrou sur votre réseau virtuel, vos groupes de ressources, ressources ou votre abonnement. Les verrous bloquent les opérations de plateforme pendant la migration.
Vérifiez qu’aucune stratégie Azure ne bloque les actions qui sont requises pour la migration, notamment les modifications de sous-réseau et les créations de ressources Azure App Service. Les stratégies bloquant des créations et des modifications de ressources peuvent entraîner l’échec ou le blocage d’une migration.
Du fait que votre App Service Environment v3 se trouve dans un autre sous-réseau de votre réseau virtuel, vous devez vérifier que vous avez un sous-réseau disponible dans votre réseau virtuel qui répond aux exigences de sous-réseau pour App Service Environment v3. Le sous-réseau que vous sélectionnez doit également être en mesure de communiquer avec le sous-réseau dans lequel se trouve votre fonctionnalité App Service Environment existante. Vérifiez que rien ne bloque la communication entre les deux sous-réseaux. Si vous ne disposez pas d’un sous-réseau disponible, vous devez en créer un avant de migrer. Il est possible que la création d’un sous-réseau implique l’augmentation de l’espace d’adressage de votre réseau virtuel. Si vous souhaitez obtenir plus d’informations, consultez Créer un réseau virtuel et un sous-réseau.
Comme la mise à l’échelle est bloquée pendant la migration, vous devez mettre à l’échelle votre environnement avec la taille souhaitée avant de commencer la migration. Si vous devez mettre à l’échelle votre environnement après la migration, vous pouvez le faire dès la fin de la migration.
Suivez les étapes décrites ici dans l’ordre et telles qu’elles sont écrites, car vous effectuez des appels d’API REST Azure. Nous vous recommandons d’utiliser Azure CLI pour effectuer ces appels d’API. Pour obtenir des informations sur les autres méthodes, consultez Informations de référence sur l’API REST Azure.
Pour ce guide, installez Azure CLI ou utilisez Azure Cloud Shell et utilisez un interpréteur de commandes Bash.
Remarque
Nous vous recommandons d’utiliser un interpréteur de commandes Bash pour exécuter les commandes fournies dans ce guide. Les commandes peuvent ne pas être compatibles avec les caractères d’échappement et les conventions PowerShell.
Important
Pendant la migration, le portail Azure peut afficher des informations incorrectes sur votre environnement App Service et vos applications. N’accédez pas à l’expérience de migration dans le portail Azure, car la fonctionnalité de migration côte à côte n’est pas disponible. Nous vous recommandons d’utiliser Azure CLI pour vérifier l’état de votre migration. Si vous avez des questions sur l’état de votre migration ou de vos applications, contactez le support technique.
1. Sélectionnez le sous-réseau pour votre nouvel App Service Environment v3
Sélectionnez un sous-réseau dans votre App Service Environment v3 qui respecte les exigences de sous-réseau pour App Service Environment v3. Notez le nom du sous-réseau que vous sélectionnez. Ce sous-réseau doit être différent du sous-réseau dans lequel se trouve votre fonctionnalité App Service Environment existante.
2. Obtenir votre ID App Service Environment
Exécutez les commandes suivantes pour obtenir votre ID App Service Environment et le stocker en tant que variable d’environnement. Remplacez les espaces réservés du nom et des groupes de ressources par vos valeurs pour l’environnement App Service que vous voulez migrer. ASE_RG et VNET_RG sont les mêmes si votre réseau virtuel et App Service Environment se trouvent dans le même groupe de ressources.
ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)
3. Confirmer que la migration est prise en charge
La commande suivante vérifie si votre environnement App Service Environment est pris en charge pour la migration. Si vous recevez une erreur ou si votre environnement App Service Environment se trouve dans un état non sain ou suspendu, vous ne pouvez pas migrer à ce stade. Consultez la section Résolution des problèmes pour obtenir les descriptions des messages d’erreur potentiels que vous pouvez obtenir. Si votre environnement n’est pas pris en charge pour la migration en utilisant la fonctionnalité de migration côte à côte, ou si vous voulez migrer vers App Service Environment v3 sans utiliser la fonctionnalité de migration côte à côte, consultez les options de migration manuelle. Cette commande valide également que votre ASE se trouve sur la version de build prise en charge pour la migration. Si votre ASE ne se trouve pas sur la version de build prise en charge, vous devez démarrer la mise à niveau vous-même. Pour plus d’informations sur la mise à niveau de la pré-migration, consultez Valider le fait que la migration est prise en charge à l’aide de la fonctionnalité de migration côte à côte pour votre ASE.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
S’il n’y a pas d’erreurs, votre migration est prise en charge et vous pouvez passer à l’étape suivante.
Si vous devez démarrer une mise à niveau pour mettre à niveau votre environnement App Service vers la version de build prise en charge, ce qui peut prendre 8 à 12 heures ou plus en fonction de la taille de votre environnement, exécutez la commande suivante. Exécutez cette commande uniquement si vous ne parvenez pas effectuer l’étape de validation et que vous êtes invité à mettre à niveau votre ASE.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Générer des adresses IP sortantes pour votre nouvelle fonctionnalité App Service Environment v3
Créez un fichier nommé zoneredundancy.json avec les détails suivants pour la sélection de votre région et de votre redondance de zone.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
Votre nouvel environnement App Service v3 peut être redondant interzone si votre environnement existant se trouve dans une région qui prend en charge la redondance interzone. Vous pouvez configurer la redondance de zone en définissant la propriété zoneRedundant sur true. La redondance interzone est une configuration facultative. Cette configuration peut être définie seulement pendant la création de votre environnement App Service v3 et ne peut pas être supprimée par la suite.
Exécutez la commande suivante pour créer des adresses IP sortantes. Cette étape prend environ 15 minutes. N’effectuez pas de mise à l’échelle et n’apportez pas de modifications à votre environnement App Service Environment existant pendant cette période.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
Exécutez la commande suivante pour vérifier l’état de cette étape :
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
Si elle est en cours, vous obtenez l’état Migrating. Après avoir obtenu l’état Ready, exécutez la commande suivante pour voir vos nouvelles adresses IP sortantes. Si les nouvelles adresses IP ne s’affichent pas immédiatement, patientez quelques minutes, puis réessayez.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5. Mettre à jour les ressources dépendantes avec les nouvelles adresses IP sortantes
En utilisant les nouvelles IP sortantes, mettez à jour 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.
6. Déléguer votre sous-réseau d’App Service Environment
L’environnement App Service Environment v3 exige que le sous-réseau où il se trouve dispose d’une seule délégation de Microsoft.Web/hostingEnvironments. Les versions précédentes n’exigeaient pas cette délégation. Vous devez vérifier que votre sous-réseau est délégué correctement et mettre à jour la délégation (si nécessaire) avant de procéder à la migration. Vous pouvez mettre à jour la délégation en exécutant la commande suivante ou en accédant au sous-réseau dans le portail Azure.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7. Vérifier qu’il n’existe aucun verrou sur le réseau virtuel
Les verrous de réseau virtuel bloquent les opérations de plateforme pendant la migration. Si votre réseau virtuel a des verrous, vous devez les supprimer avant la migration. Si nécessaire, vous pouvez rajouter les verrous une fois la migration terminée.
Les verrous peuvent exister dans trois étendues : 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, vous devez les supprimer 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.
Utilisez la commande suivante pour vérifier si votre réseau virtuel dispose de verrous :
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Supprimez les verrous existants à l’aide de la commande suivante :
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Pour connaître les commandes associées pour vérifier si votre abonnement ou groupe de ressources dispose de verrous, consultez la référence Azure CLI pour les verrous.
8. Préparer vos configurations
Si votre environnement App Service Environment existant utilise un suffixe de domaine personnalisé, vous devez en configurer un pour votre nouvelle ressource App Service Environment v3 pendant le processus de migration. La migration échoue si vous ne configurez pas de suffixe de domaine personnalisé alors que vous en utilisez un actuellement. Pour plus d’informations sur les suffixes de domaine personnalisé App Service Environment v3, notamment les exigences, les instructions pas à pas et les bonnes pratiques, consultez Suffixe de domaine personnalisé pour les environnements App Service Environment.
Remarque
Si vous configurez un suffixe de domaine personnalisé, lors de l’ajout des autorisations réseau sur votre instance Azure Key Vault, vérifiez que votre coffre de clés autorise l’accès depuis le nouveau sous-réseau de votre App Service Environment v3. Si vous accédez à votre coffre de clés à l’aide d’un point de terminaison privé, assurez-vous d’avoir correctement configuré l’accès privé avec le nouveau sous-réseau.
Pour définir ces configurations, notamment l’identification du sous-réseau sélectionné plus tôt, créez un autre fichier nommé parameters.json ayant les détails suivants basés sur votre scénario. Veillez à utiliser le nouveau sous-réseau sélectionné pour votre nouvelle fonctionnalité App Service Environment v3. N’ajoutez pas les propriétés de suffixe de domaine personnalisé si cette fonctionnalité ne s’applique pas à votre migration. Faites attention à la valeur de la propriété zoneRedundant et définissez-la sur la même valeur utilisée à l’étape de génération d’adresse IP sortante. Vous devez utiliser la même valeur pour la redondance de zone que celle utilisée à l’étape de génération d’adresse IP sortantes.
Si vous migrez sans suffixe de domaine personnalisé, utilisez ce code :
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
Si vous utilisez une identité managée affectée par l’utilisateur pour votre configuration de suffixe de domaine personnalisé, utilisez ce code :
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "/subscriptions/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é, utilisez ce code :
{
"properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>",
"customDnsSuffixConfiguration": {
"dnsSuffix": "internal.contoso.com",
"certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
"keyVaultReferenceIdentity": "SystemAssigned"
}
}
}
9. Migrer vers App Service Environment v3 et vérifier l’état
Une fois toutes les étapes précédentes effectuées, vous pouvez démarrer la migration. Assurez-vous de bien comprendre les implications de la migration.
L’achèvement de cette étape prend entre trois et six heures. Pendant ce temps, il n’existe aucun 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.
Exécutez la commande suivante pour démarrer la migration :
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
Exécutez la commande suivante pour vérifier l’état de votre migration :
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Une fois que vous obtenez l’état MigrationPendingDnsChange, la migration est effectuée et vous avez une ressource App Service Environment v3. Vos applications s’exécutent désormais dans votre nouvel environnement et dans votre ancien environnement.
Obtenez les détails de votre nouvel environnement en exécutant la commande suivante :
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Important
Pendant la migration et pendant l’étape MigrationPendingDnsChange, le portail Azure affiche des informations incorrectes sur votre App Service Environment et vos applications. Utilisez l’interface de ligne de commande Azure pour vérifier l’état de votre migration. Si vous avez des questions sur l’état de votre migration ou de vos applications, contactez le support technique.
Remarque
Si votre migration inclut un suffixe de domaine personnalisé, une fois la migration terminée, la configuration de suffixe du domaine personnalisé peut sembler altérée en raison d’un bogue connu. Votre environnement App Service devrait toujours fonctionner comme prévu. L’état altéré devrait se résoudre dans un délai de six à huit heures. Si la configuration est toujours altérée au bout de huit heures ou si le suffixe de votre domaine personnalisé ne fonctionne pas, contactez le support.
10. Obtenir les adresses IP entrantes pour votre nouvel App Service Environment v3 et mettre à jour les ressources dépendantes
Vous avez deux fonctionnalités App Service Environment à ce stade dans le processus de migration. Vos applications s’exécutent dans les deux environnements. Vous devez mettre à jour toute les ressources dépendantes afin d’utiliser la nouvelle adresse IP entrante pour votre nouvelle fonctionnalité App Service Environment v3. Pour les fonctionnalités App Service Environment en interne (ILB), vous devez mettre à jour vos zones DNS privées pour qu’elles pointent vers la nouvelle adresse IP entrante.
Vous pouvez obtenir l’adresse IP entrante de votre nouvelle fonctionnalité App Service Environment v3 en exécutant la commande suivante qui correspond à votre type d’équilibreur de charge App Service Environment. Il vous incombe d’effectuer toutes les mises à jour nécessaires.
Pour les environnements App Service ILB, obtenez l’adresse IP entrante privée en exécutant la commande suivante :
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
Pour les environnements App Service ELB, obtenez l’adresse IP entrante publique en exécutant la commande suivante :
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
11. Rediriger le trafic client, valider votre ASE v3 et effectuer la migration
Cette étape constitue votre opportunité de tester et de valider votre nouvelle fonctionnalité App Service Environment v3. Par défaut, le trafic est envoyé à vos front-ends App Service Environment v2. Si vous utilisez un ILB App Service Environment v3, vous pouvez tester votre serveur front-end App Service Environment v3 en mettant à jour votre zone DNS privée avec la nouvelle adresse IP entrante. Si vous utilisez un ELB App Service Environment v3, le processus de test dépend de votre configuration réseau spécifique. Une méthode simple pour tester les environnements ELB consiste à mettre à jour votre fichier hôtes pour utiliser votre nouvelle adresse IP entrante App Service Environment v3. Si certains de vos domaines personnalisés sont attribués à vos applications individuelles, vous pouvez également mettre à jour leur DNS pour les faire pointer vers la nouvelle adresse IP entrante. Tester cette modification vous permet de valider entièrement votre environnement ASE v3 avant de lancer l’étape finale de la migration où votre ancien ASE est supprimé. Si vous pouvez accéder à vos applications sans problème, cela signifie que vous êtes prêt à effectuer la migration.
Une fois que vous avez confirmé que vos applications fonctionnent comme prévu, vous pouvez rediriger le trafic client vers vos nouveaux serveurs front-end ASE v3 en exécutant la commande suivante. Cette commande supprime également votre ancien environnement. Vous avez 14 jours pour effectuer cette étape. Si vous n’effectuez pas cette étape dans les 14 jours, votre migration est automatiquement rétablie en un environnement App Service Environment v2. Si vous avez besoin de plus de 14 jours pour effectuer cette étape, contactez le support technique.
Si vous détectez des problèmes ou décidez à ce stade que vous ne souhaitez plus poursuivre la migration, contactez l’équipe de support pour restaurer la migration. N’exécutez pas la commande de changement de DNS si vous souhaitez restaurer la migration. Pour obtenir plus d’informations, consultez Restaurer une migration.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
Exécutez la commande suivante pour vérifier l’état de cette étape :
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Pendant cette étape, vous obtenez l’état CompletingMigration. Quand vous obtenez l’état MigrationCompleted, l’étape de redirection du trafic est effectuée et votre migration est terminée.