Ahtesham-Latif/Tie-Breaker-App

Despliegue en Azure App Service (Node.js)

Esta skill describe la ruta óptima y de mejores prácticas para desplegar una aplicación Node.js en Azure App Service (Linux), mientras se conecta de forma segura a un agente de Azure AI Foundry mediante Managed Identity.

1. Configuración de Infraestructura en la Nube

• Plan de App Service: Elige siempre un nivel dedicado (ej. Basic B1) para producción. Los niveles Gratis (F1) tienen estrictas cuotas de CPU de 60 minutos diarios que apagarán forzosamente la aplicación (provocando un error 403 Stopped).

2. Autenticación y Managed Identity (Sin Contraseñas)

1. Código: Usa DefaultAzureCredential de @azure/identity en el backend Node.js.
2. Habilitar Identidad: En el portal de Azure App Service, ve a Configuración > Identidad y activa Asignada por el sistema.
3. Permisos IAM: En el proyecto de Azure AI de destino, ve a Control de acceso (IAM) y asigna el rol Azure AI Developer a la Managed Identity del App Service. (Nota: Cognitive Services OpenAI User no es suficiente para Agentes de Orquestación de Azure Foundry).

3. Variables de Entorno (La Trampa Frontend vs Backend)

Al desplegar una aplicación full-stack (React/Vite + Node.js) mediante GitHub Actions, las variables de entorno deben dividirse lógicamente:

El Frontend (Vite)

• Las variables con prefijo VITE_ (ej. claves de Supabase) se incrustan en el HTML/JS estático en tiempo de compilación.
• Dónde configurarlas: DEBEN almacenarse en GitHub Secrets y mapearse explícitamente en tu archivo .github/workflows bajo el bloque env: para el paso de npm run build.
• Peligro: Si solo están en Azure y no en GitHub Actions, Vite compilará el frontend con variables vacías.

El Backend (Node.js)

• El archivo server.js en ejecución lee las variables de entorno en tiempo de ejecución desde el contenedor en la nube.
• Dónde configurarlas: Configura las variables (ej. endpoints de Azure AI, claves de Supabase para el backend) directamente en el Portal de Azure bajo Configuración > Variables de entorno.
• Peligro: El backend de Azure App Service NO hereda los secrets de GitHub Actions. Debes configurarlos manualmente en el Portal de Azure.
• Crucial: Las variables se cargan en memoria exactamente una vez cuando se inicia el proceso de Node.js. Si se agrega o cambia una variable, debes hacer clic explícitamente en Reiniciar en la página de descripción general del App Service.
• Para confiar en el Azure Load Balancer (necesario para express-rate-limit), asegúrate de que la aplicación Express tenga app.set('trust proxy', 1);.

4. Pipeline CI/CD de GitHub Actions

La estrategia de despliegue más segura evita que los motores de compilación entren en conflicto (GitHub vs. Azure Oryx). Deja que GitHub haga el 100% de la compilación y empaquetado.

Mejores Prácticas del Flujo de Trabajo:

1. GitHub ejecuta npm install y la compilación del frontend (npm run build).
2. GitHub sube un artefacto que contiene la salida compilada (dist), los archivos del backend (server.js) y, crucialmente, la carpeta node_modules.
   • ¿Por qué? Si se omite node_modules, el motor Oryx de Azure intentará compilar la aplicación por sí mismo ejecutando npm run build, lo que fallará porque los archivos fuente originales (index.html) no fueron subidos.
3. Usa azure/webapps-deploy@v3 con un Perfil de Publicación almacenado como un Secreto de GitHub.