Uso de la característica de migración en paralelo para migrar la versión 2 de App Service Environment a la versión 3
Nota:
La característica de migración que se describe en este artículo se usa para la migración automatizada en paralelo (en una subred diferente) de la versión 2 de App Service Environment a la versión 3.
Si busca información sobre la característica de migración local, consulte Migración a App Service Environment v3 mediante la característica de migración local. Si busca información sobre las opciones de migración manual, consulte Opciones de migración manual. Para obtener ayuda para decidir qué opción de migración es adecuada para usted, consulte Árbol de decisión ruta de migración. Para obtener más información sobre App Service Environment v3, consulte Introducción a App Service Environment v3.
Puede migrar automáticamente de App Service Environment v2 a App Service Environment v3 mediante la característica de migración en paralelo. Para obtener más información sobre el proceso de migración y comprobar si la instancia de App Service Environment admite la migración en este momento, consulte la información general sobre la característica de migración en paralelo.
Importante
Se recomienda usar esta característica para entornos de desarrollo antes de migrar cualquier entorno de producción, para evitar problemas inesperados. Proporcione comentarios relacionados con este artículo o la característica mediante los botones que se encuentran en la parte inferior de la página.
Requisitos previos
Asegúrese de que comprende cómo afecta la migración a App Service Environment v3 a las aplicaciones. Revise el proceso de migración para comprender la escala de tiempo del proceso y dónde y cuándo tendrá que participar. Revise también las preguntas más frecuentes, que pueden responder a algunas de sus preguntas.
Asegúrese de que no haya bloqueos en la red virtual, los grupos de recursos, los recursos o la suscripción. Los bloqueos bloquean las operaciones de plataforma durante la migración.
Asegúrese de que no haya directivas de Azure que bloqueen las acciones necesarias para la migración, incluidas las modificaciones de subred y las creaciones de recursos de Azure App Service. Las directivas que bloquean las modificaciones y las creaciones de recursos pueden provocar que la migración se bloquee o produzca un error.
Dado que App Service Environment v3 está en una subred diferente de la red virtual, debe asegurarse de que tiene una subred disponible en la red virtual que cumple los requisitos de subred de App Service Environment v3. La subred que seleccione también debe poder comunicarse con la subred en la que se encuentra la instancia de App Service Environment existente. Asegúrese de que no haya nada que bloquee la comunicación entre las dos subredes. Si no tiene una subred disponible, debe crear una antes de migrar. La creación de una nueva subred puede implicar aumentar el espacio de direcciones de la red virtual. Para obtener más información, consulte Creación de una red virtual y una subred.
Dado que el escalado se bloquea durante la migración, debe escalar el entorno al tamaño deseado antes de iniciar la migración. Si necesita escalar el entorno después de la migración, puede hacerlo una vez completada la migración.
Siga los pasos que se describen aquí en orden y como se escriben, ya que está realizando llamadas a la API de REST de Azure. Se recomienda usar la CLI de Azure para realizar estas llamadas de API. Para obtener información acerca de otros métodos, consulte Referencia de API de REST de Azure.
Para esta guía, instale la CLI de Azure o use Azure Cloud Shell y utilice un shell de Bash.
Nota:
Se recomienda usar un shell de Bash para ejecutar los comandos proporcionados en esta guía. Es posible que los comandos no sean compatibles con las convenciones de PowerShell y los caracteres de escape.
Importante
Durante la migración, Azure Portal podría mostrar información incorrecta sobre App Service Environment y sus aplicaciones. No vaya a la experiencia de migración en Azure Portal, ya que la característica de migración en paralelo no está disponible allí. Se recomienda usar la CLI de Azure para comprobar el estado de la migración. Si tiene alguna pregunta sobre el estado de la migración o las aplicaciones, póngase en contacto con el soporte técnico.
1. Selección de la subred para la nueva instancia de App Service Environment v3
Seleccione una subred en App Service Environment v3 que cumpla los requisitos de subred de App Service Environment v3. Anote el nombre de la subred que seleccione. Esta subred debe ser diferente de la subred en la que se encuentra su instancia de App Service Environment existente.
2. Obtención del identificador de App Service Environment
Ejecute los comandos siguientes para obtener el identificador de App Service Environment y almacenarlo como una variable de entorno. Reemplace los marcadores de posición del nombre y los grupos de recursos por los valores de App Service Environment que quiera migrar. ASE_RG y VNET_RG son los mismos si la red virtual y App Service Environment están en el mismo grupo de recursos.
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. Validación de la compatibilidad de la migración
El comando siguiente comprueba si la instancia de App Service Environment es compatible con la migración. Si se produce un error o si App Service Environment está en un estado incorrecto o suspendido, no podrá realizar la migración en este momento. Consulte la sección de solución de problemas para obtener descripciones de los posibles mensajes de error que puede obtener. Si el entorno no es compatible con la migración con la característica de migración en paralelo o si quiere migrar a App Service Environment v3 sin usar la característica de migración en paralelo, consulte las opciones de migración manuales. Este comando también valida que App Service Environment está en la versión de compilación admitida para la migración. Si App Service Environment no está en la versión de compilación admitido, debe iniciar la actualización usted mismo. Para obtener más información sobre la actualización de la migración previa, consulte Validación de que la migración se admite mediante la característica de migración en paralelo para App Service Environment.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"
Si no hay errores, se admite la migración y puede continuar con el paso siguiente.
Si necesita iniciar una actualización para actualizar App Service Environment a la versión de compilación admitida, ejecute el siguiente comando. Ejecute este comando solo si produce un error en el paso de validación y se le indica que actualice App Service Environment.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"
4. Generación de direcciones IP salientes para la nueva instancia de App Service Environment v3
Cree un archivo denominado zoneredundancy.json con los detalles siguientes para la selección de redundancia de zona y región.
{
"location":"<region>",
"Properties": {
"zoneRedundant": "<true/false>"
}
}
Puede hacer que el nuevo App Service Environment zona v3 sea redundante si el entorno existente está en una región que admita la redundancia de zona. La redundancia de zona se puede configurar estableciendo la propiedad zoneRedundant en true. La redundancia de zona es una configuración opcional. Esta configuración solo se puede establecer durante la creación de la nueva App Service Environment v3 y no se puede quitar más adelante.
Ejecute el comando siguiente para crear nuevas direcciones IP salientes. Este paso tarda unos 15 minutos en completarse. No modifique la escala ni realice cambios en la instancia existen de App Service Environment durante este tiempo.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json
Ejecute el comando siguiente para comprobar el estado de este paso:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.status
Si el paso está en curso, obtiene el estado Migrating. Una vez que obtenga el estado de Ready, ejecute el comando siguiente para ver las nuevas direcciones IP salientes. Si no ve las nuevas direcciones IP inmediatamente, espere unos minutos e inténtelo de nuevo.
az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses
5. Actualización de recursos dependientes con nuevas direcciones IP salientes
Mediante el uso de las nuevas direcciones IPs de salida, actualice cualquiera de los recursos o componentes de red para asegurarse de que el nuevo entorno funciona según lo previsto una vez completada la migración. Es responsable de realizar las actualizaciones necesarias.
6. Delegación de la subred de App Service Environment
En App Service Environment v3 es necesario que la subred en la que se encuentra tenga una sola delegación de Microsoft.Web/hostingEnvironments. En las versiones anteriores no es necesaria esta delegación. Tiene que confirmar que la subred se ha delegado correctamente y actualizar la delegación (si es necesario) antes de migrar. Puede actualizar la delegación si ejecuta el comando siguiente o si va hasta la subred en Azure Portal.
az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments
7. Confirmación de que no haya bloqueos en la red virtual
Los bloqueos de la red virtual bloquean las operaciones de la plataforma durante la migración. Si la red virtual tiene bloqueos, debe quitarlos antes de migrar. Si es necesario, puede volver a agregar los bloqueos una vez completada la migración.
Los bloqueos pueden existir en tres ámbitos: suscripción, grupo de recursos y recurso. Cuando se aplica un bloqueo en un ámbito primario, todos los recursos heredan el mismo bloqueo. Si tiene bloqueos aplicados en el ámbito de suscripción, grupo de recursos o recurso, debe quitarlos antes de llevar a cabo la migración. Para más información sobre los bloqueos y la herencia de bloqueos, consulte Bloqueo de los recursos para proteger la infraestructura.
Use el siguiente comando para comprobar si la red virtual tiene bloqueos:
az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Elimine los bloqueos existentes con el siguiente comando:
az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks
Para ver los comandos relacionados para comprobar si la suscripción o el grupo de recursos tiene bloqueos, consulte la Referencia de la CLI de Azure para bloqueos.
8. Preparación de las configuraciones
Si el App Service Environment existente usa un sufijo de dominio personalizado, debe configurar uno para el nuevo recurso App Service Environment v3 durante el proceso de migración. Se produce un error en la migración si no configura un sufijo de dominio personalizado y usa uno actualmente. Para obtener más información sobre el sufijos de dominio personalizado de App Service Environment v3, incluidos los requisitos, las instrucciones paso a paso y los procedimientos recomendados, consulte Sufijo de dominio personalizado para App Service Environment.
Nota:
Si va a configurar un sufijo de dominio personalizado, al agregar los permisos de red en el almacén de claves de Azure, asegúrese de que el almacén de claves permite el acceso desde la nueva subred de App Service Environment v3.
Para establecer estas configuraciones, incluida la identificación de la subred seleccionada anteriormente, cree otro archivo denominado parameters.json con los detalles siguientes en función de su escenario. Asegúrese de usar la nueva subred seleccionada para la nueva instancia de App Service Environment v3. No incluya las propiedades para un sufijo de dominio personalizado si esta característica no se aplica a la migración. Preste atención al valor de la propiedad zoneRedundant y establézcalo en el mismo valor que usó en el paso de generación de IP salientes. Debe usar el mismo valor para la redundancia de zona que usó en el paso de generación de IP de salida.
Si va a migrar sin un sufijo de dominio personalizado, use este código:
{
"Properties": {
"VirtualNetwork": {
"Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
},
"zoneRedundant": "<true/false>"
}
}
Si usa una identidad administrada asignada por el usuario para la configuración del sufijo de dominio personalizado, use este código:
{
"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/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
}
}
}
Si usa una identidad administrada asignada por el sistema para la configuración del sufijo de dominio personalizado, use este código:
{
"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. Migración manual a App Service Environment v3 y comprobación del estado
Una vez completados todos los pasos anteriores, puede iniciar la migración. Asegúrese de comprender las implicaciones de la migración.
Este paso tarda entre tres y seis horas en completarse. Durante ese tiempo, no hay tiempo de inactividad de la aplicación. El escalado, la implementación y las modificaciones en la instancia existente de App Service Environment se bloquean durante este paso.
Ejecute el siguiente comando para iniciar la migración:
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json
Ejecute el siguiente comando para comprobar el estado de la migración:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Una vez que obtenga el estado MigrationPendingDnsChange, la migración habrá terminado y tendrá un recurso App Service Environment v3. Las aplicaciones ahora se ejecutan en el nuevo entorno y en el entorno anterior.
Ejecute el siguiente comando para obtener los detalles del nuevo entorno:
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Importante
Durante la migración, así como durante el paso MigrationPendingDnsChange, Azure Portal muestra información incorrecta sobre la aplicación Service Environment y sus aplicaciones. Use la CLI de Azure para comprobar el estado de la migración. Si tiene alguna pregunta sobre el estado de la migración o las aplicaciones, póngase en contacto con el soporte técnico.
Nota:
Si la migración incluye un sufijo de dominio personalizado, su configuración podría mostrarse como degradada una vez completada la migración debido a un error conocido. App Service Environment debería seguir funcionando con normalidad. El estado degradado se debería resolver automáticamente en un plazo de 6 a 8 horas. Si la configuración sigue degradada después de 8 horas o si el sufijo del dominio personalizado no funciona, póngase en contacto con el soporte técnico.
10. Obtenga las direcciones IP de entrada para la nueva instancia de App Service Environment v3 y actualice los recursos dependientes
Tiene dos instancias de App Service Environment en esta fase en el proceso de migración. Las aplicaciones se ejecutan en ambos entornos. Debe actualizar los recursos dependientes para usar la nueva dirección IP entrante para la nueva instancia de App Service Environment v3. Para instancias de App Service Environment orientadas internamente (ILB), debe actualizar las zonas DNS privadas para que apunten a la nueva dirección IP de entrada.
Para obtener la nueva dirección IP de entrada para la nueva instancia de App Service Environment v3, ejecute el siguiente comando que corresponde al tipo de equilibrador de carga de App Service Environment. Es responsable de realizar las actualizaciones necesarias.
Para entornos de App Service con ILB, ejecute el comando siguiente para obtener la dirección IP de entrada privada:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses
Para entornos de App Service de ELB, ejecute el comando siguiente para obtener la dirección IP de entrada pública:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses
Redirigir el tráfico de cliente, validar la versión del entorno de App Service Environment v3 y completar la migración
Este paso es la oportunidad de probar y validar la nueva instancia de App Service Environment v3. De forma predeterminada, el tráfico se envía a los servidores front-end de la versión 2 de App Service Environment. Si usa un entorno de la versión 3 de App Service Environment de ILB, puede probar los servidores front-end de la versión 3 de App Service Environment, para lo que debe actualizar su zona DNS privada con la nueva dirección IP de entrada. Si usa una instancia de App Service Environment v3 de ELB, el proceso de prueba depende de la configuración de red específica. Un método sencillo para probar los entornos de ELB es actualizar el archivo de hosts para usar la nueva dirección IP de entrada de App Service Environment, versión 3. Si tiene dominios personalizados asignados a las aplicaciones individuales, también puede actualizar su DNS para que apunte a la nueva IP de entrada. Probar este cambio le permite validar completamente el entorno de App Service Environment v3 antes de iniciar el paso final de la migración, en el que se elimina el antiguo entorno de App Service Environment. Si puede acceder a las aplicaciones sin problemas, significa que está listo para completar la migración.
Una vez que confirme que las aplicaciones funcionan según lo previsto, puede redirigir el tráfico del cliente a la nueva instancia de App Service Environment v3 mediante la ejecución del siguiente comando. Este comando también elimina el entorno anterior. Tiene 14 días para completar este paso. Si no completa este paso en 14 días, la migración se revertirá automáticamente a una instancia de App Service Environment v2. Si necesita más de 14 días para completar este paso, póngase en contacto con el soporte técnico.
Si encuentra algún problema o decide en este momento que ya no desea continuar con la migración, póngase en contacto con el soporte técnico para revertir la migración. No ejecute el comando de cambio de DNS si necesita revertir la migración. Para obtener más información, consulte Revertir la migración.
az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"
Ejecute el comando siguiente para comprobar el estado de este paso:
az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus
Durante este paso, obtendrá un estado de CompletingMigration. Cuando se obtiene un estado de MigrationCompleted, se realiza el paso de redirección del tráfico y se completa la migración.