Compartir a través de

Reubicar Azure App Services en otra región

  • Artículo

En este artículo, se explica cómo pueden trasladarse los recursos de App Service a otra región de Azure.

Hay varias razones por las que puede desear 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
  • Cumpla los requisitos de planeamiento de capacidad.

Los recursos de App Service son específicos de una región y no pueden moverse entre regiones. Debe crear una copia de los recursos de App Service existentes en la región de destino y, a continuación, reubicar el contenido en la nueva aplicación. Si la aplicación de origen usa un dominio personalizado, puede migrarla a la nueva aplicación en la región de destino después de completar la reubicación.

Para facilitar la copia de la aplicación, puede hacer copias de seguridad y restauración de una aplicación de App Service individual en un plan de App Service en otra región.

Requisitos previos

  • Asegúrese de que la aplicación de App Service esté en la región de Azure desde la que va a trasladarla.
  • Compruebe que la región de destino admite App Service y los servicios relacionados, cuyos recursos desea trasladar.
  • Compruebe que existe un permiso suficiente para implementar recursos de App Service en la suscripción y región de destino.
  • Valide si se asigna alguna directiva de Azure con una restricción de región.
  • Tenga en cuenta los costos operativos, ya que los precios de los recursos de proceso pueden variar de una región a otra. Para calcular los posibles costos, consulte la calculadora de precios.

Preparación

Identifique todos los recursos de App Service que utiliza actualmente. Por ejemplo:

Ciertos recursos, como los certificados importados o las conexiones híbridas, tienen elementos que están integrados con otros servicios de Azure. Para más información acerca de cómo migrar esos recursos entre regiones, consulte la documentación de los servicios correspondientes.

Plan

Esta sección es una lista de comprobación de planificación en las siguientes áreas:

  • Dependencias de estado, almacenamiento y bajada
  • Certificados
  • Configuración
  • Conectividad de red virtual/ nombres personalizados/DNS
  • Identidades
  • Puntos de conexión de servicio

Dependencias de estado, almacenamiento y bajada

  • Determine si la aplicación de App Service tiene estado o no. Aunque se recomienda que las aplicaciones de App Service no tengan estado y que los archivos de la unidad de %HOME%\site solo deben ser los necesarios para ejecutar la aplicación implementada con archivos temporales, todavía es posible almacenar el estado de la aplicación en tiempo de ejecución en la unidad virtual %HOME%\site. Si la aplicación escribe el estado en la ruta de acceso de almacenamiento compartido de la aplicación, asegúrese de planear cómo va a administrar ese estado durante un traslado de recursos.

    Sugerencia

    Puede usar Kudu para, junto con el acceso al portal, proporcionar una API de acceso a archivos (Sistema de archivos virtual (VFS)) que pueda leer y escribir archivos en el directorio %HOME%\site. Para más información, vea la wiki de Kudu.

  • Compruebe el estado y el almacenamiento en caché interno en el código de la aplicación.

  • Deshabilite la configuración de afinidad de sesión. Siempre que sea posible, se recomienda deshabilitar la configuración de afinidad de sesión. Esto mejora el equilibrio de carga para un escalado horizontal. Cualquier estado interno puede afectar a la planeación de la ordenación de una carga de trabajo, especialmente si se requiere un tiempo de inactividad de cero. Siempre que sea posible, puede ser beneficioso refactorizar cualquier estado de aplicación para que la aplicación no tenga estado como preparación para el traslado.

  • Analice las cadenas de conexión de la base de datos. Las cadenas de conexión de base de datos se pueden encontrar en la configuración de la aplicación. Sin embargo, también pueden codificarse o administrarse de forma rígida en los archivos de configuración que se incluyen con la aplicación. Analice y planee la migración o replicación de datos como parte del planeamiento de nivel superior para mover la carga de trabajo. En el caso de las aplicaciones críticas de chatty o latencia, no es eficaz que la aplicación de la región de destino vuelva a llegar a los orígenes de datos de la región de origen.

  • Analice el almacenamiento en caché externo (por ejemplo, Redis). Las cachés de aplicaciones deben implementarse lo más cerca posible de la aplicación. Analice cómo se rellenan las memorias caché, las directivas de expiración o expulsión y cualquier impacto que pueda tener una caché en frío en los primeros usuarios para acceder a la carga de trabajo después de la migración.

  • Analice y planee las dependencias de API (o aplicación) la comunicación entre regiones es significativamente menos eficaz si la aplicación de la región de destino vuelve a las dependencias que todavía están en la región de origen. Se recomienda reubicar todas las dependencias de bajada como parte de la reubicación de la carga de trabajo. Sin embargo, los recursos *locales* son la excepción, en particular aquellos recursos que están geográficamente más cerca de la región de destino (como puede ser el caso de escenarios de repatriación).

    Azure Container Registry puede ser una dependencia de nivel inferior (runtime) para App Service configurada para ejecutarse en imágenes de contenedor personalizadas. Tiene más sentido que Container Registry esté en la misma región que la aplicación. Puede cargar las imágenes necesarias en un nuevo ACR en la región get de destino. De lo contrario, considere la posibilidad de usar la característica de replicación geográfica si planea mantener las imágenes en la región de origen.

  • Analice y planee los servicios regionales. Los datos de Application Insights y Log Analytics son servicios regionales. Plantéese crear un nuevo almacenamiento de Application Insights y Log Analytics en la región de destino. Para Application Insights, un nuevo recurso también afecta a la cadena de conexión que se debe actualizar como parte del cambio en App Configuration.

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.

Información adicional que se debe tener en cuenta:

  • Se pueden usar direcciones asignadas por la aplicación, donde una conexión SSL de la aplicación de App Service está enlazada a una dirección IP específica designada por la aplicación, para permitir llamadas de lista de permitidos desde redes de terceros en App Service. Por ejemplo, un administrador de TI o red puede bloquear las llamadas salientes desde una red local o una red virtual para usar una dirección estática y conocida. Por lo tanto, si la característica Dirección asignada por la aplicación está en uso, las reglas de firewall ascendentes (como interna, externa o de terceros) para los autores de llamadas en la aplicación deben comprobarse e informarse de la nueva dirección. Las reglas de firewall pueden ser internas, externas o de terceros (como asociados o clientes conocidos).

  • Respecto a cualquier aplicación virtual de red ascendente (NVA) o proxy inverso, puede que tenga que cambiar la configuración de NVA si va a escribir el encabezado de host o la terminación SSL.

Nota:

App Service Environment es la única oferta de App Service que permite llamadas de bajada a dependencias de aplicaciones de bajada a través de SSL, donde SSL se basa en PKI o certificados autofirmados creados con certificados de CA raíz no estándar. El servicio multiinquilino no proporciona acceso para que los clientes carguen en el almacén de certificados de confianza.

En la actualidad, App Service Environment no permite la compra de certificados SSL, solo le permite traer sus propios certificados. No se permite IP-SSL (que tampoco tendría sentido), pero sí SNI. App Service Environment interno no se asociaría a un dominio público y, por tanto, el cliente debe proporcionar los certificados SSL utilizados, que, por ello, son transportables (por ejemplo, certificados para uso interno generados mediante PKI). App Service Environment v3 en modo externo comparte las mismas características que App Service multiinquilino normal.

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.

  • Asegúrese de comprobar cualquier configuración de archivo de disco, que puede invalidar o no la configuración de la aplicación.

Conectividad de red virtual/ nombres personalizados/DNS

  • App Service Environment es un servicio de inquilino único insertado en una red virtual. Las redes de App Service Environment difieren del multiinquilino de App Service, lo que requiere uno o ambos “puntos” de conexión privados o “integración” de red virtual regional. Otras opciones incluyen la integración de red virtual basada en VPN P2S heredada y conexiones híbridas (un servicio de Azure Relay).

    Nota:

    Las redes ASEv3 están simplificadas: el tráfico de administración de Azure y las dependencias de bajada de App Service Environment no son visibles para la red virtual del cliente, lo que simplifica considerablemente la configuración necesaria cuando el cliente usa un túnel forzado para todo el tráfico o envía un subconjunto de tráfico saliente a través de una aplicación virtual de red o firewall.

    Las conexiones híbridas (Azure Relay) son regionales. Si se usan conexiones híbridas y aunque se puede mover un espacio de nombres de Azure Relay a otra región, sería más sencillo volver a implementar la conexión híbrida (asegúrese de que la conexión híbrida está configurada en la nueva región en la implementación de los recursos de destino) y volver a vincularla al Administrador de conexiones híbridas. La ubicación del Administrador de conexiones híbridas debe tenerse en cuenta cuidadosamente.

  • Siga la estrategia de una región en estado de espera semiactiva. Asegúrese de que las redes y la conectividad principales, la red del concentrador, los controladores de dominio, DNS, VPN o ExpressRoute, etcetera., estén presentes y probados antes de la reubicación de recursos.

  • Valide las ACL de red ascendentes o descendentes y las de configuración. Por ejemplo, considere un servicio externo de bajada que solo permita la lista de tráfico de la aplicación. Una reubicación en un nuevo plan de aplicación para una instancia multiinquilino de App Service también sería un cambio en las direcciones IP salientes.

  • En la mayoría de los casos, es mejor asegurarse de que las redes virtuales de la región de destino tienen un espacio de direcciones único. Un espacio de direcciones único facilita la conectividad de red virtual si es necesario, por ejemplo, para replicar datos. Por lo tanto, en estos escenarios hay un requisito implícito para cambiar:

    • DNS privado
    • Cualquier configuración externa o codificada de forma rígida que haga referencia a los recursos por dirección IP (sin un nombre de host)
    • ACL de red, incluidos los grupos de seguridad de red y la configuración del firewall (tenga en cuenta el impacto en las NVA locales aquí también)
    • Cualquier regla de enrutamiento, tablas de rutas definidas por el usuario

    Además, asegúrese de comprobar la configuración, incluidos los intervalos IP específicos de la región o las etiquetas de servicio si llevan a cabo recursos de implementación de DevOps existentes.

  • Se requieren menos cambios para el DNS privado implementado por el cliente que está configurado para reenviar a Azure para dominios de Azure y a Azure DNS Private Zones. Sin embargo, dado que los puntos de conexión privados se basan en un FQDN de recursos y esto suele ser también el nombre del recurso (que se puede esperar que sea diferente en la región de destino), recuerde hacer una verificación cruzada de la configuración para asegurarse de que los FQDN a los que se hace referencia en la configuración se actualizan en consecuencia.

  • Vuelva a crear puntos de conexión privados, si se usan, en la región de destino. Lo mismo se aplica a la integración con red virtual regional.

  • DNS para App Service Environment se administra normalmente a través de la solución DNS personalizada privada de los clientes (hay una invalidación de configuración manual disponible en cada aplicación básica). App Service Environment proporciona un equilibrador de carga para la entrada y salida, mientras que App Service filtra los encabezados de host. Por lo tanto, se pueden apuntar varios nombres personalizados hacia el mismo punto de conexión de entrada de App Service Environment. App Service Environment no requiere validación de dominio.

    Nota:

    El punto de conexión de Kudu para App Service Environment v3 solo está disponible en {resourcename}.scm.{asename}.appserviceenvironment.net. Para obtener más información sobre DNS y redes de App Service Environment v3, etc., consulte Redes de App Service Environment.

    Para App Service Environment, el cliente posee el enrutamiento y, por tanto, los recursos usados para la migración. Siempre que se habilite el acceso a App Service Environment externamente —normalmente a través de una aplicación virtual de red de nivel 7 o proxy inverso— se puede usar Traffic Manager, Azure Front Door u otros servicios de equilibrio de carga global L7.

  • Para la versión multiinquilino pública del servicio, se aprovisiona un nombre predeterminado {resourcename}.azurewebsites.net para los puntos de conexión del plano de datos, junto con un nombre predeterminado para el punto de conexión de Kudu (SCM). Como el servicio proporciona un punto de conexión público de forma predeterminada, el enlace debe comprobarse para demostrar la propiedad del dominio. Sin embargo, una vez implementado el enlace, no es necesario volver a comprobarlo. Tampoco es necesario para que los registros DNS públicos apunten al punto de conexión de App Service.

  • Si usa 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.

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.

  • Plan para reasignar el proveedor de identidades (IDP) a la región de destino. Aunque Microsoft Entra ID es un servicio global, algunas soluciones dependen de un IDP local (o de bajada local).

  • Actualizar los recursos a App Service que puedan confiar en las credenciales de FTP de Kudu.

Puntos de conexión del servicio

Los puntos de conexión de servicio de red virtual para Azure App Service restringen el acceso a una red virtual especificada. También permiten restringir el acceso a una lista de intervalos de direcciones IPv4 (protocolo de Internet, versión 4). Se deniega el acceso a cualquier usuario que se conecte a Event Hubs desde fuera de esos orígenes. Si los puntos de conexión de servicio se configuraron en la región de origen del recurso de Event Hubs, tendría que hacerse lo mismo en el destino.

Para una recreación correcta de Azure App Service en la región de destino, la red virtual y la subred deben crearse de antemano. En caso de que el traslado de estos dos recursos se realice con la herramienta Azure Resource Mover, los puntos de conexión de servicio no se configurarán automáticamente. Por lo tanto, deben configurarse manualmente. Puede hacerlo a través del Azure Portal, la CLI de Azure o Azure PowerShell.

Reubicar

Para reubicar los recursos de App Service, puede usar Azure Portal o Infraestructura como código (IaC).

Reubicación mediante Azure Portal

La mayor ventaja de usar Azure Portal para la reubicación es su simplicidad. La aplicación, el plan y el contenido, así como muchas configuraciones se clonan en el nuevo recurso y plan de App Service.

Tenga en cuenta que, en el caso de los niveles de App Service Environment (aislado), debe volver a implementar toda la instancia de App Service Environment en otra región y, después, puede empezar a implementar los planes individuales en el nuevo App Service Environment en la nueva región.

Para reubicar los recursos de App Service en una nueva región mediante Azure Portal:

  1. Cree una copia de seguridad de la aplicación de origen.
  2. Cree una aplicación en un nuevo plan de App Service de la región de destino.
  3. Restaure la copia de seguridad en la aplicación de destino.
  4. Si usa un dominio personalizado, vincúlelo preferentemente a la aplicación de destino con asuid. y habilite el dominio en la aplicación de destino.
  5. Configure el resto del contenido de la aplicación de destino para que esté igual que en la aplicación de origen y compruebe la configuración.
  6. Cuando tenga todo preparado para que el dominio personalizado apunte a la aplicación de destino, reasigne el nombre de dominio.

Reubicación mediante IaC

Use IaC cuando exista una canalización de integración continua y entrega continua (CI/CD) existente o se pueda crear. Con una canalización de CI/CD, el recurso de App Service se puede crear en la región de destino mediante una acción de implementación o una implementación zip de Kudu.

Los requisitos del Acuerdo de Nivel de Servicio deben determinar cuánto esfuerzo adicional se requiere. Por ejemplo: ¿Se trata de una reimplementación con tiempo de inactividad limitado o se requiere una migración casi en tiempo real con un tiempo de inactividad mínimo o sin tiempo de inactividad?

La inclusión de servicios perimetrales externos y globales de enrutamiento de tráfico, como Traffic Manager o Azure Front Door, ayudan a facilitar la migración de usuarios y aplicaciones externos.

Sugerencia

Es posible usar Traffic Manager (ATM) al conmutar por error App Services detrás de puntos de conexión privados. Aunque los sondeos de Traffic Manager no pueden acceder a los puntos de conexión privados, si se degradan todos los puntos de conexión, ATM permite el enrutamiento. Para más información, consulte Control del tráfico de Azure App Service con Azure Traffic Manager.

Validación

Una vez completada la reubicación, pruebe y valide Azure App Service con las directrices recomendadas:

  • Una vez que Azure App Service se reubica en la región de destino, ejecute una prueba de integración y humo. Puede probar o ejecutar manualmente una prueba con un script. Asegúrese de validar que todas las configuraciones y los recursos dependientes estén correctamente vinculados y que todos los datos configurados sean accesibles.

  • Valide todos los componentes e integración de Azure App Service.

  • Realice pruebas de integración en la implementación de la región de destino, incluidas todas las pruebas de regresión formales. Las pruebas de integración deben alinearse con el ritmo habitual de los procesos de implementación y prueba empresariales aplicables a la carga de trabajo.

  • En algunos escenarios, especialmente cuando la reubicación incluye actualizaciones, cambios en las aplicaciones o recursos de Azure o un cambio en el perfil de uso, use pruebas de carga para validar que la nueva carga de trabajo es adecuada para su fin. Las pruebas de carga también son una oportunidad para validar las operaciones y la cobertura de supervisión. Por ejemplo, use pruebas de carga para validar que la infraestructura y los registros de aplicación necesarios se generan correctamente. Las pruebas de carga deben medirse con las líneas base de rendimiento de carga de trabajo establecidas.

Sugerencia

Una reubicación de App Service también es una oportunidad para volver a evaluar la disponibilidad y la planificación de la recuperación ante desastres. App Service y App Service Environment (App Service Environment v3) admiten zonas de disponibilidad. Se recomienda configurar con una zona de disponibilidad. Descubra cuáles son los requisitos previos para la implementación, los precios y las limitaciones y téngalos en cuenta en el planeamiento del traslado de recursos. Para más información sobre las zonas de disponibilidad y App Service, consulte confiabilidad de Azure App Service.

Limpiar

Elimine la aplicación y el plan de App Service de origen. Los planes de App Service de los niveles que no son gratuitos generan cargos aunque no se ejecute ninguna aplicación en ellos.

Pasos siguientes

Clonación de aplicaciones de Azure App Service mediante PowerShell