Uso de la característica de migración local para migrar App Service Environment v1 y v2 a App Service Environment v3
Nota:
La característica de migración que se describe en este artículo se usa para la migración automatizada en contexto (misma subred) de App Service Environment v1 y v2 a App Service Environment v3. Si busca información sobre la característica de migración en paralelo, consulte Migración a App Service Environment v3 mediante la característica de migración en paralelo. 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 una instancia de App Service Environment v1 y v2 a App Service Environment v3 mediante la característica de migración local. 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 local.
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 hay bloqueos en la red virtual, el grupo de recursos, el recurso 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 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.
Se recomienda usar Azure Portal para la experiencia de migración local. Si decide usar la CLI de Azure para llevar a cabo la migración, siga los pasos descritos aquí en orden y conforme a lo indicado, ya que realiza llamadas de 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.
1. Obtención del id. 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)
2. 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 local o si quiere migrar a App Service Environment v3 sin usar la característica de migración local, 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 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 local para App Service Environment.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"
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}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"
3. Generación de direcciones IP para el nuevo recurso de App Service Environment v3
Ejecute el comando siguiente para crear nuevas direcciones IP. 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}/migrate?api-version=2021-02-01&phase=premigration"
Ejecute el comando siguiente para comprobar el estado de este paso:
az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status
Si el paso está en curso, obtiene el estado Migrating. Una vez que obtenga el estado Ready, ejecute el comando siguiente para ver las nuevas direcciones IP. 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=2021-02-01"
Nota:
Debido a un error conocido, en las migraciones de App Service Environment de ELB, la dirección IP de entrada puede volver a cambiar una vez que el paso de migración se ha completado. Prepárese para actualizar los recursos dependientes de nuevo con la nueva dirección IP de entrada una vez que se complete el paso de migración. Este error se está estudiando y se corregirá lo antes posible. Si tiene cualquier pregunta o duda sobre este problema o necesita ayuda con el proceso de migración, abra un caso de soporte técnico.
4. Actualización de recursos dependientes con IP nuevas
Mediante el uso de las nuevas IP, actualice sus recursos o los componentes de red para asegurarse de que el nuevo entorno funciona según lo previsto una vez que se complete la migración. Es responsable de realizar las actualizaciones necesarias.
Este paso también es un buen momento para revisar los cambios en las dependencias de red entrante y saliente al pasar a App Service Environment v3. Estos cambios incluyen el cambio de puerto para Azure Load Balancer, que ahora usa el puerto 80. No migre hasta que complete este paso.
5. 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
6. Confirme que no hay 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.
7. Prepare las configuraciones
Puede hacer que la zona del nuevo recurso App Service Environment 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. Solo puede establecerla durante la creación del nuevo recurso de App Service Environment v3. No se puede quitar más adelante. Para más información, consulte Elegir sus configuraciones de App Service Environment v3. Si no desea configurar la redundancia de zona, no incluya el parámetro zoneRedundant.
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. También se produce un error en la migración si intenta agregar un sufijo de dominio personalizado durante la migración a un entorno que no tiene uno configurado. 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 las nuevas direcciones IP de salida de App Service Environment que se generaron en el paso 3.
Si la migración no incluye un sufijo de dominio personalizado y no habilita la redundancia de zona, puede pasar a la migración.
Para establecer estas configuraciones, cree un archivo denominado parameters.json con los detalles siguientes en función de su escenario. 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, ya que esta configuración es irreversible después de la migración. Establezca el valor de la propiedad kind en función de la versión de App Service Environment existente. Los valores posibles para la propiedad kind son ASEV1 y ASEV2.
Si va a migrar sin un sufijo de dominio personalizado y habilita la redundancia de zona, use el código siguiente:
{
"type": "Microsoft.Web/hostingEnvironments",
"name": "sample-ase-migration",
"kind": "ASEV2",
"location": "westcentralus",
"properties": {
"zoneRedundant": true
}
}
Si usa una identidad administrada asignada por el usuario para la configuración del sufijo de dominio personalizado y habilita la redundancia de zona, use el código siguiente:
{
"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/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 y no habilita la redundancia de zona, use el código siguiente:
{
"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. 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 de tres a seis horas para las migraciones de v2 a v3 y hasta seis horas para las migraciones de v1 a v3, en función del tamaño del entorno. Durante ese tiempo, hay aproximadamente una hora de 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.
Incluya el parámetro body en el comando siguiente si va a habilitar la redundancia de zona o está configurando un sufijo de dominio personalizado. Si ninguna de esas configuraciones se aplica a la migración, puede quitar el parámetro del comando.
az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json
Ejecute los comandos siguientes para comprobar el estado detallado de la migración. Para obtener información sobre los estados, consulte las descripciones de estado de migración.
El primer comando obtiene el id. de la operación para la migración. Copie el valor de la propiedad ID.
az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"
Reemplace el marcador de posición del id. de la operación en el siguiente comando por el valor ha copiado. Este comando devuelve el estado detallado de la migración. Puede ejecutar este comando con la frecuencia necesaria para obtener el estado más reciente.
az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"
Una vez que obtenga el estado Ready, la migración habrá terminado y tendrá un recurso App Service Environment v3. Las aplicaciones se ejecutan ahora en el nuevo entorno.
Para obtener los detalles del nuevo entorno, ejecute el comando siguiente o vaya a Azure Portal.
az appservice ase show --name $ASE_NAME --resource-group $ASE_RG
Nota:
Debido a un error conocido, en las migraciones de App Service Environment de ELB, la dirección IP de entrada puede cambiar una vez que el paso de migración se ha completado. Compruebe las direcciones IP de App Service Environment v3 y realice las actualizaciones necesarias si se han producido cambios desde el paso de generación de direcciones IP. Si tiene cualquier pregunta o duda sobre este problema o necesita ayuda con la confirmación de las nuevas direcciones IP, abra un caso de soporte técnico.
1. Validación de la compatibilidad de la migración
En Azure Portal, vaya a la página Migración de la instancia de App Service Environment a la que está migrando. Para acceder a la página Migración, seleccione el mensaje de la parte superior de la página Información general de la instancia de App Service Environment o seleccione el elemento Migración del menú izquierdo.
En la página Migración, la plataforma valida si se admite la migración de la instancia de App Service Environment. Seleccione Validar y confirme que desea continuar con la validación. El proceso de validación requiere algunos segundos.
Si el entorno no es compatible con la migración, aparece un mensaje en la parte superior de la página con un mensaje de error con un motivo. Consulte la sección Solución de problemas para ver descripciones de los mensajes de error que pueden aparecer si no es apto para la migración.
Si su instancia de App Service Environment no es compatible con la migración en este momento o el entorno está en un estado incorrecto o suspendido, no puede usar la característica de migración. Si el entorno no es compatible con la migración con la característica de migración local o si quiere migrar a App Service Environment v3 sin usar la característica de migración local, consulte las opciones de migración manuales.
Si necesita iniciar una actualización para actualizar App Service Environment a la versión de compilación admitida, se le pedirá que inicie la actualización. Seleccione Actualizar para iniciar la actualización. Una vez completada la actualización, se pasa la validación y se puede usar la característica de migración para iniciar la migración.
Si la migración es compatible con su instancia de App Service Environment, continúe con el paso siguiente del proceso. La página Migración le guía a lo largo de la serie de pasos necesarios para realizar la migración.
2. Generación de direcciones IP para el nuevo recurso de App Service Environment v3
En Obtener nuevas direcciones IP, confirme que comprende las implicaciones e inicie el proceso y seleccione el botón Inicio. Este paso tarda unos 15 minutos en completarse. No puede modificar la escala ni realizar cambios en la instancia existente de App Service Environment durante este tiempo.
3. Actualización de recursos dependientes con IP nuevas
Al terminar el paso anterior, aparecen las direcciones IP del nuevo recurso App Service Environment v3. Con las nuevas IP puede actualizar los recursos y los componentes de red para que el nuevo entorno funcione según lo previsto una vez que se complete la migración. Es responsable de realizar las actualizaciones necesarias.
Este paso también es un buen momento para revisar los cambios en las dependencias de red entrante y saliente al pasar a App Service Environment v3. Estos cambios incluyen el cambio de puerto para Azure Load Balancer, que ahora usa el puerto 80. No vaya al siguiente paso hasta que haya confirmado que ha realizado estas actualizaciones.
4. 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. El portal muestra un vínculo a la subred para que pueda confirmar y actualizar según sea necesario.
5. Confirmación de cambios de tamaño de instancia
Los planes de App Service se convierten de Aislado al nivel Aislado v2 correspondiente. Por ejemplo, I2 se convierte en I2v2. Es posible que las aplicaciones se aprovisionen en exceso después de la migración, ya que el nivel Aislado v2 tiene más memoria y CPU por tamaño de instancia correspondiente. Tiene la oportunidad de escalar el entorno según sea necesario una vez completada la migración. Para obtener más información, revise los detalles de precios.
6. Confirmación de que la red virtual no tiene bloqueos
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.
Para más información sobre cómo comprobar si la suscripción o el grupo de recursos tiene bloqueos, consulte Configuración de bloqueos.
7. Elija las configuraciones
Puede hacer que la zona del nuevo recurso App Service Environment v3 sea redundante si el entorno existente está en una región que admita la redundancia de zona. La redundancia de zona es una configuración opcional. Solo puede establecerla durante la creación del nuevo recurso de App Service Environment v3. No se puede quitar más adelante. Para más información, consulte Elegir sus configuraciones de App Service Environment v3.
Active la casilla Habilitado si quiere configurar la redundancia de zona.
Si el entorno está en una región que no admite redundancia de zona, la casilla no está disponible. Si necesita un recurso App Service Environment v3 con redundancia de zona, use una de las opciones de migración manual y cree el recurso en una de las regiones que admite la redundancia de zona.
Si el App Service Environment existente usa un sufijo de dominio personalizado, deberá configurar uno para el nuevo recurso App Service Environment v3. Las opciones de configuración de un sufijo de dominio personalizado aparecen si esta situación se aplica a usted. No puede migrar hasta que proporcione la información necesaria.
Si quiere usar un sufijo de dominio personalizado, pero no tiene configurado actualmente uno, puede configurar uno una vez completada la migración. 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 las nuevas direcciones IP de salida de App Service Environment que se generaron en el paso 2.
Después de agregar los detalles del sufijo de dominio personalizado, el botón Migrar está disponible.
8. Migración a App Service Environment v3
Una vez completados todos los pasos anteriores, puede iniciar la migración. Asegúrese de comprender las implicaciones de la migración, incluido lo que ocurre durante este tiempo.
Este paso tarda de tres a seis horas para las migraciones de v2 a v3 y hasta seis horas para las migraciones de v1 a v3, en función del tamaño del entorno. El escalado y las modificaciones en la instancia existente de App Service Environment se bloquean durante este paso.
Nota:
En raras ocasiones, es posible que vea una notificación en el portal que indica "Error de migración a App Service Environment v3" después de iniciar la migración. Hay un error conocido que podría desencadenar esta notificación, incluso si la migración está progresando. Compruebe el registro de actividad de App Service Environment para determinar la validez de este mensaje de error. En la mayoría de los casos, al actualizar la página se resuelve el problema y el mensaje de error desaparece. Si el mensaje de error persiste, póngase en contacto con el soporte técnico para obtener ayuda.
En este momento, los estados detallados de la migración solo están disponibles cuando se usa la CLI de Azure. Para obtener más información, consulte la sección CLI de Azure para migrar a App Service Environment v3. Puede comprobar el estado de la migración con la CLI incluso si usa el portal para realizar la migración.
Una vez completada la migración, tiene un recurso App Service Environment v3 y todas las aplicaciones se ejecutan en el nuevo entorno. Para confirmar la versión del entorno, vea la página Configuración de App Service Environment.
Nota:
Debido a un error conocido, en las migraciones de App Service Environment de ELB, la dirección IP de entrada puede cambiar una vez que el paso de migración se ha completado. Compruebe las direcciones IP de App Service Environment v3 y realice las actualizaciones necesarias si se han producido cambios desde el paso de generación de direcciones IP. Si tiene cualquier pregunta o duda sobre este problema o necesita ayuda con la confirmación de las nuevas direcciones IP, abra un caso de soporte técnico.
Si la migración incluye un sufijo de dominio personalizado, el dominio aparecía en la sección Información esencial de la página Información general del portal para App Service Environment v1/v2, pero ya no aparece en App Service Environment v3. Alternativamente, en el caso de App Service Environment v3, vaya a la página Sufijo de dominio personalizado, para confirmar que el sufijo de dominio personalizado está configurado correctamente. También puede quitar la configuración si ya no lo necesita o configurar uno si no lo tenía anteriormente.
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 entre 6 y 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.
