Información general sobre .NET en Azure Container Apps
Para implementar una aplicación .NET en un entorno nativo de nube, como Azure Container Apps, debe tomar decisiones para asegurarse de que la aplicación se ejecuta sin problemas y de forma segura. En esta guía se describen los conceptos clave implicados en la implementación de una aplicación .NET en Azure Container Apps.
Azure Container Apps es un servicio de contenedor sin servidor totalmente administrado que permite ejecutar aplicaciones en contenedores sin tener que administrar la infraestructura subyacente. Container Apps incluye compatibilidad integrada con características como las de escalado automático, comprobaciones de estado y certificados de seguridad de la capa de transporte (TLS).
En este artículo se detallan los conceptos y preocupaciones importantes a medida que implementa una aplicación .NET en Azure Container Apps.
Seleccione de un tipo de recursos
Container Apps admite dos tipos de recursos: aplicaciones y trabajos. Las aplicaciones ejecutan continuamente servicios, mientras que los trabajos son tareas de corta duración diseñados para ejecutarse hasta su finalización.
A medida que se prepara para implementar la aplicación, tenga en cuenta las diferencias entre estos dos tipos de aplicación, ya que su comportamiento afecta a la forma de administrar la aplicación .NET. En la tabla siguiente se describen las diferencias de casos de uso entre aplicaciones y trabajos.
| Caso de uso | Tipo de recurso |
|---|---|
| Una API web de ASP.NET Core que atiende solicitudes HTTP | Aplicación |
| Una aplicación de consola de .NET Core que procesa algunos datos y, después, sale | Trabajo |
| Un servicio de ejecución continua en segundo plano que procesa los mensajes de una cola | Aplicación |
| Un servicio de optimización de imágenes que se ejecuta solo cuando se guardan imágenes grandes en una cuenta de almacenamiento. | Trabajo |
| Una aplicación que usa un marco como Hangfire, Quartz.NET o el SDK de Azure WebJobs | Aplicación |
Inclusión en contenedores e implementación de la aplicación .NET
Tanto para las aplicaciones como para los trabajos, debe crear una imagen de contenedor para empaquetar la aplicación .NET. Para más información sobre cómo crear una imagen de contenedor, vea Imágenes de Docker para ASP.NET Core.
Una vez que se configure, puede implementar la aplicación en Azure Container Apps mediante estas guías:
- Tutorial: Implementación en Azure Container Apps mediante Visual Studio
- Inicio rápido: Compilación e implementación desde un repositorio en Azure Container Apps
- Creación de un trabajo con Azure Container Apps
Uso de la entrada HTTP
Azure Container Apps incluye una entrada HTTP integrada que le permite exponer las aplicaciones al tráfico procedente desde fuera del contenedor. La entrada de Container Apps se ubica entre la aplicación y el usuario final. Como la entrada actúa de intermediario, lo que el usuario final ve termina en la entrada, y lo que la aplicación ve comienza en la entrada.
La entrada administra la terminación TLS y los dominios personalizados, lo que elimina la necesidad de configurarlos manualmente en la aplicación. Mediante la entrada, el puerto 443 se expone para el tráfico HTTPS y, opcionalmente, el puerto 80 para el tráfico HTTP. La entrada reenvía las solicitudes a la aplicación en su puerto de destino.
Si la aplicación necesita metadatos sobre la solicitud original, puede usar encabezados X reenviados.
Para más información, vea Entrada HTTP en Azure Container Apps.
Definición de un puerto de destino
Para recibir tráfico, la entrada se configura en un puerto de destino donde la aplicación escucha el tráfico.
Cuando ASP.NET Core se ejecuta en un contenedor, la aplicación escucha en los puertos configurados en la imagen de contenedor. Al usar las imágenes oficiales de ASP.NET Core, la aplicación está configurada para escuchar HTTP en un puerto predeterminado. El puerto predeterminado depende de la versión de ASP.NET Core.
| Tiempo de ejecución | Puerto de destino |
|---|---|
| ASP.NET Core 7 y versiones anteriores | 80 |
| ASP.NET Core 8 y versiones posteriores | 8080 |
Al configurar la entrada, establezca el puerto de destino en el número correspondiente a la imagen de contenedor que use.
Definición de encabezados X reenviados
A medida que la entrada controla la solicitud HTTP original, la aplicación ve la entrada como cliente. Hay algunas situaciones en las que la aplicación debe conocer la dirección IP del cliente original o el protocolo original (HTTP o HTTPS). Puede acceder a la información de protocolo e IP mediante el encabezado X-Forwarded-* de la solicitud.
Puede leer los valores originales de estos encabezados si accede al objeto ForwardedHeaders.
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
options.ForwardedHeaders =
ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
options.KnownNetworks.Clear();
options.KnownProxies.Clear();
});
Para más información sobre cómo trabajar con encabezados de solicitud, vea Configuración de ASP.NET Core para trabajar con servidores proxy y equilibradores de carga.
Compilación de aplicaciones .NET nativas de nube
Las aplicaciones implementadas en Container Apps suelen funcionar mejor cuando se basan en los principios nativos de nube. Las secciones siguientes ayudan a detallar las preocupaciones comunes relacionadas con las aplicaciones nativas de nube.
Configuración de aplicaciones
Al implementar la aplicación .NET en Azure Container Apps, use variables de entorno para almacenar información de configuración en lugar de usar appsettings.json. Este procedimiento le permite configurar la aplicación de maneras diferentes en entornos diferentes. Además, el uso de variables de entorno facilita la administración de valores de configuración sin tener que volver a compilar e implementar la imagen de contenedor.
En Azure Container Apps, se establecen variables de entorno al definir el contenedor de la aplicación o del trabajo. Almacene los valores confidenciales en secretos y haga referencia a ellos como variables de entorno. Para más información sobre la administración de secretos, vea Administración de secretos en Azure Container Apps.
Identidad administrada
Azure Container Apps admite la identidad administrada, lo que permite que la aplicación acceda a otros servicios de Azure sin necesidad de intercambiar credenciales. Para más información sobre la comunicación segura entre servicios de Azure, vea Identidades administradas en Azure Container Apps.
Registro
En un entorno nativo de nube, el registro es fundamental para supervisar y solucionar problemas de las aplicaciones. De manera predeterminada, Azure Container Apps usa Azure Log Analytics para recopilar registros de los contenedores. Puede configurar otros proveedores de registro. Para más información sobre el registro de aplicaciones,vea Opciones de almacenamiento y supervisión de registros en Azure Container Apps.
Al configurar un proveedor de registro que escribe registros en la consola, Azure Container Apps recopila y almacena los mensajes de registro de forma automática.
Sondeos de estado
Azure Container Apps incluye compatibilidad integrada con sondeos de estado, lo que le permite supervisar el estado de las aplicaciones. Si un sondeo determina que la aplicación está en un estado incorrecto, el contenedor se reiniciará automáticamente. Para más información sobre los sondeos de estado, vea Sondeos de estado en Azure Container Apps.
Para poder implementar lógica personalizada a fin de determinar el estado de la aplicación, puede configurar un punto de conexión de comprobación de estado. Para más información sobre los puntos de conexión de comprobación de estado, vea Comprobaciones de estado en ASP.NET Core.
Consideraciones de escalado automático
De manera predeterminada, Azure Container Apps escala automáticamente las aplicaciones ASP.NET Core en función del número de solicitudes HTTP entrantes. También puede configurar reglas de escalado automático personalizadas basadas en otras métricas, como el uso de CPU o memoria. Para más información sobre el escalado automático, vea Establecimiento de reglas de escalado en Azure Container Apps.
En .NET 8.0.4 y versiones posteriores, las aplicaciones de ASP.NET Core que usan la protección de datos se configuran automáticamente para mantener los datos protegidos accesibles para todas las réplicas a medida que se escala la aplicación. Cuando la aplicación comienza a escalarse, un administrador de claves controla la escritura y el uso compartido de claves en varias revisiones. A medida que se implementa la aplicación, la variable de entorno autoConfigureDataProtection se establece automáticamente en true para habilitar esta característica. Para obtener más información sobre esta configuración automática, consulte esta solicitud de cambios de GitHub.
El escalado automático cambia el número de réplicas de la aplicación en función de las reglas que defina. De manera predeterminada, Container Apps enruta aleatoriamente el tráfico entrante a las réplicas de la aplicación ASP.NET Core. Como el tráfico se puede dividir entre diferentes réplicas, la aplicación debe estar sin estado para que no experimente problemas relacionados con el estado.
Las características como las de antifalsificación, autenticación, SignalR, Blazor Server y Razor Pages dependen de la protección de datos y necesitan una configuración adicional para funcionar correctamente al escalar a varias réplicas.
Configuración de la protección de datos
ASP.NET Core tiene características especiales para proteger y desproteger datos, como datos de sesión y tokens antifalsificación. De manera predeterminada, las claves de protección de datos se almacenan en el sistema de archivos, lo que no es adecuado para un entorno nativo de nube.
Si va a implementar una aplicación .NET Aspire, la protección de datos se configura automáticamente. En todas las demás situaciones, debe configurar manualmente la protección de datos.
Configuración de ASP.NET Core SignalR
En ASP.NET Core SignalR se necesita un backplane para distribuir mensajes a varias réplicas de servidor. Al implementar la aplicación ASP.NET Core con SignalR en Azure Container Apps, debe configurar uno de los backplanes admitidos, como Azure SignalR Service o Redis. Para más información sobre los backplanes, vea Hospedaje y escalado de ASP.NET Core SignalR.
Configuración de Blazor Server
Las aplicaciones Blazor Server de ASP.NET Core almacenan el estado en el servidor, lo que significa que cada cliente debe estar conectado a la misma réplica de servidor durante su sesión. Al implementar la aplicación Blazor Server en Azure Container Apps, debe habilitar sesiones permanentes para asegurarse de que los clientes se enrutan a la misma réplica. Para más información, vea Afinidad de sesión en Azure Container Apps.