Compartir a través de

Reubicar la aplicación de funciones a otra región de Azure

  • Artículo

En este artículo se describe cómo mover una aplicación de funciones alojada en Azure Functions a otra región de Azure.

Hay varias razones por las que sería conveniente mover los recursos de Azure existentes de una región a otra. Quizá también desea:

  • Aproveche las ventajas de una nueva región de Azure.
  • Implemente características o servicios que solo están disponibles en regiones determinadas.
  • Cumpla requisitos internos de gobernanza y directivas.
  • Alineación con fusiones y adquisiciones de la empresa
  • Cumplir los requisitos de planeamiento de capacidad.

Los recursos de Azure que alojan su aplicación de funciones son específicos de cada región y no pueden moverse de una región a otra. En su lugar, debe crear una copia de sus recursos de aplicación de funciones existentes en la región de destino, y luego volver a implementar el código de sus funciones en la nueva aplicación.

Puede mover estos mismos recursos a otro grupo de recursos o suscripción, siempre y cuando permanezcan en la misma región. Para obtener más información, vea Traslado de recursos de App Service a un nuevo grupo de recursos o suscripción.

Requisitos previos

  • Asegúrese de que la región de destino admite Azure Functions y cualquier servicio relacionado cuyos recursos desee mover.
  • Asegúrese de que tiene privilegios para crear los recursos necesarios en la nueva región.

Preparación

Identificar todos los recursos de la aplicación de funciones utilizados en la región de origen, lo que potencialmente incluye:

Al preparar el traslado de su aplicación a una nueva región, hay algunas partes de la arquitectura que requieren especial consideración y planificación.

Nombre de la aplicación de funciones

Los nombres de las aplicaciones de función deben ser globalmente únicos para todas las aplicaciones Azure. Esto significa que su nueva aplicación funcional no puede tener el mismo nombre y URL que la original. Esto es cierto incluso cuando se utiliza un DNS personalizado, porque el subyacente <APP_NAME>.azurewebsites.net debe seguir siendo único. Es posible que tenga que actualizar los clientes que se conectan a los puntos de conexión HTTP en su aplicación de función. Estos clientes deben utilizar la nueva URL cuando realicen solicitudes.

Código fuente

Lo ideal es mantener el código fuente en un repositorio de código de algún tipo, o en un repositorio contenedor si se ejecuta en un contenedor Linux. Si está utilizando la implementación continua, planifique cambiar la conexión de implementación del repositorio o contenedor a la nueva dirección de la aplicación de funciones. Si, por alguna razón, ya no dispone del código fuente, puede descargar el paquete en ejecución desde la aplicación de la función original. Recomendamos almacenar los archivos fuente en un repositorio de código y utilizar la implementación continua para las actualizaciones.

Cuenta de almacenamiento predeterminada

Las funciones de host requieren una cuenta de Azure Storage. Para más información, consulte Requisitos de la cuenta de almacenamiento. Para obtener el mejor rendimiento, la aplicación de funciones debe utilizar una cuenta de almacenamiento en la misma región. Al crear una nueva aplicación con una nueva cuenta de almacenamiento en su nueva región, su aplicación obtiene un nuevo conjunto de claves de acceso a funciones y se restablece el estado de cualquier activador (como los activadores de temporizador).

Almacenamiento local persistente

Se pretende que las ejecuciones de las funciones sean sin estado. Sin embargo, no le impedimos escribir datos en el sistema de archivos local. Es posible almacenar datos generados y utilizados por su aplicación en la unidad virtual %HOME%\site, pero estos datos no deben estar relacionados con el estado. Si su escenario requiere que mantenga el estado entre ejecuciones de funciones, considere en su lugar el uso de Durable Functions.

Si su aplicación persiste los datos a la ruta de almacenamiento compartido de la aplicación, asegúrese de planificar cómo va a administrar ese estado durante un movimiento de recursos. Tenga en cuenta que para las aplicaciones del plan Dedicado (App Service), la cuota forma parte del sitio. Para los planes Consumo y Premium, el recurso compartido es, por defecto, un recurso compartido de Azure Files en la cuenta de almacenamiento predeterminada. Las aplicaciones que se ejecutan en Linux pueden estar utilizando un recurso compartido montado explícitamente para el almacenamiento persistente.

Servicios conectados

Sus funciones pueden conectarse a Azure Services y otros recursos utilizando un SDK de servicio o desencadenadores y vínculos. Cualquier servicio conectado puede verse afectado negativamente cuando la aplicación se traslada a una nueva región. Si la latencia o el ancho de banda son problemas, considere la posibilidad de mover también cualquier servicio conectado a la nueva región. Para saber cómo mover esos recursos entre regiones, consulte la documentación de los respectivos servicios. Al trasladar una aplicación con servicios conectados, es posible que desee considerar una estrategia de recuperación ante desastres y continuidad de negocio entre regiones durante el traslado.

Los cambios en los servicios conectados pueden requerir que actualice los valores almacenados en la configuración de su aplicación, que se utilizan para conectarse a esos servicios.

Configuración

  • Puede capturar una instantánea de la configuración de la aplicación existente y las cadenas de conexión desde Azure Portal. Expanda Configuración>Variables de entorno, seleccione Edición avanzada en Configuración de la aplicación o Cadenas de conexiones y guarde la salida JSON que contiene la configuración o las conexiones existentes. Debe volver a crear esta configuración en la nueva región, pero es probable que los propios valores cambien como resultado de los cambios de región posteriores en los servicios conectados.

  • Las referencias de Key Vault existentes no se pueden exportar a través de un límite geográfico de Azure. Debe volver a crear las referencias necesarias en la nueva región.

  • La configuración de la aplicación puede administrarse mediante Azure App Configuration o desde alguna otra dependencia de base de datos central (de bajada). Revise cualquier almacén de App Configuration o almacenes similares para conocer la configuración específica del entorno y la región que podrían requerir modificaciones.

Dominios personalizados

Si su aplicación funcional utiliza un dominio personalizado, enlácelo de forma preventiva a la aplicación de destino. Compruebe y habilite el dominio en la aplicación de destino. Tras el traslado, debe volver a asignar el nombre de dominio.

Redes virtuales

Azure Functions le permite integrar las aplicaciones con recursos de red virtual e incluso ejecutarlas en una red virtual. Para obtener más información, vea las opciones de red de Azure Functions. Al trasladarse a una nueva región, primero debe trasladar o volver a crear todos los recursos de red y subred virtuales necesarios antes de implementar su aplicación. Esto incluye mover o recrear cualquier punto de conexión privado y puntos de conexión de servicio.

Identidades

  • Debe volver a crear las identidades administradas asignadas por el sistema junto con la aplicación en la nueva región de destino. Normalmente, una aplicación de Microsoft Entra ID creada automáticamente, usada por EasyAuth, tiene como valor predeterminado el nombre del recurso de la aplicación.

  • Las identidades administradas asignadas por el usuario tampoco se pueden mover entre regiones. Para mantener las identidades administradas asignadas por el usuario en el mismo grupo de recursos con la aplicación, debe volver a crearlas en la nueva región. Para obtener más información, consulte Reubicación de identidades administradas para recursos de Azure en otra región.

  • Conceda a las identidades administradas los mismos permisos en los servicios reubicados que a las identidades originales a las que sustituyen, incluida la pertenencia a grupos.

Certificados

Los recursos de certificado de App Service se pueden mover a un nuevo grupo de recursos o suscripción, pero no entre regiones. Los certificados que pueden exportarse también pueden importarse a la aplicación o a Key Vault en la nueva región. Este proceso de exportación e importación es equivalente a un movimiento entre regiones.

Hay diferentes tipos de certificados que deben tenerse en cuenta a la hora de planificar el traslado de servicios:

Tipo de certificado Exportable Comentarios
Administrados por App Service No Vuelva a crear estos certificados en la nueva región.
Administrados por Azure Key Vault Sí Estos certificados se pueden exportar desde Key Vault, y luego importarse a Key Vault en la nueva región.
Clave privada (auto administrados) Sí Los certificados adquiridos fuera de Azure se pueden exportar desde App Service, y luego importarlos en la nueva aplicación o en Key Vault en la nueva región.
Clave pública No Es posible que la aplicación tenga certificados solo con una clave pública y sin secreto, que se usan para acceder a otros puntos de conexión protegidos. Obtenga los archivos de certificado de clave pública necesarios e impórtelos en la aplicación en la nueva región.

Claves de acceso

Functions utiliza claves de acceso para dificultar el acceso a los puntos de conexión HTTP en su aplicación de funciones. Estas claves se mantienen cifradas en la cuenta de almacenamiento predeterminada. Al crear una nueva aplicación en la nueva región, se crea un nuevo conjunto de claves. Debe actualizar los clientes existentes que usen claves de acceso para usar las nuevas claves en la nueva región. Aunque debe usar las nuevas claves, es posible volver a crear las claves antiguas en la nueva aplicación. Para más información, consulte Work with access keys in Azure Functions (Trabajo con claves de acceso en Azure Functions).

Tiempo de inactividad

Si el tiempo de inactividad mínimo es un requisito, considere la posibilidad de ejecutar su aplicación de funciones en ambas regiones, como se recomienda para implementar una arquitectura de recuperación ante desastres. La arquitectura específica que implemente dependerá de los tipos de activadores de su aplicación de funciones. Para obtener más información, consulte Confiabilidad en Azure Functions.

Durable Functions

La extensión Durable Functions permite definir orquestaciones en las que el estado se mantiene en las ejecuciones de las funciones mediante entidades con estado. Lo ideal es que permita que las orquestaciones en ejecución se completen antes de migrar su aplicación Durable Functions, especialmente cuando planea cambiar a una nueva cuenta de almacenamiento en la nueva región. Al migrar las aplicaciones de Durable Functions, considere la posibilidad de usar una de estas estrategias de recuperación ante desastres y distribución geográfica.

Reubicar

Para volver a crear su aplicación de función en una nueva región, primero debe volver a crear la infraestructura Azure de un plan App Service, una instancia de aplicación de función y los recursos relacionados, como redes virtuales, identidades y ranuras. También debe volver a conectar o, en la nueva región, volver a crear los recursos de Azure necesarios para la aplicación. Estos recursos pueden incluir la cuenta de Azure Storage predeterminada y la instancia de Application Insights.

A continuación, puede empaquetar y volver a desplegar el código fuente o el contenedor de la aplicación real en la aplicación funcional que se ejecuta en la nueva región.

Vuelva a crear su infraestructura Azure

Hay varias formas de crear una aplicación de función y recursos relacionados en Azure en la región de destino:

  • Plantillas de implementación: si ha implementado originalmente la aplicación de funciones mediante archivos de infraestructura como código (IaC) (Bicep, plantillas de ARM o Terraform), puede actualizar esas implementaciones anteriores para dirigirse a la nueva región y usarlas para volver a crear recursos en la nueva región. Si ya no tiene estos archivos de implementación, siempre puede descargar una plantilla ARM para el grupo de recursos existente desde Azure Portal.
  • Scripts de la CLI o PowerShell de Azure: si ha implementado originalmente la aplicación de funciones mediante la CLI de Azure o scripts de Azure PowerShell, puede actualizar estos scripts para dirigirse a la nueva región y ejecutarlos de nuevo. Si ya no dispone de estos scripts, también puede descargar una plantilla ARM para su grupo de recursos existente desde el Azure Portal.
  • Azure Portal: si creó la aplicación de funciones en el portal originalmente o no se siente cómodo con scripts o archivos IaC, puede volver a crear todo en el portal. Asegúrese de usar el mismo plan de hospedaje, idioma de ejecución y la versión de idioma que la aplicación original.

Revisión de los recursos configurados

Revise y configure los recursos identificados en el paso anterior de Preparación en la región de destino si no se configuraron durante la implementación. Si utiliza la implementación continua con autenticación de identidad administrada, asegúrese de que las identidades y asignaciones de funciones necesarias existan en la nueva aplicación de funciones.

Vuelva a distribuir el código fuente

Ahora que tiene la infraestructura en su lugar, puede volver a empaquetar e implementar el código fuente en la aplicación de funciones. Este es un buen momento para mover el código fuente o la imagen de contenedor a un repositorio y habilitar la implementación continua desde ese repositorio.

También puede usar cualquier otro método de publicación compatible con Functions. La mayoría de las herramientas de publicación requieren que habilite la autenticación básica en el scm punto de conexión, lo que no es recomendable para aplicaciones de producción.

Consideraciones sobre reubicación

  • No olvide verificar su configuración y probar sus funciones en la región de destino.
  • Si tenía configurado un dominio personalizado, vuelva a asignar el nombre de dominio.
  • En el caso de una aplicación funcional que se ejecute en un plan Dedicado (App Service), revise también el Plan de migración de App Service cuando el plan esté compartido con una o más aplicaciones web.

Limpiar

Una vez completado el traslado, elimine la aplicación de funciones y el plan de hospedaje de la región de origen. Paga por las aplicaciones de funciones en Premium o Planes dedicados, incluso cuando la propia aplicación no se está ejecutando. Si ha vuelto a crear otros servicios en la nueva región, también debe eliminar los servicios anteriores después de que esté seguro de que ya no son necesarios.

Consulte el Centro de arquitectura de Azure para ver ejemplos de aplicación de funciones que se ejecutan en varias regiones como parte de arquitecturas de soluciones más avanzadas y redundancia geográfica.