Migración a App Service Environment v3

Artículo
03/06/2024

Nota:

Hay dos características de migración automatizadas disponibles para ayudarle a actualizar a App Service Environment v3. Para obtener más información sobre esas características y para obtener ayuda para decidir qué opción de migración es adecuada para usted, consulte Árbol de decisión de ruta de migración. Considere una de las opciones automatizadas para lograr una ruta de acceso más rápida a App Service Environment v3.

Si actualmente usa App Service Environment v1 o v2, tiene la posibilidad de migrar las cargas de trabajo a App Service Environment v3. App Service Environment v3 tiene ventajas y diferencias en las características que proporcionan compatibilidad mejorada con las cargas de trabajo y pueden reducir los costos generales. Considere la posibilidad de usar las características de migración automatizadas si el entorno cumple los criterios descritos en el árbol de decisión de ruta de migración.

Si su instancia de App Service Environment no es compatible con la característica de migración, debe usar uno de los métodos manuales para migrar a App Service Environment v3.

Requisitos previos

Escenario: Tiene una aplicación que se ejecuta en App Service Environment v1 o App Service Environment v2, y necesita que esa aplicación se ejecute en App Service Environment v3.

Si los métodos de migración no usan las características automatizadas de migración, debe crear el recurso de App Service Environment v3 y una nueva subred mediante el método que prefiera.

Los cambios de red entre App Service Environment v1/v2 y App Service Environment v3 suponen nuevas direcciones IP (y otras adicionales para entornos accesibles desde Internet). Debe actualizar cualquier infraestructura que se base en estas IP. Asegúrese de contar con los cambios de dependencia de entrada, como el puerto de Azure Load Balancer.

No pueden existir varios entornos de App Service Environment en una sola subred. Si necesita usar la subred existente con el nuevo recurso App Service Environment v3, debe eliminar la instancia existente de App Service Environment existente antes de crear una nueva. En este escenario, se recomienda realiza una copia de seguridad de las aplicaciones y, luego, restaurarlas en el nuevo entorno después de crearlo y configurarlo. Este proceso provoca el tiempo de inactividad de la aplicación debido al tiempo que se tarda en:

Eliminar el entorno anterior.
Crear el recurso App Service Environment v3.
Configurar la infraestructura y los recursos conectados para trabajar con el nuevo entorno.
Implementar las aplicaciones en el nuevo entorno.

Lista de comprobación antes de migrar aplicaciones

Crear un recurso App Service Environment v3.
Actualizar las dependencias de red con las direcciones IP asociadas al nuevo entorno.
Planear el tiempo de inactividad (si procede).
Decidir un proceso para volver a crear las aplicaciones en el entorno nuevo.

Tamaño y escalado del entorno

App Service Environment v3 usa los planes Aislado v2 de Azure App Service que tienen un precio y un tamaño distintos a los de los planes aislados. Revise los detalles de precios para comprender cómo se debe cambiar el tamaño del entorno nuevo y escalarlo a fin de garantizar la capacidad adecuada. No hay ninguna diferencia en la forma de crear planes de App Service para App Service Environment v3 en comparación con las versiones anteriores.

Evaluación de la copia de seguridad y restauración

Puede usar la característica de copia de seguridad y restauración para mantener la configuración de la aplicación, el contenido de los archivos y la base de datos conectados a la aplicación al migrar al nuevo entorno.

Debe configurar copias de seguridad personalizadas de las aplicaciones con el fin de restaurarlas en App Service Environment v3. La copia de seguridad automática no admite la restauración en diferentes versiones de App Service Environment. Para más información sobre las copias de seguridad personalizadas, consulte Copias de seguridad automáticas frente a personalizadas. Screenshot that shows options for configuring custom backups for an App Service app.

Puede seleccionar una copia de seguridad personalizada y restaurarla en App Service en el recurso App Service Environment v3. Antes de restaurar la aplicación, debe crear el plan de App Service en el que lo hará. Puede optar por restaurar la copia de seguridad en el espacio de producción, o bien en una ranura existente o recién creada que cree durante el proceso de restauración.

Screenshot that shows how to use a backup to restore an App Service app in App Service Environment v3.

Ventajas	Limitaciones
Rápido: solo tardará entre 5 y 10 minutos por aplicación.	La compatibilidad se limita a determinados tipos de base de datos.
Puede restaurar varias aplicaciones al mismo tiempo. (Debe configurar la restauración para cada aplicación por separado).	Los entornos antiguos y nuevos, así como los recursos compatibles (por ejemplo, aplicaciones, bases de datos, cuentas de almacenamiento y contenedores) deben estar todos en la misma suscripción.
Se hace una copia de datos automáticamente de las bases de datos MySQL en la aplicación sin ninguna configuración.	Puede realizar copias de seguridad de hasta 10 GB de contenido de base de datos y aplicaciones. La copia de seguridad de la base de datos puede ser de hasta 4 GB de ese contenido. Si el tamaño de la copia de seguridad supera este límite, obtendrá un error.
Puede restaurar la aplicación a una instantánea de un estado anterior.	No se admite el uso de una cuenta de almacenamiento habilitada para firewall como destino para las copias de seguridad.
Se realizar la integración con Azure Traffic Manager y Azure Application Gateway para distribuir el tráfico entre los entornos antiguos y nuevos.	No se admite el uso de una cuenta de almacenamiento con puntos de conexión privados para la copia de seguridad y restauración.
Antes de comenzar la restauración, y con el fin de acelerar el proceso, puede crear en el entorno nuevo aplicaciones web vacías donde realizarla.	Solo se admiten copias de seguridad personalizadas.

Clonación de la aplicación en App Service Environment v3

La clonación de las aplicaciones es otra característica que se puede usar para llevar las aplicaciones de Windows a App Service Environment v3. Las limitaciones de clonación de aplicaciones son las mismas que las de la característica de copia de seguridad de App Service. Para más información, consulte Copia de seguridad de una aplicación en Azure App Service.

Nota:

Solo se admite la clonación de aplicaciones para planes de App Service en Windows.

Se recomienda esta solución para usuarios que usan App Service en Windows y no se pueden migrar mediante la característica de migración. Antes de clonar las aplicaciones, debe configurar el nuevo recurso App Service Environment v3. La clonación de una aplicación puede tardar hasta 30 minutos en completarse.

Para clonar una aplicación mediante PowerShell, consulte las instrucciones.

Para clonar una aplicación mediante Azure Portal:

En Azure Portal, vaya al plan de App Service existente. En Herramientas de desarrollo, seleccione Clonar aplicación.
Rellene los campos obligatorios con los detalles del nuevo recurso App Service Environment v3.
1. En Grupo de recursos:, seleccione un grupo de recursos existente o cree uno nuevo.
2. En Nombre, asigne un nombre a la aplicación. Este nombre puede ser el mismo que el de la aplicación antigua, pero la dirección URL predeterminada del sitio del nuevo entorno será diferente. Debe actualizar cualquier DNS o recursos conectados personalizados para que apunten a la nueva dirección URL.
3. En Región, use el nombre de su instancia de App Service Environment v3.
4. Si quiere clonar el origen de implementación, active la casilla Clonar origen de implementación.
5. En Plan de Windows, puede usar un plan existente de App Service del nuevo entorno si ya ha creado uno, o bien crear otro. Los planes de App Service disponibles en el nuevo recurso App Service Environment v3 aparecen en la lista desplegable.
6. En SKU y tamaño, modifique la memoria y la CPU según sea necesario mediante una de las opciones Aislado v2 si va a crear un nuevo plan de App Service. App Service Environment v3 usa planes Aislado v2, que tienen más memoria y CPU por tamaño de instancia correspondiente en comparación con el plan Aislado. Para más información, consulte Precios de App Service Environment v3.

Screenshot that shows options for cloning an app to App Service Environment v3 by using the portal.

Ventajas	Limitaciones
Puede automatizar la clonación mediante PowerShell.	Solo se admite para planes de App Service en Windows.
Puede clonar varias aplicaciones al mismo tiempo. (La clonación debe configurarse para cada aplicación por separado o mediante un script).	La compatibilidad se limita a determinados tipos de base de datos.
Se realizar la integración con Azure Traffic Manager y Azure Application Gateway para distribuir el tráfico entre los entornos antiguos y nuevos.	Los entornos antiguos y nuevos, así como los recursos compatibles (por ejemplo, aplicaciones, bases de datos, cuentas de almacenamiento y contenedores) deben estar todos en la misma suscripción.

Creación manual de aplicaciones en App Service Environment v3

Si la característica de migración no admite las aplicaciones o quiere seguir una ruta más manual, puede implementar las aplicaciones siguiendo el mismo proceso que usó para la instancia de App Service Environment existente.

Puede exportar plantillas de Azure Resource Manager (plantillas de ARM) de las aplicaciones existentes, de los planes de App Service y de cualquier otro recurso compatible, e implementarlas en el entorno nuevo o con él. Para exportar una plantilla solo para una aplicación, vaya al plan de App Service. En Automatización, seleccione Exportar plantilla.

Screenshot of the option to export a template on the left pane of the Azure portal.

También puede exportar plantillas para varios recursos directamente desde el grupo de recursos. Vaya al grupo de recursos, seleccione los recursos para los que quiere obtener una plantilla y, luego, seleccione Exportar plantilla.

Screenshot of the option for exporting a template for resources from a resource group.

Los siguientes cambios iniciales en las plantillas de ARM son necesarios para llevar las aplicaciones a App Service Environment v3:

Actualizar los parámetros sku de un plan de App Service a un plan Aislado 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
},

Actualizar el parámetro del plan de App Service (serverfarm) en el que se implementará la aplicación al plan asociado a App Service Environment v3.
Actualizar el parámetro del perfil del entorno de hospedaje (hostingEnvironmentProfile) al nuevo identificador de recurso de App Service Environment v3.

Una exportación de plantillas de ARM incluye todas las propiedades que los proveedores de recursos exponen para los recursos. Quite todas las propiedades no necesarias, como las que apuntan al dominio de la aplicación antigua. Por ejemplo, podría simplificar el recurso sites al ejemplo siguiente:

"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')]"
    }
}

Es posible que se requieran otros cambios, en función de cómo haya configurado la aplicación. Por ejemplo, si usa identidades administradas asignadas por el sistema y los mismos nombres de aplicación para los entornos antiguos y nuevos, es posible que se produzcan conflictos. Para resolver este conflicto y evitar el tiempo de inactividad, puede usar una identidad administrada asignada por el usuario.

Puede implementar plantillas de ARM mediante Azure Portal, la CLI de Azure o PowerShell.

Migración manual

La característica de migración local automatiza la migración a App Service Environment v3 y transfiere todas las aplicaciones al entorno nuevo. Durante esta migración hay aproximadamente una hora de tiempo de inactividad. Si las aplicaciones no pueden tener tiempo de inactividad, se recomienda usar la característica de migración en paralelo, que es una opción de migración sin tiempo de inactividad, ya que el nuevo entorno se crea en una subred diferente. Si también decide no usar la característica de migración en paralelo, puede usar una de las opciones manuales para volver a crear las aplicaciones en App Service Environment v3.

Puede distribuir el tráfico entre el entorno antiguo y el nuevo mediante Application Gateway. Si usa un equilibrador de carga interno (ILB), App Service Environment crea una instancia de Azure Application Gateway con un grupo back-end adicional para distribuir el tráfico entre los entornos. Para información sobre las instancias de App Service Environment con ILB y los entornos de App Service accesibles desde Internet, consulte Integración de Application Gateway.

También puede usar servicios como Azure Front Door, Azure Content Delivery Network y Azure Traffic Manager para distribuir el tráfico entre los entornos. El uso de estos servicios permite probar el entorno nuevo de forma controlada y ayuda a migrarlo a su propio ritmo.

Una vez completada la migración y las pruebas con el entorno nuevo, elimine la instancia antigua de App Service Environment, las aplicaciones que contiene y los recursos complementarios que ya no necesite. Se le seguirá cobrando por los recursos que no elimine.

Preguntas más frecuentes

¿Cómo sé si debo migrar a App Service Environment v3 mediante una de las opciones manuales?
Para obtener ayuda para decidir qué opción de migración es adecuada para usted, consulte Árbol de decisión de ruta de migración. Si el entorno cumple los criterios descritos en el árbol de decisión de ruta de migración, considere la posibilidad de usar una de las características de migración automatizadas para lograr una ruta de acceso más rápida a App Service Environment v3. Se recomienda realizar la migración manual si necesita mover lentamente las aplicaciones al nuevo entorno y validarlas durante todo el proceso.
¿Experimentaré tiempo de inactividad durante la migración?
El tiempo de inactividad depende del proceso de migración. Si tiene otra instancia de App Service Environment a la que pueda dirigir el tráfico durante la migración o si puede usar otra subred para crear el nuevo entorno, no tendrá tiempo de inactividad. Si debe usar la misma subred, hay un tiempo de inactividad entre que se elimina el entorno anterior, se crea el recurso App Service Environment v3, se crean los nuevos planes de App Service, se vuelven a crear las aplicaciones y se actualizan los recursos que usan las nuevas direcciones IP.
¿Es necesario cambiar algo sobre mis aplicaciones para que se ejecuten en App Service Environment v3?
No. Las aplicaciones que se ejecutan en App Service Environment v1 y v2 no deberían necesitar ninguna modificación para ejecutarse en App Service Environment v3. Si usa SSL de IP, debe quitar los enlaces SSL de IP antes de migrar.
¿Qué ocurre si mi entorno de App Service Environment tiene un sufijo de dominio personalizado?
La característica de migración admite este escenario de migración. Si no quiere usar la característica de migración, puede realizar la migración mediante un método manual. Puede configurar el sufijo de dominio personalizado cuando cree el recurso App Service Environment v3 o después.
¿Qué pasa si el recurso App Service Environment v2 está anclado en una zona?
El anclado de zona no es una característica admitida en App Service Environment v3. Puede optar por habilitar la redundancia de zona al crear el recurso App Service Environment v3.
¿Qué propiedades de mi entorno de App Service Environment cambiarán?
Revise las diferencias de características entre App Service Environment v3 y las versiones anteriores. En el caso de App Service Environment con ILB, conservará la misma dirección IP de ILB. En el caso de App Service Environment accesible desde Internet, la IP pública y la dirección IP de salida cambiarán.

En App Service Environment accesible desde Internet, anteriormente había una única IP tanto de entrada como de salida. En el caso de App Service Environment v3 estas son independientes. Para obtener más información, vea Redes de App Service Environment v3.
¿Se admite la copia de seguridad y restauración para mover aplicaciones de App Service Environment v2 a v3? La característica de copia de seguridad y restauración admite la restauración de aplicaciones entre versiones de App Service Environment siempre y cuando se use una copia de seguridad personalizada para la restauración. La copia de seguridad automática no admite la restauración a diferentes versiones de App Service Environment.
¿Qué ocurrirá con mis recursos App Service Environment v1/v2 después del 31 de agosto de 2024?
Después del 31 de agosto de 2024, si no ha migrado a App Service Environment v3, sus recursos App Service Environment v1 y v2 y las aplicaciones implementadas en ellos dejarán de estar disponibles.

App Service Environment v1 y v2 se hospedan en unidades de escalado de App Service que se ejecutan en la arquitectura de Azure Cloud Services (clásico). Dado que esta arquitectura se retirará el 31 de agosto de 2024, App Service Environment v1 y v2 no estarán disponibles después de esa fecha. Migre a App Service Environment v3 para que sus aplicaciones sigan funcionando, o guarde o haga una copia de seguridad de los recursos o datos que necesite mantener.