Reubicación de Azure Container Apps en otra región

En este artículo se describe cómo reubicar una carga de trabajo de Azure Container Apps en otra región de Azure mediante la recreación del entorno administrado y las aplicaciones de contenedor en la región de destino. El proceso abarca la exportación de la configuración de la aplicación, la reimplementación de recursos, la validación de la implementación y la limpieza de recursos en la región de origen.

Prerrequisitos

Antes de comenzar, compruebe que cumple los siguientes requisitos:

• Azure Container Apps está disponible en la región de destino.
• La región de destino admite las mismas características de Container Apps, perfiles de carga de trabajo y opciones de red que se usan en la región de origen.
• Tiene cuota suficiente en la región de destino para los recursos que planea implementar.
• Tiene los permisos siguientes en las suscripciones de origen y de destino:
  • Propietario o Colaborador en el grupo de recursos.
  • Colaborador de Container Apps (recomendado). Este rol incluye permisos comodines que otorgan acceso a valores secretos de Aplicaciones Contenedor. Para un acceso más restringido, véase Permisos para gestionar secretos.
• Las imágenes de contenedor están en un registro accesible desde la región de destino (por ejemplo, Azure Container Registry o un registro externo compatible).
• Los recursos de Azure dependientes, como Key Vault, cuentas de almacenamiento, bases de datos, redes virtuales y servicios de mensajería, ya están disponibles en la región de destino o tienen un plan de reimplementación.

az acr replication create --registry <REGISTRY_NAME> --location <TARGET_REGION>

Descripción de los requisitos de tiempo de inactividad

Azure Container Apps no admite la migración de regiones activas. El tiempo de inactividad se basa principalmente en la propagación de DNS y los cambios de enrutamiento del tráfico durante la transición. Para minimizar el impacto:

1. Implemente y valide primero la aplicación contenedora en la región de destino.
2. Reduzca los valores de TTL de DNS de antemano (por ejemplo, a 60 segundos), por lo que los cambios de enrutamiento se propagan rápidamente.
3. Redirigir el tráfico de producción al nuevo punto de conexión solo una vez completada la validación.
4. Mantenga en ejecución la aplicación del contenedor de origen hasta que confirme que la implementación de destino funciona correctamente.

Preparación

Para prepararse para la reubicación, exporte la configuración de origen y revise todas las configuraciones específicas de la región.

Identificación de dependencias

Los siguientes recursos dependientes deben existir en la región de destino antes del cambio:

• Azure Key Vault
• cuentas de almacenamiento
• Bases de datos y servicios de mensajería (como Azure Service Bus, Azure Cosmos DB)
• Redes virtuales, subredes y puntos de conexión privados
• Grupos de seguridad de red (NSG) y rutas definidas por el usuario (UDR)
• Zonas DNS privadas
• Áreas de trabajo de Log Analytics
• Componentes Dapr (si se utilizan)

Planear los cambios de identidad administrada

La gestión de identidades administradas depende del tipo de identidad:

• Identidad asignada por el sistema: Al recrear la aplicación de contenedor, Azure genera un nuevo ID principal. Debe reasignar todos los roles de RBAC, las políticas de acceso de Key Vault y los permisos de servicios descendentes a la nueva identidad.

• Identidad asignada por el usuario: las identidades administradas asignadas por el usuario son recursos regionales y no se pueden mover entre regiones. Cree una nueva identidad asignada por el usuario en la región de destino y asigne los permisos necesarios antes de la implementación.

Exportación de la configuración de origen

az containerapp env show \
  --name <ENVIRONMENT_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > managed-environment.json

az containerapp show \
  --name <APP_NAME> \
  --resource-group <RESOURCE_GROUP> \
  --output json > container-app.json

Modificación de la plantilla de entorno administrado

Antes de volver a implementar el entorno administrado, actualice la configuración exportada:

• Actualice la ubicación: establezca la location propiedad en la región de Azure de destino.
• Validar nombres de recursos: asegúrese de que el nombre del entorno administrado sea único dentro del grupo de recursos y la región de destino.
• Revise la configuración de Log Analytics: actualice la referencia del área de trabajo de Log Analytics si el área de trabajo es específica de la región. Es posible que tenga que crear un área de trabajo en la región de destino.
• Eliminar propiedades de solo lectura: si exportó desde el portal, quite propiedades como id, type, systemData, y otros campos de solo lectura que causan fallos de implementación.

Modificación de la plantilla de aplicación de contenedor

Después de exportar la configuración de la aplicación contenedora, realice los siguientes cambios:

• Actualice la referencia del entorno administrado: reemplace managedEnvironmentId por el identificador de recurso del nuevo entorno administrado en la región de destino. Los entornos administrados están enlazados a regiones y no se pueden reutilizar entre regiones.

• Comprobar las referencias de imagen de contenedor: confirme que las referencias de imagen apuntan a un registro de contenedor accesible desde la región de destino. Si ha habilitado la replicación geográfica de ACR, las referencias existentes podrían funcionar sin cambios.

• Revisar la configuración de entrada: Después de la reimplementación, cambia el nombre de dominio completamente calificado (FQDN) de la aplicación. Prevea la actualización de los registros DNS personalizados y el enrutamiento del tráfico durante la transición.

• Reconfigurar secretos y la configuración de la aplicación: Recrear secretos mediante referencias de Azure Key Vault o configuración de la aplicación. No se base en los valores exportados para la configuración confidencial.

• Actualizar componentes de Dapr: si usa Dapr, compruebe que las configuraciones de componentes de Dapr hacen referencia a los recursos disponibles en la región de destino (por ejemplo, almacenes de estado, pub/sub broker, almacenes secretos).

• Actualización de diagnósticos y supervisión: compruebe las referencias del área de trabajo de Log Analytics y vuelva a configurar la configuración de diagnóstico según sea necesario.

Volver a implementar

Los entornos administrados de Azure Container Apps están enlazados a regiones. Cree el entorno administrado en la región de destino antes de volver a implementar las aplicaciones de contenedor.

Implementación del entorno administrado

az containerapp env create \
  --name <ENVIRONMENT_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --location <TARGET_REGION> \
  --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>

az containerapp env create \
  --name <ENVIRONMENT_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --location <TARGET_REGION> \
  --infrastructure-subnet-resource-id <SUBNET_ID> \
  --internal-only true \
  --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
  --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>

Validación del acceso al registro de contenedor

Antes de implementar la aplicación contenedora, confirme que la identidad usada por la aplicación contenedora (asignada por el sistema o la identidad administrada asignada por el usuario) tiene asignado el rol AcrPull en azure Container Registry de destino.

az role assignment create \
  --assignee <IDENTITY_PRINCIPAL_ID> \
  --role AcrPull \
  --scope <ACR_RESOURCE_ID>

Implementación de la aplicación contenedora

az containerapp create \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --environment <ENVIRONMENT_NAME> \
  --image <IMAGE_REFERENCE> \
  --target-port <PORT> \
  --ingress external \
  --registry-server <ACR_LOGIN_SERVER> \
  --registry-identity <IDENTITY_RESOURCE_ID>

az deployment group create \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --template-file container-app-template.json \
  --parameters container-app-parameters.json

Configuración de las redes

Después de la implementación, vuelva a configurar las redes para que coincidan con la configuración de origen:

1. Configurar la entrada: configure la entrada pública o privada en función del modelo de exposición de la aplicación.

2. Volver a aplicar la integración de VNet: Si la aplicación contenedora utiliza redes privadas, configure la VNet, las subredes, los puntos de conexión privados y las zonas DNS privadas en la región de destino.

3. Actualizar NSG y UDR: vuelva a crear grupos de seguridad de red y rutas definidas por el usuario según sea necesario.

4. Actualizar listas de permitidos de IP: si los servicios de bajada usan listas de permitidos basadas en IP, actualícelas con las nuevas direcciones IP salientes del entorno de la región de destino.

5. Configurar certificados y dominios personalizados: los dominios personalizados y los certificados TLS no se transfieren durante la reubicación. Vuelva a configurarlos en la nueva aplicación contenedora y actualice los registros DNS.

Transicionar tráfico

Después de la validación, redirija el tráfico al despliegue de la región de destino.

1. Si ha reducido el TTL de DNS anteriormente, actualice los registros DNS para que apunten al nuevo FQDN de la aplicación contenedora.

2. Si usa Azure Front Door o Azure Traffic Manager, actualice el grupo de back-end o el punto de conexión para incluir la aplicación contenedora de región de destino y quite el punto de conexión de la región de origen.

3. Monitorice el tráfico de red para confirmar que las solicitudes llegan a la nueva implementación.

Verificar

Después de la transición del tráfico, verifique los siguientes elementos:

• Disponibilidad de la aplicación y tiempos de respuesta.
• Comportamiento de escalado en carga máxima y esperada.
• Conectividad a servicios dependientes, como bases de datos, Key Vault, almacenamiento y mensajería.
• Acceso de identidad administrada a los recursos de bajada.
• Funcionalidad de los componentes de Dapr, si se utiliza.
• Registros y métricas que fluyen a Azure Monitor y Log Analytics.

Compruebe mediante la CLI:

# Confirm the container app is running
az containerapp show \
  --name <APP_NAME> \
  --resource-group <TARGET_RESOURCE_GROUP> \
  --query "{status:properties.runningStatus, fqdn:properties.configuration.ingress.fqdn}" \
  --output table

# Test the application endpoint
curl -s -o /dev/null -w "%{http_code}" https://<APP_FQDN>/health

Limpieza de los recursos de origen

Una vez completadas correctamente la validación y la transición del tráfico:

1. Elimine la aplicación de contenedor de origen.
2. Elimine el entorno administrado de origen si ya no lo necesita.
3. Quite las imágenes de contenedores no utilizadas, los recursos de red y las asignaciones de identidad para evitar cargos innecesarios.
4. Actualice los paneles de supervisión o las reglas de alertas a las que se hace referencia a los recursos de origen.

Limitaciones

• Azure Container Apps no admite la reubicación de regiones en su lugar ni en tiempo real.
• Debe volver a crear secretos, certificados y dominios personalizados.
• El historial de revisiones no se conserva en el despliegue objetivo.
• Se requiere tiempo de inactividad durante el cambio.
• Los ID de entidad de seguridad de la identidad administrada asignados por el sistema cambian; por lo tanto, es necesario volver a crear todas las asignaciones de RBAC.
• Las identidades administradas asignadas por el usuario son regionales y deben volver a crearse en la región de destino.
• Las direcciones IP de salida cambian, lo que puede afectar a las listas de permisos de los servicios posteriores.

Contenido relacionado

• Automatización de implementaciones mediante plantillas de Bicep o ARM
• Introducción a las redes de Azure Container Apps
• Configuración de certificados y dominios personalizados
• Escalado y rendimiento de Azure Container Apps
• Identidad administrada en Azure Container Apps