Tutorial: Creación de una aplicación de varias regiones con alta disponibilidad en Azure App Service

En una solución bien diseñada, dos de los componentes clave son la alta disponibilidad y la tolerancia a errores. En caso de algún acontecimiento inesperado, es mejor contar con un plan de emergencia que pueda acortar el tiempo de inactividad y mantener los sistemas en funcionamiento automáticamente cuando algo vaya mal.

Al implementar la aplicación en la nube, elija una región de esa nube en la que se base la infraestructura de la aplicación. Si su aplicación se implementa en una sola región y la región no está disponible, la aplicación tampoco estará disponible. Esta falta de disponibilidad puede ser inaceptable bajo los términos del Acuerdo de Nivel de Servicio de la aplicación. En este caso, una buena solución es implementar la aplicación y sus servicios en varias regiones.

En este tutorial, obtendrá información sobre cómo implementar una aplicación web de varias regiones con alta disponibilidad. Este escenario se simplifica mediante la restricción de los componentes de la aplicación a solo una aplicación web y Azure Front Door, pero los conceptos se pueden expandir y aplicar a otros patrones de infraestructura. Por ejemplo, si la aplicación se conecta a una oferta de base de datos de Azure o a una cuenta de almacenamiento, consulte Replicación geográfica activa para bases de datos SQL y Opciones de redundancia para cuentas de almacenamiento. Para ver una arquitectura de referencia en un escenario más detallado, consulte Aplicación web de varias regiones de alta disponibilidad.

En el diagrama de arquitectura siguiente se muestra la infraestructura que se crea en este tutorial. Consta de dos instancias de App Service idénticas en distintas regiones, una, la región activa o primaria, y la otra, la región en espera o secundaria. Para enrutar el tráfico a las instancias de App Service se usa Azure Front Door y se configuran restricciones de acceso para bloquear el acceso directo a las aplicaciones desde Internet. La línea de puntos indica que el tráfico solo se envía a la región en espera si la región activa deja de funcionar.

Azure proporciona varias opciones para el equilibrio de carga y el enrutamiento del tráfico. Para este caso de uso se seleccionó Azure Front Door porque tiene en cuenta aplicaciones web accesibles desde Internet hospedadas en Azure App Service implementadas en varias regiones. Para ayudarle a decidir qué utilizar para su caso de uso si varía con respecto al de este tutorial, consulte el árbol de decisión para el equilibrio de carga de Azure.

Con esta arquitectura:

• Se implementan aplicaciones de App Service idénticas en dos regiones distintas.
• El tráfico público que va directamente a las aplicaciones de App Service se bloquea.
• Azure Front Door se usa para enrutar el tráfico a la región primaria o activa. La región secundaria tiene una instancia de App Service que funciona y está lista para atender el tráfico si es necesario.

Temas que se abordarán:

• Crear instancias de App Service idénticas en distintas regiones.
• Crear Azure Front Door con restricciones de acceso que bloqueen el acceso público a las instancias de App Service.

Requisitos previos

Si no tiene una suscripción a Azure, cree una cuenta gratuita de Azure antes de empezar.

Para completar este tutorial:

• Use el entorno de Bash en Azure Cloud Shell. Para más información, consulte Inicio rápido para Bash en Azure Cloud Shell.

  

• Si prefiere ejecutar comandos de referencia de la CLI localmente, instale la CLI de Azure. Si utiliza Windows o macOS, considere la posibilidad de ejecutar la CLI de Azure en un contenedor Docker. Para más información, vea Ejecución de la CLI de Azure en un contenedor de Docker.

  • Si usa una instalación local, inicie sesión en la CLI de Azure mediante el comando az login. Siga los pasos que se muestran en el terminal para completar el proceso de autenticación. Para ver otras opciones de inicio de sesión, consulte Inicio de sesión con la CLI de Azure.

  • En caso de que se le solicite, instale las extensiones de la CLI de Azure la primera vez que la use. Para más información sobre las extensiones, consulte Uso de extensiones con la CLI de Azure.

  • Ejecute az version para buscar cuál es la versión y las bibliotecas dependientes que están instaladas. Para realizar la actualización a la versión más reciente, ejecute az upgrade.

Creación de dos instancias de una aplicación web

Para este tutorial, necesita dos instancias de una aplicación web que se ejecuten en diferentes regiones de Azure. Usará el par de regiones Este de EE. UU. y Oeste de EE. UU. y creará dos aplicaciones web vacías. Si es necesario, no dude en elegir sus propias regiones.

Para simplificar la administración y la limpieza, usará un único grupo de recursos para todos los recursos de este tutorial. Considere la posibilidad de usar grupos de recursos distintos para cada región o recurso con el fin de aislar aún más los recursos en una situación de recuperación ante desastres.

Ejecute el comando siguiente para crear el grupo de recursos.

az group create --name myresourcegroup --location eastus

Creación de planes de App Service

Ejecute los siguientes comandos para crear los planes de App Service. Reemplace los marcadores de posición <app-service-plan-east-us> y <app-service-plan-west-us> por dos nombres únicos en los que pueda identificar fácilmente la región en la que se encuentran.

az appservice plan create --name <app-service-plan-east-us> --resource-group myresourcegroup --is-linux --location eastus

az appservice plan create --name <app-service-plan-west-us> --resource-group myresourcegroup --is-linux --location westus

Creación de aplicaciones web

Una vez creados los planes de App Service, ejecute los siguientes comandos para crear las aplicaciones web. Reemplace los marcadores de posición <web-app-east-us> y <web-app-west-us> por dos nombres globalmente únicos (los caracteres válidos son a-z, 0-9 y -) y asegúrese de prestar atención al parámetro --plan para colocar una aplicación en cada plan (y, por tanto, en cada región). Reemplace el parámetro <runtime> por la versión de lenguaje de la aplicación. Ejecute az webapp list-runtimes para ver la lista de entornos de ejecución disponibles. Si tiene previsto usar la aplicación Node.js de ejemplo que se muestra en este tutorial en las secciones siguientes, use NODE:18-lts como runtime.

az webapp create --name <web-app-east-us> --resource-group myresourcegroup --plan <app-service-plan-east-us> --runtime <runtime>

az webapp create --name <web-app-west-us> --resource-group myresourcegroup --plan <app-service-plan-west-us> --runtime <runtime>

Anote el nombre de host predeterminado de cada aplicación web, con el fin de que pueda definir las direcciones de back-end al implementar la instancia de Front Door en el paso siguiente. Debe tener este formato: <web-app-name>.azurewebsites.net. Para encontrar estos nombres de host, ejecute el siguiente comando o vaya a la página Información general de la aplicación en Azure Portal.

az webapp show --name <web-app-name> --resource-group myresourcegroup --query "hostNames"

Crear una instancia de Azure Front Door

Una implementación de varias regiones puede usar una configuración activa-activa o activa-pasiva. Una configuración activa-activa distribuye las solicitudes entre varias regiones activas. Una configuración activa-pasiva mantiene en ejecución las instancias de la región secundaria, pero no les envía tráfico a menos que la región primaria no pueda atenderlo. Azure Front Door tiene una característica integrada que permite habilitar estas configuraciones. Para más información sobre el diseño de aplicaciones con alta disponibilidad y tolerancia a errores, consulte Diseño de aplicaciones de Azure para lograr resistencia y disponibilidad.

Creación de un perfil de Azure Front Door

Ahora creará una instancia de Azure Front Door Premium para enrutar el tráfico a las aplicaciones.

Ejecute az afd profile create para crear un perfil de Azure Front Door.

Nota:

Si quiere implementar la versión Estándar de Azure Front Door en lugar de la Premium, sustituya el valor del parámetro --sku por Standard_AzureFrontDoor. No puede implementar reglas administradas con la directiva de WAF si elige el nivel estándar. Para ver una comparación detallada de los planes de tarifa, consulte Comparación de niveles de Azure Front Door.

az afd profile create --profile-name myfrontdoorprofile --resource-group myresourcegroup --sku Premium_AzureFrontDoor

Parámetro	valor	Descripción
profile-name	myfrontdoorprofile	Nombre del perfil de Azure Front Door, que es único dentro del grupo de recursos.
resource-group	myresourcegroup	El grupo de recursos que contiene los recursos de este tutorial.
sku	Premium_AzureFrontDoor	El plan de tarifa del perfil de Azure Front Door.

Agregación de un extremo

Ejecute az afd endpoint create para crear un punto de conexión en el perfil. Puede crear varios puntos de conexión en el perfil después de finalizar la experiencia de creación.

az afd endpoint create --resource-group myresourcegroup --endpoint-name myendpoint --profile-name myfrontdoorprofile --enabled-state Enabled

Parámetro	valor	Descripción
endpoint-name	myendpoint	Nombre del punto de conexión en el perfil, que es único globalmente.
enabled-state	Enabled	Si se va a habilitar este punto de conexión.

Creación de un grupo de origen

Ejecute az afd origin-group create para crear un grupo de orígenes que contenga las dos aplicaciones web.

az afd origin-group create --resource-group myresourcegroup --origin-group-name myorigingroup --profile-name myfrontdoorprofile --probe-request-type GET --probe-protocol Http --probe-interval-in-seconds 60 --probe-path / --sample-size 4 --successful-samples-required 3 --additional-latency-in-milliseconds 50

Parámetro	valor	Descripción
origin-group-name	myorigingroup	Nombre del grupo de orígenes.
probe-request-type	GET	El tipo de solicitud de sondeo de estado que se realiza.
probe-protocol	Http	Protocolo que se va a usar para el sondeo de estado.
probe-interval-in-seconds	60	Número de segundos entre sondeos de estado.
probe-path	/	La ruta de acceso relativa al origen que se usa para determinar el estado del origen.
sample-size	4	Número de muestras para tener en cuenta para las decisiones de equilibrio de carga.
successful-samples-required	3	El número de muestras dentro del período de muestreo que deben realizarse correctamente.
additional-latency-in-milliseconds	50	Latencia adicional en milisegundos para que los sondeos se ubiquen en el cubo de latencia más bajo.

Adición de un origen al grupo

Ejecute az afd origin create para agregar un origen al grupo de origen. Para el parámetro --host-name, reemplace el marcador de posición <web-app-east-us> por el nombre de la aplicación en esa región. Observe que el parámetro --priority se establece en 1, lo que indica que todo el tráfico se envía a la aplicación principal.

az afd origin create --resource-group myresourcegroup --host-name <web-app-east-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name primaryapp --origin-host-header <web-app-east-us>.azurewebsites.net --priority 1 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Parámetro	valor	Descripción
host-name	<web-app-east-us>.azurewebsites.net	El nombre de host de la aplicación web principal.
origin-name	primaryapp	Nombre del origen.
origin-host-header	<web-app-east-us>.azurewebsites.net	El encabezado host para enviar las solicitudes a este origen. Si deja este valor en blanco, el nombre de host de la solicitud determina este valor. Los orígenes de Azure CDN, como Web Apps, Blob Storage y Cloud Services requieren que este valor de encabezado host coincida con el nombre de host de origen de forma predeterminada.
priority	1	Establezca este parámetro en 1 para dirigir todo el tráfico a la aplicación web principal.
weight	1000	Peso del origen en un grupo de orígenes determinado para el equilibrio de carga. Debe estar entre 1 y 1000.
enabled-state	Enabled	Si se va a habilitar este origen.
http-port	80	El puerto usado para las solicitudes HTTP al origen.
https-port	443	El puerto usado para las solicitudes HTTPS al origen.

Repita este paso para agregar el segundo origen. Preste atención al parámetro --priority. Para este origen, se establece en 2. Esta configuración de prioridad indica a Azure Front Door que dirija todo el tráfico al origen primario, a menos que este deje de funcionar. Si establece la prioridad de este origen en 1, Azure Front Door trata ambos orígenes como activos y dirige el tráfico a ambas regiones. Asegúrese de reemplazar ambas instancias del marcador de posición <web-app-west-us> por el nombre de esa aplicación web.

az afd origin create --resource-group myresourcegroup --host-name <web-app-west-us>.azurewebsites.net --profile-name myfrontdoorprofile --origin-group-name myorigingroup --origin-name secondaryapp --origin-host-header <web-app-west-us>.azurewebsites.net --priority 2 --weight 1000 --enabled-state Enabled --http-port 80 --https-port 443

Agregar una ruta

Ejecute az afd route create para asignar el punto de conexión al grupo de origen. Esta ruta reenvía las solicitudes del punto de conexión al grupo de origen.

az afd route create --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --forwarding-protocol MatchRequest --route-name route --https-redirect Enabled --origin-group myorigingroup --supported-protocols Http Https --link-to-default-domain Enabled 

Parámetro	valor	Descripción
endpoint-name	myendpoint	Nombre del punto de conexión.
forwarding-protocol	MatchRequest	Protocolo que usa esta regla al reenviar el tráfico a los servidores back-end.
route-name	route	Nombre de la ruta.
https-redirect	Enabled	Si se va a redirigir automáticamente el tráfico HTTP al tráfico HTTPS.
supported-protocols	Http Https	Lista de protocolos admitidos para esta ruta.
link-to-default-domain	Enabled	Si esta ruta se vincula al dominio de punto de conexión predeterminado.

Espere unos 15 minutos a que se complete este paso, ya que este cambio tarda algún tiempo en propagarse globalmente. Después de este período, la instancia de Azure Front Door será totalmente funcional.

Restricción del acceso de las aplicaciones web a la instancia de Azure Front Door

En este momento, todavía puede acceder a las aplicaciones directamente mediante sus direcciones URL. Para asegurarse de que el tráfico solo puede llegar a las aplicaciones mediante Azure Front Door, establezca restricciones de acceso sobre cada una de las aplicaciones. Las características de Front Door funcionan mejor cuando el tráfico solo fluye a través de Front Door. Debe configurar los orígenes para bloquear el tráfico que aún no se ha enviado mediante Front Door. De lo contrario, el tráfico podría omitir el firewall de aplicaciones web de Front Door, la protección contra DDoS y otras características de seguridad. El tráfico de Azure Front Door a las aplicaciones se origina en un conjunto conocido de intervalos IP definidos en la etiqueta de servicio AzureFrontDoor.Backend. Con una regla de restricción de etiquetas de servicio, puede restringir el tráfico a solo el que se origina en Azure Front Door.

Antes de configurar las restricciones de acceso de App Service, tome nota del identificador de Front Door mediante la ejecución del comando siguiente. Este identificador es necesario para asegurarse de que el tráfico solo se origina en la instancia específica de Front Door. La restricción de acceso filtra aún más las solicitudes entrantes en función del encabezado HTTP único que envía la instancia de Azure Front Door.

az afd profile show --resource-group myresourcegroup --profile-name myfrontdoorprofile --query "frontDoorId"

Ejecute los comandos siguientes para establecer las restricciones de acceso en las aplicaciones web. Reemplace el marcador de posición <front-door-id> por el resultado del comando anterior. Reemplace los marcadores de posición de los nombres de aplicación.

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-east-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

az webapp config access-restriction add --resource-group myresourcegroup -n <web-app-west-us> --priority 100 --service-tag AzureFrontDoor.Backend --http-header x-azure-fdid=<front-door-id>

Prueba de Front Door

Cuando se crea el perfil de Azure Front Door Estándar/Premium, la configuración tarda unos minutos en implementarse globalmente. Cuando haya finalizado, puede acceder al host de front-end que ha creado.

Ejecute az afd endpoint show para obtener el nombre de host del punto de conexión de Front Door.

az afd endpoint show --resource-group myresourcegroup --profile-name myfrontdoorprofile --endpoint-name myendpoint --query "hostName"

En un explorador, vaya al nombre de host del punto de conexión que devolvió el comando anterior: <myendpoint>-<hash>.z01.azurefd.net. La solicitud se debería enrutar automáticamente a la aplicación principal en la región Este de EE UU.

Para probar la conmutación por error global instantánea:

1. Abra un explorador y vaya al nombre de host del punto de conexión: <myendpoint>-<hash>.z01.azurefd.net.

2. Detenga la aplicación principal mediante la ejecución de az webapp stop.

   az webapp stop --name <web-app-east-us> --resource-group myresourcegroup
   

3. Actualice el explorador. Verá la misma página de información porque el tráfico ahora se dirige a la aplicación en ejecución de Oeste de EE. UU.

   Sugerencia

   Es posible que tenga que actualizar la página varias veces para que se complete la conmutación por error.

4. Ahora detenga la aplicación secundaria.

   az webapp stop --name <web-app-west-us> --resource-group myresourcegroup
   

5. Actualice el explorador. Esta vez debería aparecer un mensaje de error.

   

6. Reinicie una de las aplicaciones web mediante la ejecución de az webapp start. Actualice el explorador; verá de nuevo la aplicación.

   az webapp start --name <web-app-east-us> --resource-group myresourcegroup
   

Ahora ha validado que puede acceder a las aplicaciones mediante Azure Front Door y que la conmutación por error funciona según lo previsto. Si ha terminado con las pruebas de conmutación por error, reinicie la otra aplicación.

Para probar las restricciones de acceso y garantizar que solo se pueda acceder a las aplicaciones mediante Azure Front Door, abra un explorador y vaya a cada una de las direcciones URL de la aplicación. Para encontrar las direcciones URL, ejecute los siguientes comandos:

az webapp show --name <web-app-east-us> --resource-group myresourcegroup --query "hostNames"

az webapp show --name <web-app-west-us> --resource-group myresourcegroup --query "hostNames"

Verá una página de error que indica que las aplicaciones no son accesibles.

Limpieza de recursos

En los pasos anteriores, creó recursos de Azure en un grupo de recursos. Si prevé que no necesitará estos recursos en el futuro, elimine el grupo de recursos ejecutando el siguiente comando en Cloud Shell.

az group delete --name myresourcegroup

Este comando puede tardar unos minutos en ejecutarse.

Implementación desde ARM o Bicep

Los recursos creados en este tutorial se pueden implementar mediante una plantilla de ARM o Bicep. La plantilla de Bicep de aplicaciones web de varias regiones de alta disponibilidad permite crear una solución completa de varias regiones segura y de alta disponibilidad con dos aplicaciones web en diferentes regiones detrás de Azure Front Door.

Para aprender a implementar plantillas de ARM o Bicep, consulte Implementación de recursos con Bicep y la CLI de Azure.

Preguntas más frecuentes

Hasta el momento, en este tutorial ha implementado la infraestructura de línea de base para permitir una aplicación web de varias regiones. App Service proporciona características que pueden ayudarle a garantizar que ejecuta aplicaciones siguiendo las recomendaciones y los procedimientos recomendados de seguridad.

Esta sección contiene preguntas frecuentes que pueden ayudarle a proteger mejor las aplicaciones e implementar y administrar los recursos mediante procedimientos recomendados.

¿Cuál es el método recomendado para administrar e implementar la infraestructura de aplicaciones y los recursos de Azure?

En este tutorial, ha usado la CLI de Azure para implementar los recursos de infraestructura. Considere la posibilidad de configurar un mecanismo de implementación continua para administrar la infraestructura de la aplicación. Puesto que implementa recursos en diferentes regiones, debe administrar esos recursos de forma independiente en todas ellas. Para asegurarse de que los recursos son idénticos en cada región, se debe usar la infraestructura como código (IaC), como plantillas de Azure Resource Manager o Terraform, con canalizaciones de implementación, como Azure Pipelines o Acciones de GitHub. De este modo, si se configura correctamente, cualquier cambio en los recursos desencadenará actualizaciones en todas las regiones en las que se van a implementar. Para más información, consulte Implementación continua en Azure App Service.

¿Cómo se pueden usar los espacios de ensayo para practicar la implementación segura en producción?

No se recomienda implementar el código de la aplicación directamente en aplicaciones o espacios de producción. El motivo es que es conveniente tener un lugar en el que probar las aplicaciones y validar los cambios realizados antes de insertarlos en producción. Use una combinación de espacios de ensayo e intercambio de ranuras para mover el código del entorno de pruebas a producción.

Ya ha creado la infraestructura de línea de base para este escenario. Ahora creará ranuras de implementación para cada instancia de la aplicación y configurará la implementación continua en estos espacios de ensayo con Acciones de GitHub. Al igual que con la administración de la infraestructura, también se recomienda configurar la implementación continua para el código fuente de la aplicación para asegurarse de que los cambios entre regiones están sincronizados. Si no configura la implementación continua, deberá actualizar manualmente cada aplicación de cada región siempre que haya un cambio en el código.

Para el resto de pasos de este tutorial, tendrá una aplicación lista para implementar en las instancias de App Service. Si necesita una aplicación de ejemplo, puede usar la aplicación de ejemplo "Hola, mundo" de Node.js. Bifurque ese repositorio para tener su propia copia.

Asegúrese de establecer la configuración de la pila de App Service de las aplicaciones. La configuración de la pila hace referencia al lenguaje o al entorno de ejecución que se usa para la aplicación. Esta configuración se puede realizar mediante la CLI de Azure con el comando az webapp config set o en el portal con los pasos siguientes. Si usa el ejemplo de Node.js, establezca la configuración de la pila en Node 18 LTS.

1. Vaya a la aplicación y seleccione Configuración en la tabla de contenido de la izquierda.
2. Seleccione la pestaña Configuración general.
3. En Configuración de la pila, elija el valor adecuado para la aplicación.
4. Seleccione Guardar y, luego, Continuar para confirmar la actualización.
5. Repita estos pasos con el resto de aplicaciones.

Ejecute los comandos siguientes para crear espacios de ensayo también llamados "fases" para cada una de las aplicaciones. Reemplace los marcadores de posición <web-app-east-us> y <web-app-west-us> por sus nombres de aplicación.

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-east-us> --slot stage --configuration-source <web-app-east-us>

az webapp deployment slot create --resource-group myresourcegroup --name <web-app-west-us> --slot stage --configuration-source <web-app-west-us>

Para configurar la implementación continua, debe usar Azure Portal. Para una guía detallada sobre cómo configurar la implementación continua con proveedores como Acciones de GitHub, consulte Implementación continua en Azure App Service.

Para configurar la implementación continua con Acciones de GitHub, realice los pasos siguientes para cada uno de los espacios de ensayo.

1. En Azure Portal, vaya a la página de administración de una de las ranuras de implementación de App Service.

2. En el panel izquierdo, seleccione Centro de implementación. Luego, seleccione Configuración.

3. En el cuadro Origen, seleccione "GitHub" en las opciones de CI/CD:

   

4. Si va a realizar la implementación desde GitHub por primera vez, seleccione Autorizar y siga las indicaciones de autorización. Si quiere realizar la implementación desde un repositorio de usuario diferente, seleccione Cambiar cuenta.

5. Después de autorizar su cuenta de Azure con GitHub, seleccione la organización, el repositorio y la rama para configurar CI/CD. Si no encuentra ningún repositorio u organización, es posible que tenga que habilitar más permisos en GitHub. Para más información, consulte Administración del acceso a los repositorios de la organización.

   1. Si va a usar la aplicación de ejemplo de Node.js, utilice la siguiente configuración.

      Configuración	Valor
      Organización	<your-GitHub-organization>
      Repositorio	nodejs-docs-hello-world
      Rama	main (principal)

6. Seleccione Guardar.

   Las nuevas confirmaciones del repositorio y la rama seleccionados ahora se implementan continuamente en la ranura de la aplicación de App Service. Puede hacer el seguimiento de las confirmaciones y las implementaciones en la pestaña Registros.

Se agrega a su repositorio de GitHub un archivo de flujo de trabajo predeterminado que utiliza un perfil de publicación para autenticarse en App Service. Para ver este archivo, vaya al directorio <repo-name>/.github/workflows/.

¿Cómo se deshabilita la autenticación básica en App Service?

Considere la posibilidad de deshabilitar la autenticación básica, lo que limita el acceso de los usuarios respaldados por Microsoft Entra ID a los puntos de conexión FTP y SCM. Si usa una herramienta de implementación continua para implementar el código fuente de la aplicación, para deshabilitar la autenticación básica son necesarios pasos adicionales para configurar la implementación continua. Por ejemplo, no puede usar un perfil de publicación, ya que no usa las credenciales de Microsoft Entra. En su lugar, debe usar una entidad de servicio u OpenID Connect.

Para deshabilitar la autenticación básica para App Service, ejecute los siguientes comandos para cada aplicación y ranura, y reemplace los marcadores de posición de <web-app-east-us> y <web-app-west-us> por los nombres de la aplicación. El primer conjunto de comandos deshabilita el acceso FTP en los sitios de producción y los espacios de ensayo, y el segundo conjunto de comandos deshabilita el acceso básico de autenticación al puerto WebDeploy y al sitio SCM en estos mismos lugares.

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name ftp --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-east-us>/slots/stage --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us> --set properties.allow=false

az resource update --resource-group myresourcegroup --name scm --namespace Microsoft.Web --resource-type basicPublishingCredentialsPolicies --parent sites/<web-app-west-us>/slots/stage --set properties.allow=false

Para obtener más información sobre cómo deshabilitar la autenticación básica, incluido cómo probar y supervisar inicios de sesión, consulte Deshabilitación de la autenticación básica en implementaciones de App Service.

¿Cómo se implementa el código mediante la implementación continua si se ha deshabilitado la autenticación básica?

Si decide permitir la autenticación básica en las aplicaciones de App Service, puede usar cualquiera de los métodos de implementación disponibles en App Service, incluido el uso del perfil de publicación configurado en la sección Espacios de ensayo.

Si deshabilita la autenticación básica para las instancias de App Service, la implementación continua requiere una entidad de servicio u OpenID Connect para la autenticación. Si usa Acciones de GitHub como repositorio de código, consulte el tutorial paso a paso sobre el uso de una entidad de servicio u OpenID Connect para realizar la implementación en App Service mediante Acciones de GitHub o lleve a cabo los pasos de la sección siguiente.

Creación de la entidad de servicio y configuración de credenciales con Acciones de GitHub

Para configurar la implementación continua con Acciones de GitHub y una entidad de servicio, siga estos pasos.

1. Ejecute el siguiente comando para crear la entidad de servicio. Reemplace los marcadores de posición por <subscription-id> y sus nombres de aplicación. La salida es un objeto JSON con las credenciales de asignación de roles que proporcionan acceso a las aplicaciones de App Service. Copie este objeto JSON en el siguiente paso. Esto incluye el secreto de cliente, que solo es visible en este momento. Siempre es recomendable conceder acceso mínimo. El ámbito de este ejemplo se limita a solo las aplicaciones, no al grupo de recursos entero.

   az ad sp create-for-rbac --name "myApp" --role contributor --scopes /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-east-us> /subscriptions/<subscription-id>/resourceGroups/myresourcegroup/providers/Microsoft.Web/sites/<web-app-west-us> --sdk-auth
   

2. Como parte del flujo de trabajo de Acciones de GitHub que va a usar, debe proporcionar las credenciales de la entidad de servicio a la acción de Azure/inicio de sesión. Estos valores se pueden proporcionar directamente en el flujo de trabajo o se pueden almacenar en secretos de GitHub y se puede hacer referencia a ellos en el flujo de trabajo. Guardar los valores como secretos de GitHub es la opción más segura.

   1. Abra el repositorio de GitHub y vaya a Configuración>Seguridad>Secretos y variables>Acciones

   2. Seleccione Nuevo secreto del repositorio y cree un secreto para cada uno de los valores siguientes. Los valores se pueden encontrar en la salida JSON que copió anteriormente.

      Nombre	Valor
      AZURE_APP_ID	<application/client-id>
      AZURE_PASSWORD	<client-secret>
      AZURE_TENANT_ID	<tenant-id>
      AZURE_SUBSCRIPTION_ID	<subscription-id>

Creación del flujo de trabajo de Acciones de GitHub

Ahora que tiene una entidad de servicio que puede acceder a las aplicaciones de App Service, edite los flujos de trabajo predeterminados que se crearon para las aplicaciones cuando configuró la implementación continua. La autenticación debe realizarse mediante la entidad de servicio en lugar del perfil de publicación. Para ver flujos de trabajo de ejemplo, consulte la pestaña "Entidad de servicio" en Agregar el archivo de flujo de trabajo al repositorio de GitHub. El siguiente flujo de trabajo de ejemplo se puede usar para la aplicación de ejemplo de Node.js que se ha facilitado.

1. Abra el repositorio de GitHub de la aplicación y vaya al directorio <repo-name>/.github/workflows/. Debería ver los flujos de trabajo generados automáticamente.

2. Para cada archivo de flujo de trabajo, seleccione el botón de "lápiz" en la parte superior derecha para editar el archivo. Reemplace el contenido por el texto siguiente, que supone que creó los secretos de GitHub anteriormente para la credencial. Actualice el marcador de posición <web-app-name> en la sección "env" y, luego, confirme directamente en la rama principal. Esta confirmación hace que la acción de GitHub se ejecute de nuevo e implemente el código, esta vez mediante la entidad de servicio para autenticarse.

   
   name: Build and deploy Node.js app to Azure Web App
   
   on:
     push:
       branches:
         - main
     workflow_dispatch:
   
   env:
     AZURE_WEBAPP_NAME: <web-app-name>   # set this to your application's name
     NODE_VERSION: '18.x'                # set this to the node version to use
     AZURE_WEBAPP_PACKAGE_PATH: '.'      # set this to the path to your web app project, defaults to the repository root
     AZURE_WEBAPP_SLOT_NAME: stage       # set this to your application's slot name
   
   jobs:
     build:
       runs-on: ubuntu-latest
   
       steps:
         - uses: actions/checkout@v2
   
         - name: Set up Node.js version
           uses: actions/setup-node@v1
           with:
             node-version: ${{ env.NODE_VERSION }}
   
         - name: npm install, build
           run: |
             npm install
             npm run build --if-present
   
         - name: Upload artifact for deployment job
           uses: actions/upload-artifact@v2
           with:
             name: node-app
             path: .
   
     deploy:
       runs-on: ubuntu-latest
       needs: build
       environment:
         name: 'stage'
         url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
   
       steps:
         - name: Download artifact from build job
           uses: actions/download-artifact@v2
           with:
             name: node-app
   
         - uses: azure/login@v1
           with:
             creds: |
               {
                 "clientId": "${{ secrets.AZURE_APP_ID }}",
                 "clientSecret":  "${{ secrets.AZURE_PASSWORD }}",
                 "subscriptionId": "${{ secrets.AZURE_SUBSCRIPTION_ID }}",
                 "tenantId": "${{ secrets.AZURE_TENANT_ID }}"
               }
   
         - name: 'Deploy to Azure Web App'
           id: deploy-to-webapp
           uses: azure/webapps-deploy@v2
           with:
             app-name: ${{ env.AZURE_WEBAPP_NAME }}
             slot-name: ${{ env.AZURE_WEBAPP_SLOT_NAME }}
             package: ${{ env.AZURE_WEBAPP_PACKAGE_PATH }}
   
         - name: logout
           run: |
             az logout
   

¿Cómo el enrutamiento del tráfico de ranura permite probar las actualizaciones que se hacen en las aplicaciones?

El enrutamiento del tráfico con ranuras le permite dirigir una parte predefinida del tráfico de usuario a cada ranura. Inicialmente, el 100 % del tráfico se dirige al sitio de producción. Sin embargo, tiene la posibilidad de enviar, por ejemplo, el 10 % del tráfico al espacio de ensayo. Si configura el enrutamiento del tráfico de ranura de esta manera, cuando los usuarios intentan acceder a la aplicación, el 10 % de ellos se enruta automáticamente al espacio de ensayo sin cambios en la instancia de Front Door. Para información sobre los intercambios de ranuras y los entornos de ensayo en App Service, consulte Configuración de entornos de ensayo en Azure App Service.

¿Cómo se mueve el código del espacio de ensayo al espacio de producción?

Cuando haya terminado de probar y validar los espacios de ensayo, puede realizar un intercambio de ranuras desde el espacio de ensayo al espacio de producción. Debe realizar este intercambio con todas las instancias de la aplicación en cada región. Durante un intercambio de ranuras, la plataforma App Service garantiza que la ranura de destino no experimente tiempo de inactividad.

Para realizar el intercambio, ejecute el siguiente comando para cada aplicación. Reemplace el marcador de posición <web-app-name>.

az webapp deployment slot swap --resource-group MyResourceGroup -name <web-app-name> --slot stage --target-slot production

Al cabo de unos minutos, puede ir al punto de conexión de Front Door para validar que el intercambio de ranuras se ha realizado correctamente.

En este momento, las aplicaciones están funcionando y los cambios que realiza en el código fuente de la aplicación desencadenan automáticamente una actualización en ambos espacios de ensayo. Cuando esté listo para mover ese código a producción, puede repetir entonces el proceso de intercambio de ranuras.

¿De qué otra manera se puede usar Azure Front Door en las implementaciones de varias regiones?

Si le preocupan las posibles interrupciones o problemas de continuidad entre regiones, como que algunos clientes vean una versión de su aplicación mientras otros ven otra, o si está realizando cambios significativos en sus aplicaciones, puede eliminar temporalmente del grupo de origen de su instancia de Front Door el sitio que está sufriendo el intercambio de ranuras. A continuación, todo el tráfico se dirige al otro origen. Vaya al panel Actualizar grupo de orígenes y elimine el origen que experimenta el cambio. Cuando haya realizado todos los cambios y esté listo para atender el tráfico allí de nuevo, puede volver al mismo panel y seleccionar + Agregar un origen para leer el origen.

Si prefiere no eliminar los orígenes y leerlos, puede crear grupos de orígenes adicionales para la instancia de Front Door. A continuación, puede asociar la ruta al grupo de orígenes que apunta al origen previsto. Por ejemplo, puede crear dos nuevos grupos de orígenes, uno para la región primaria y otro para la región secundaria. Cuando la región primaria experimente un cambio, asocie la ruta a la región secundaria y haga lo contrario cuando sea la región secundaria la que experimente un cambio. Cuando se completen todos los cambios, puede asociar la ruta con el grupo de orígenes original que contiene ambas regiones. Este método funciona porque una ruta solo se puede asociar a un grupo de orígenes a la vez.

Para demostrar que se trabaja con varios orígenes, en la captura de pantalla siguiente hay tres grupos de orígenes. "MyOriginGroup" consta de ambas aplicaciones web y los otros dos grupos de orígenes consta cada uno de la aplicación web en su región respectiva. En el ejemplo, la aplicación de la región primaria está experimentando un cambio. Antes de que se iniciara ese cambio, la ruta estaba asociada a "MySecondaryRegion", por lo que todo el tráfico se enviaba a la aplicación de la región secundaria durante el período de cambio. Para actualizar la ruta, seleccione Sin asociar, lo que abre el panel Asociar rutas.

¿Cómo se restringe el acceso al sitio de herramientas avanzadas?

Con Azure App Service, el sitio de herramientas avanzadas o el SCM se usan para administrar las aplicaciones e implementar el código fuente de la aplicación. Considere la posibilidad de bloquear el sitio de herramientas avanzadas o SCM, ya que es probable que no se tenga que llegar a este sitio mediante Front Door. Por ejemplo, puede configurar restricciones de acceso que solo le permitan realizar las pruebas y habilitar la implementación continua con la herramienta que prefiera. Si usa ranuras de implementación, para los espacios de producción en concreto, puede denegar casi todo el acceso al sitio de SCM, ya que las pruebas y la validación se realizan con los espacios de ensayo.

Pasos siguientes

Implementación de una aplicación web de varias regiones de alta disponibilidad

Aplicación web con redundancia de zona de alta disponibilidad