Microsoft Foundry: ¿basta con Deploy as Web App o necesitas un proxy de backend?

Los equipos siguen celebrando cuando el contenedor escucha en el puerto correcto. En las webapps de agentes respaldadas por Foundry, esa es la mitad fácil. La mitad difícil es con qué identidad se ejecuta la app, cómo fluye el OBO y cómo llega la salida a Foundry, Search y storage sin que la historia de la VNet se convierta en folclore.

Despliega el patrón empezando por la identidad y la red. El hostname y la versión de Node son lo mínimo.

Figura 1. Primero identidad y salida. Una webapp de Foundry es un diseño de identidad y salida que, además, ejecuta un contenedor. Celebrar el hostname no demuestra nada en staging.

Contexto y restricción

Un patrón habitual con frontales de contenedor en App Service delante de Foundry: las demos funcionan en un portátil y staging falla por DNS e identidad. Los prompts estaban bien. La managed identity y el private DNS, no.

Reutiliza ACR, App Insights y los registros de aplicación de Entra en lugar de inventar un segundo plano de identidad. La integración regional con VNet sirve para la salida. La entrada pública es una decisión de producto aparte. El on-behalf-of solo funciona si la app se ejecuta con la user-assigned identity correcta y con los permisos de API correctos. El private DNS y una planificación de subredes ganan a la confianza de "en mi portátil funciona".

La figura 2 es la página de Learn sobre la integración regional con VNet. La integración cambia la resolución de nombres y las rutas de salida más que los hostnames.

Figura 2. La integración regional con VNet da a la app una ruta de salida hacia los private endpoints. Por sí sola no decide si los usuarios llegan a la app desde internet público. Fuente: Microsoft Learn: App Service VNet integration.

Diseño

1. Reutiliza el plano de identidad

Un único criterio para el registro de aplicación de Entra de la API, una user-assigned managed identity para los recursos de Azure y App Insights coherente. No crees registros de aplicación paralelos por entorno sin un mapa. Reutiliza ACR para que el origen de las imágenes siga siendo aburrido. Los nuevos objetos de identidad necesitan responsables y un plan de rotación.

2. Separa las decisiones de producto sobre la entrada de la mecánica de salida

La integración con VNet da a la app una ruta de salida hacia los private endpoints. Por sí sola no decide si los usuarios llegan a la app desde internet público, a través de Front Door o con acceso privado. Escríbelo en el diseño como dos secciones. Mezclarlas produce diagramas que nadie puede implementar. La figura 3 muestra la separación.

Figura 3. Postura de entrada frente a mecánica de salida. Entrada pública con salida privada es una elección válida para una etapa. Una nube con la etiqueta "privado" no es un diseño.

3. El OBO necesita la identidad de ejecución y los permisos correctos

Los flujos OBO sin secretos fallan de formas confusas cuando a la identidad de la app le faltan permisos de API o cuando la audiencia del token es incorrecta. Valida la identidad y el consentimiento antes de ajustar prompts. "El modelo va lento" es una etiqueta equivocada muy común para los fallos de autenticación.

4. Planifica las subredes y el private DNS a propósito

Los private endpoints de Foundry, Cognitive Search y storage necesitan un DNS que la subred de integración de App Service use de verdad. Las zonas de private DNS que faltan aparecen como errores intermitentes de la plataforma que parecen bugs del SDK. Revisa con una checklist la resolución de nombres desde la app hacia fuera.

5. Checklist de despliegue: identidad y DNS antes que calidad de prompts

Condiciona los releases a: identidad asignada, asignaciones de roles presentes, private DNS resolviendo, salida a las dependencias verificada y App Insights recibiendo datos. Las evaluaciones de prompts van después, cuando el plano es honesto. Si no, iteras sobre la redacción mientras la red pierde llamadas. La figura 4 muestra el orden de las pruebas.

Figura 4. Orden de las pruebas. DNS, roles y OBO antes que las suites de prompts. Invierte el orden y obtendrás evaluaciones preciosas sobre un plano que sigue sin llegar a las dependencias de producción.

6. Los contenedores son portables; el plano no

La misma imagen puede ejecutarse en un laboratorio sin private endpoints. Eso no demuestra que esté listo para un MVP. La paridad de entornos en identidad y red importa más que coincidir en el nivel de parche de Node.

Reutilizar sin congelar lo que no toca

Reutilizar ACR y App Insights no significa que todas las etapas compartan los mismos secretos ni el mismo conjunto de private endpoints. Reutiliza el patrón y los tipos de recursos. Aísla las instancias. Escribe la matriz: qué registros, qué identidades y qué zonas DNS por etapa. La matriz es aburrida. La caída por una fila que falta no lo es.

Orden de las pruebas en staging

Demuestra la resolución DNS hacia los private endpoints desde la app. Demuestra las asignaciones de roles de la managed identity en Foundry, Search y storage. Demuestra el OBO con una ruta real de usuario. Solo entonces ejecuta las suites de prompts. Invertir ese orden produce hojas de evaluación preciosas sobre un plano que sigue sin llegar al grafo de dependencias en producción. La identidad y la salida son el release train; los prompts van en el vagón de pasajeros.

Si staging todavía usa endpoints públicos de Foundry "temporalmente", registra esa deuda en el ADR con un responsable. Las excepciones de red temporales suelen sobrevivir hasta la primera revisión de seguridad.

Guarda un único diagrama de red por etapa en el repo junto a la checklist, para que la incorporación no dependa de una foto de la pizarra.

Errores comunes

Obsesión por el hostname. TLS y DNS del hostname listos; la salida a Foundry, ignorada.

Segundo plano de identidad. Registros de aplicación duplicados y URI de redirección contradictorias.

OBO con la MI equivocada. Los tokens se emiten; las llamadas a los recursos dan 401/403.

"Funciona en el portátil" como prueba de staging. Los endpoints públicos de Foundry ocultan huecos en el private DNS.

Ajustar prompts durante una caída. Ciclos perdidos en la capa equivocada.

Dar por hecha la entrada pública para siempre. Más adelante el producto la quiere privada y rediseñar sale caro.

Úsalo tal cual o adáptalo

Úsalo tal cual

• App Service con contenedor e integración regional con VNet para la salida privada.
• User-assigned managed identity más registros de aplicación de Entra con nombre; sin planos duplicados sin un mapa.
• OBO sin secretos con permisos de API verificados.
• Private endpoints y private DNS para Foundry, Search y storage según lo que pida la etapa.
• Postura de entrada (pública, con un front delante o privada) decidida de forma explícita por etapa.
• La checklist de release valida identidad y DNS antes del trabajo con prompts y evaluaciones.

Adáptalo antes de usarlo

Las user-assigned identities y los private endpoints cuestan tiempo de configuración y conocimiento de la plataforma. A cambio eliminan los secretos desperdigados y la exposición pública de las dependencias. Las checklists estrictas ralentizan el primer despliegue y aceleran cada incidente posterior. Reutilizar apps de Entra entre etapas exige cuidar bien las redirecciones y las audiencias; duplicarlas parece más fácil hasta que se multiplican las pantallas de consentimiento. La integración con VNet limita las opciones de escalado; documéntalas en lugar de descubrirlas en pleno incendio.

Referencias principales: App Service VNet integration, managed identities y la guía de red de Microsoft Foundry en Microsoft Learn.

¿Te planteas usar hosted agents de Foundry en lugar de este backend? Lee primero Los hosted agents de Foundry siguen necesitando una puerta de entrada: los hosted agents trasladan el runtime, no el inicio de sesión, los roles ni el mapa de sesiones por usuario.

Despliega la identidad y la salida como el producto. Después ajusta el host de Node. En la demo el orden es el contrario; en producción, no.