Reubicar Azure Static Web Apps en otra región

En este artículo se describe cómo reubicar recursos de Azure Static Web Apps 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.

Requisitos previos

Revise los siguientes requisitos previos antes de prepararse para la reubicación.

• Compruebe que Azure Static Web Apps está disponible en la región de destino.

• Asegúrese de que tiene permiso para crear recursos de Static Web App en la región de destino.

• Averigüe si se aplican restricciones de región de Azure Policy a su organización.

• Si usa la compatibilidad de API integrada proporcionada por Azure Functions:

  • Determine la disponibilidad de Azure Functions en la región de destino.
  • Determine si se usan claves de API de función. Por ejemplo, ¿usa Key Vault o lo implementa como parte de los archivos de configuración de la aplicación?
  • Determine el modelo de implementación para la compatibilidad con api en la región de destino: Traiga sus propias funciones. Comprenda las diferencias entre los dos modelos.

• Asegúrese de que el plan de hospedaje estándar se usa para hospedar la aplicación web estática. Para más información sobre los planes de hospedaje, consulte planes de hospedaje de Azure Static Web Apps.

• Determine el tiempo de inactividad permitido para la reubicación.

• En función de la implementación de la Azure Static Web App, es posible que sea necesario implementar y configurar los siguientes recursos dependientes en la región de destino antes para la reubicación:

  • Azure Functions.
  • Azure Virtual Network
  • Azure Front Door
  • Grupo de seguridad de red (NSG)
  • Servicio Azure Private Link
  • Azure Key Vault
  • Cuenta de Azure Storage
  • Introducción a Puerta de enlace de aplicaciones

Tiempo de inactividad

La reubicación de un sitio web estático de Azure presenta un tiempo de inactividad para la aplicación. El tiempo de inactividad se ve afectado por el patrón de alta disponibilidad que ha implementado para el sitio web estático de Azure. Los patrones generales son:

• Espera inactiva: los datos de carga de trabajo se realiza una copia de seguridad periódicamente en función de sus requisitos. En caso de desastre, la carga de trabajo se vuelve a implementar en una nueva región de Azure y se restauran los datos.
• Estado de espera semiactiva: la carga de trabajo se implementa en la región de continuidad empresarial y recuperación ante desastres (BCDR), y los datos se replican de forma asincrónica o sincrónica. En caso de desastre, la implementación en la región de recuperación ante desastres (DR) se escala vertical y horizontalmente.
• Varias regiones: la carga de trabajo se implementa en ambas regiones y los datos se replican sincrónicamente. Ambas regiones tienen una copia grabable de los datos. La implementación puede ser activa/pasiva o activa/activa.

Preparación

Implementaciones con puntos de conexión privados

Si Azure Static Web Apps se implementa con puntos de conexión privados, asegúrese hacer lo siguiente:

• Actualizar el nombre de host para el punto de conexión.
• Actualizar el nombre de host en la zona privada DNS o en el servidor DNS personalizado (solo se aplica a Private Link).

Para más información, consulte Configuración del punto de conexión privado en Azure Static Web Apps.

Todas las demás implementaciones

Para todos los demás tipos de implementación, asegúrese de lo siguiente:

• Si procede, recupere las nuevas claves de Function API de Azure Functions en la nueva región.

• Si la función de Azure tiene una dependencia en una base de datos, asegúrese de que DATABASE_CONNECTION_STRING se actualice. Esta base de datos puede no estar en el ámbito de la migración regional.

• Actualice el dominio personalizado para que apunte al nuevo nombre de host de la aplicación web estática.

• Si usa Key Vault, aprovisione una nueva instancia de Key Vault en la región de destino. Actualice las claves de Function API en Key Vault si procede. Cualquier otra información confidencial que no se almacene en el código o los archivos de configuración debe almacenarse en esta instancia de Key Vault.

Exportación de la plantilla

Para exportar la plantilla de Resource Manager que contiene la configuración que describe la aplicación web estática:

1. Inicie sesión en Azure Portal.

2. Vaya a la aplicación web estática.

3. En el menú de la izquierda, en Automatización, seleccione Exportar plantilla.

   La plantilla puede tardar un momento en generarse.

4. Seleccione Descargar.

5. Busque el archivo .zip descargado y ábralo en una carpeta de su elección.

   Este archivo contiene los archivos .json que incluyen la plantilla y los scripts para implementar la plantilla.

6. Realice los cambios necesarios en la plantilla, como actualizar la ubicación con la región de destino.

Reubicar

Siga estos pasos para reubicar la aplicación web estática en otra región.

1. Si va a reubicar con el punto de conexión privado, siga las instrucciones de Reubicación del servicio Azure Private Link en otra región.

2. Si ha proporcionado una instancia de Azure Functions existente a la aplicación web estática, siga el procedimiento de reubicación de Azure Functions.

3. Vuelva a implementar la aplicación web estática mediante la plantilla de que exportó y configuró en la sección anterior.

   Importante

   Si no usa un dominio personalizado, la dirección URL de la aplicación cambia en la región de destino. En este escenario, asegúrese de que los usuarios conozcan el cambio de dirección URL.

4. Si usa una API integrada, cree una nueva API integrada compatible con Azure Functions.

5. Vuelva a configurar el repositorio (GitHub o Azure DevOps) para implementarlo en la aplicación web estática recién implementada en la región de destino. Inicie la implementación de la aplicación mediante acciones de GitHub o Azure Pipelines.

6. Con una implementación de espera inactiva, asegúrese de informar a los clientes sobre la nueva dirección URL. Si usa un dominio DNS personalizado, simplemente cambie la entrada DNS para que apunte a la región de destino. Con una implementación de estado de espera semiactiva, un equilibrador de carga, como Front Door o Traffic Manager, controla la migración de la aplicación web estática en la región de origen a la región de destino.