Implementación full stack con la CLI de Azure para Desarrolladores

Las aplicaciones de pila completa que combinan servicios front-end y back-end son un patrón común en el desarrollo web moderno. La CLI para desarrolladores de Azure (azd) admite la implementación de aplicaciones de pila completa en las que el front-end y el back-end se hospedan como servicios independientes. En este artículo se explica cómo implementar aplicaciones de pila completa mediante azd y resalta estrategias y ventajas para una implementación eficaz.

¿Qué es un despliegue completo?

Una implementación de pila completa con azd normalmente consta de:

• Servicio front-end: una aplicación web orientada al usuario, que a menudo se compila con marcos como React, Angular, Vue o Blazor. El front-end puede hospedarse como un sitio estático o como una aplicación en contenedor.
• Servicio back-end: una API o capa de servicio que controla la lógica de negocios, el acceso a los datos y las integraciones. El back-end se hospeda normalmente en contenedores o como funciones sin servidor.
• Recursos compartidos: bases de datos, cuentas de almacenamiento, almacenes de claves y otros recursos de Azure que ambos servicios pueden usar.

Mediante azd, puede definir ambos servicios en un único archivo azure.yaml y aprovisionarlos juntos mediante la infraestructura como código (Bicep o Terraform).

Ciclo de vida de la CLI para desarrolladores de Azure

La CLI para desarrolladores de Azure sigue un flujo de trabajo estructurado con distintos eventos de ciclo de vida:

1. Paquete: compile el código fuente de la aplicación y prepare los artefactos para la implementación.
2. Aprovisionamiento: cree o actualice los recursos de infraestructura de Azure mediante Bicep o Terraform.
3. Implementación: implemente el código de aplicación empaquetado en la infraestructura aprovisionada.

El azd up comando ejecuta las tres fases secuencialmente. También puede ejecutar cada fase de forma independiente mediante azd package, azd provisiony azd deploy para un control más granular. Comprender este ciclo de vida es esencial para administrar las dependencias entre servicios, especialmente en implementaciones de pila completa en las que importan el tiempo y el orden.

Para obtener más información sobre el ciclo de vida y la azd personalización del flujo de trabajo, consulte Explore el flujo de trabajo de azd up.

Consideraciones sobre el diseño de infraestructura

Al diseñar una aplicación full-stack con azd, elija los servicios de hospedaje de Azure adecuados para el front-end y el back-end:

Obtenga más información sobre el hospedaje de aplicaciones en Azure.

Descripción de la interdependencia entre las aplicaciones front-end y back-end

Los despliegues de full-stack suelen encontrar desafíos de dependencia circular en los que cada servicio necesita información sobre el otro antes de que pueda quedar completamente configurado. Comprender estas interdependencias le ayuda a diseñar flujos de trabajo de implementación eficaces.

Front-end necesita una dirección URL de back-end: la aplicación front-end normalmente debe conocer la dirección URL del punto de conexión de la API de back-end en tiempo de compilación o tiempo de ejecución. Sin embargo, el servicio back-end no tiene una dirección URL hasta que se implementa en Azure.

Back-end necesita una dirección URL de front-end: es posible que el servicio back-end necesite la dirección URL de front-end para configurar directivas de CORS, pero el front-end no tiene una dirección URL hasta que se implemente.

Dependencias de recursos compartidos: ambos servicios pueden depender de recursos compartidos, como bases de datos, almacenes de claves o cuentas de almacenamiento. Estos recursos se deben aprovisionar antes de que se pueda configurar cualquiera de los servicios para usarlos.

Configuración específica del entorno: los distintos entornos (desarrollo, ensayo, producción) requieren diferentes direcciones URL y configuraciones de punto de conexión, pero estos valores no se conocen hasta que se complete el aprovisionamiento.

Descripción de las estrategias de configuración

La CLI para desarrolladores de Azure controla estas interdependencias a través de dos enfoques:

• Configuración en tiempo de implementación: resolución de dependencias durante el aprovisionamiento y la implementación
• Configuración en tiempo de ejecución: aplazar la configuración de dependencia a cuando se ejecuta la aplicación

Estos enfoques representan las decisiones de diseño que se toman al compilar la aplicación. Puede usar una estrategia exclusivamente o combinar ambas en función de la arquitectura y los requisitos.

Configuración en tiempo de implementación

La configuración en tiempo de implementación significa que las conexiones y configuraciones de servicio se determinan y se bloquean durante las fases azd provision y azd deploy. Mediante este enfoque, configurará los servicios con direcciones URL de punto de conexión específicas, cadenas de conexión y otra información de dependencia antes de que comiencen a ejecutarse. Esta configuración forma parte del entorno del servicio implementado, ya sea como variables de entorno o en archivos de configuración empaquetados con la implementación.

Aprovisionamiento en primer lugar de la infraestructura: cuando se ejecuta azd up o azd provision, primero se crea la infraestructura. Este paso genera las direcciones URL necesarias y las cadenas de conexión antes de que comience la implementación, lo que garantiza que los servicios dependientes tengan la información que necesitan.

Variables de salida: Bicep y Terraform pueden generar valores, como direcciones URL y cadenas de conexión, después del aprovisionamiento. Estas salidas están disponibles como variables de entorno durante la fase de implementación, por lo que puede configurar los servicios con los puntos de conexión correctos antes de comenzar.

Implementación secuencial: en escenarios complejos, es posible que tenga que implementar servicios en un orden específico. Usa azdganchos para controlar la secuencia de implementación, asegurándote de que los servicios de requisitos previos se ejecuten antes de implementar los servicios dependientes.

Patrón upsert de contenedor: Los Módulos Verificados de Azure (AVM) proporcionan patrones de aplicaciones de contenedores como container-app-upsert que funcionan sin problemas con el flujo de trabajo de dos fases de azd. Durante el aprovisionamiento, se crean la infraestructura y el contenedor inicial. Durante la implementación, azd inserta o actualiza la imagen de contenedor con variables de entorno actualizadas que incluyen valores generados durante el aprovisionamiento, como cadenas de conexión de base de datos o URL de servicios. Este patrón resuelve el problema de pollo y huevo al permitir que la infraestructura exista primero y, a continuación, actualizando la configuración del contenedor con toda la información de dependencia necesaria.

Flujo de trabajo de ejemplo para un front-end de React con un back-end de API de contenedor:

1. Ejecute azd up, que ejecuta fases de paquete, aprovisionamiento e implementación secuencialmente.
2. Durante el aprovisionamiento, Bicep crea la infraestructura de Azure Container Apps mediante módulos de AVM container-app-upsert y genera la dirección URL de la API de back-end.
3. Durante la implementación, azd actualiza automáticamente ambos contenedores con las variables de entorno correctas, incluida la dirección URL de LA API para el front-end.
4. Ambos servicios comienzan con la configuración correcta. Futuras ejecuciones de azd up o azd deploy actualizan los contenedores con los nuevos valores de configuración.

Configuración en tiempo de ejecución

La configuración en tiempo de ejecución permite a las aplicaciones cargar la configuración cuando la aplicación se ejecuta en lugar de durante la implementación. Este enfoque proporciona flexibilidad para actualizar los puntos de conexión de servicio, las cadenas de conexión y las directivas sin volver a implementar la aplicación.

Orígenes de configuración: las aplicaciones pueden cargar la configuración en tiempo de ejecución desde dos orígenes principales:

• Archivos de configuración local: implemente un archivo de configuración, como config.json, junto con la aplicación. La aplicación carga este archivo al inicio para obtener las direcciones URL actuales del punto de conexión, la configuración de autenticación y otros valores de configuración. Este enfoque funciona bien para marcos del lado cliente como React, Angular, Vue y Blazor WebAssembly que pueden capturar la configuración cuando la aplicación se inicia en el explorador.

• Servicios de configuración en la nube: use Azure App Configuration o servicios similares para administrar de forma centralizada la configuración en todos los entornos. Las aplicaciones consultan el servicio de configuración en el inicio o a petición para recuperar los valores actuales. Este enfoque es útil para las arquitecturas de microservicios en las que varios servicios necesitan actualizaciones de configuración coordinadas.

Ventajas: con cualquiera de los enfoques, los cambios de configuración estarán disponibles inmediatamente sin volver a implementar. Actualice el archivo de configuración a través de la canalización de implementación o cambie los valores de Azure App Configuration a través de Azure Portal. Cuando la aplicación se reinicia o actualiza su configuración, recoge los nuevos valores. Este patrón es especialmente útil para:

• Aplicaciones del lado del cliente que necesitan descubrir las URL de API del back-end, los extremos de autenticación y las ubicaciones de microservicios
• Los servicios back-end que necesitan actualizar las directivas de CORS a medida que cambian las direcciones URL de front-end
• Servicios que necesitan una configuración diferente en entornos de desarrollo, ensayo y producción

Flujo de trabajo de ejemplo para un front-end de React que detecta una API de back-end:

1. Ejecute azd up para aprovisionar la infraestructura e implementar ambos servicios.
2. Un hook posterior al despliegue genera un archivo config.json que contiene la URL del back-end y lo carga en la ubicación de almacenamiento del front-end.
3. La aplicación React captura config.json en el inicio para detectar el punto de conexión de API.
4. Para actualizar el punto de conexión más adelante, modifique config.json sin volver a implementar el front-end.

Este enfoque no funciona para sitios generados estáticamente en los que todo el contenido se representa previamente en tiempo de compilación.

Planeamiento del flujo de trabajo de implementación

Tenga en cuenta estos factores al diseñar el despliegue de pila completa.

1. Identificar dependencias: asigne qué servicios necesitan información de otros servicios. Para las dependencias unidireccionales (como una API en función de una base de datos), la plataforma de aprovisionamiento (Bicep o Terraform) controla el orden automáticamente. En el caso de las dependencias circulares (como los servicios front-end y back-end que necesitan las URLs del otro en el arranque), deberá diseñar una coordinación mediante estrategias de configuración durante la implementación o en tiempo de ejecución.
2. Aprovisionar antes de implementar: asegúrese de que existe toda la infraestructura antes de implementar el código de la aplicación.
3. Usar variables de entorno: pase la configuración entre las capas de infraestructura y aplicación mediante azd environment variables.
4. Diseño para varios entornos: planee cómo difiere la configuración en los entornos de desarrollo, almacenamiento provisional y producción.
5. Considere el orden de implementación: algunos escenarios pueden requerir la implementación de servicios en una secuencia específica.

El azd up comando controla la mayoría de los escenarios de implementación mediante la ejecución automática del aprovisionamiento seguido de la implementación en un único flujo de trabajo. En el caso de las aplicaciones únicas estándar, este enfoque funciona bien y requiere una configuración mínima.

Para despliegues más complicados, como el stack completo con dependencias circulares:

• Configurar el orden de servicio: en el azure.yaml archivo, defina los servicios en el orden en que desee implementarlos. Aunque azd implementa servicios en paralelo de forma predeterminada, puede usar enlaces para aplicar la implementación secuencial cuando sea necesario.

• Personalizar pasos de flujo de trabajo: invalide el flujo de trabajo predeterminado azd up definiendo una propiedad personalizada workflows en el azure.yaml archivo. Por ejemplo, puede cambiar el comportamiento predeterminado para ejecutar el aprovisionamiento antes de compilar el código fuente de la aplicación:

  name: todo-nodejs-mongo
  metadata:
    template: todo-nodejs-mongo@0.0.1-beta
  workflows:
    up: 
      steps:
        - azd: provision
        - azd: package
        - azd: deploy
  

  Este patrón es útil cuando el proceso de compilación necesita valores de configuración que solo están disponibles después de que se complete el aprovisionamiento.

• Aprovisionamiento e implementación independientes: en lugar de usar azd up, ejecute azd provision y azd deploy como comandos independientes. Esta separación es útil cuando es necesario comprobar la configuración de la infraestructura antes de implementar el código de la aplicación o al solucionar problemas de implementación. Puede aprovisionar la infraestructura una vez y luego implementar y reaprovechar código de aplicación varias veces sin volver a aprovisionar.

• Personalizar con enlaces: agregue enlaces previos y posteriores en el azure.yaml archivo para ejecutar lógica personalizada entre las fases de aprovisionamiento e implementación. Use enlaces para rellenar archivos de configuración, validar el estado del entorno o coordinar secuencias de implementación complejas.

procedimientos recomendados

Al desarrollar aplicaciones de pila completa con azd, siga estas mejores prácticas:

1. Mapear las dependencias temprano: identifique qué servicios necesitan información de otros servicios durante la fase de diseño. Distinga entre las dependencias unidireccionales que Bicep o Terraform controla automáticamente y las dependencias circulares que requieren estrategias de configuración en tiempo de implementación o tiempo de ejecución.
2. Elija la estrategia de configuración adecuada: use la configuración en tiempo de implementación cuando los servicios necesiten la configuración fijada durante la implementación. Use la configuración en tiempo de ejecución cuando necesite flexibilidad para actualizar la configuración sin volver a implementarla. Combine ambas estrategias cuando corresponda.
3. Utilice los módulos comprobados de Azure (AVM): Aproveche módulos de Bicep de Azure verificados, como para las aplicaciones de contenedor. Estos patrones funcionan sin problemas con azd el flujo de trabajo de dos fases para resolver dependencias circulares.
4. Personalice los flujos de trabajo cuando sea necesario: para implementaciones sencillas, use azd up con la configuración predeterminada. En escenarios complejos con dependencias circulares, personalice la workflows propiedad del azure.yaml archivo para controlar el orden del paquete, el aprovisionamiento y los pasos de implementación.
5. Aprovechar la configuración en tiempo real: para lograr la máxima flexibilidad en todos los entornos, use Azure App Configuration o archivos de configuración local para administrar los puntos de conexión de servicio y configuraciones que puede actualizar sin necesidad de volver a implementar.
6. Prueba entre entornos: asegúrese de que la estrategia de configuración funciona correctamente en entornos de desarrollo, almacenamiento provisional y producción en los que las direcciones URL y las configuraciones del servicio difieren.

Pasos siguientes

• Implementación en Azure Container Apps mediante la CLI para desarrolladores de Azure
• Plantillas de implementación de pila completa
• Introducción a las plantillas de la CLI para desarrolladores de Azure
• Explora el flujo de trabajo azd up