Partager via

Vue d’ensemble de .NET sur Azure Container Apps

  • Article

Pour déployer une application .NET dans un environnement natif Cloud comme Azure Container Apps, vous devez prendre des décisions pour vous assurer que votre application s’exécute correctement et en toute sécurité. Ce guide décrit les concepts clés impliqués dans le déploiement d’une application .NET sur Azure Container Apps.

Azure Container Apps est un service de conteneur serverless complètement managé qui vous permet d’exécuter des applications conteneurisées sans avoir à gérer l’infrastructure sous-jacente. Container Apps inclut la prise en charge intégrée des fonctionnalités, notamment la mise à l’échelle automatique, les contrôles d’intégrité et les certificats TLS (Transport Layer Security).

Cet article détaille les concepts et les préoccupations importants que vous pouvez avoir lorsque vous déployez une application .NET sur Azure Container Apps.

Sélectionner un type de ressource

Container Apps prend en charge deux types de ressources : les applications et les travaux. Les applications exécutent en permanence des services, tandis que les travaux sont des tâches de courte durée conçues pour s’exécuter jusqu’à leur terme.

Lorsque vous vous préparez à déployer votre application, tenez compte des différences entre ces deux types d’application, car leur comportement affecte la façon dont vous gérez votre application .NET. Le tableau suivant décrit les différences dans des cas d’utilisation entre les applications et les travaux.

Cas d’usage Type de ressource
Une API web ASP.NET Core qui répond aux requêtes HTTP Application
Une application console .NET Core qui traite certaines données, puis se ferme Travail
Une service en arrière-plan en cours d’exécution continu qui traite les messages à partir d’une file d’attente Application
Un service d’optimisation d’image qui s’exécute uniquement lorsque des images volumineuses sont enregistrées dans un compte de stockage. Travail
Une application utilisant une infrastructure telle que Hangfire, Quartz.NET ou le Kit de développement logiciel (SDK) Azure WebJobs Application

Conteneuriser et déployer votre application .NET

Pour les applications ou les travaux, vous devez générer une image conteneur pour empaqueter votre application .NET. Pour plus d’informations sur la création d’images conteneur, consultez Images Docker pour ASP.NET Core.

Une fois configuré, vous pouvez déployer votre application sur Azure Container Apps en suivant ces guides :

Utiliser l’entrée HTTP

Azure Container Apps inclut une entrée HTTP intégrée qui vous permet d’exposer vos applications au trafic provenant de l’extérieur du conteneur. L’entrée Container Apps se trouve entre votre application et l’utilisateur final. Étant donné que l’entrée agit en tant qu’intermédiaire, tout ce que l’utilisateur final voit se termine à l’entrée, et tout ce que votre application voit commence à l’entrée.

L’entrée gère la terminaison TLS et les domaines personnalisés, ce qui élimine la nécessité de les configurer manuellement dans votre application. Par le biais de l’entrée, le port 443 est exposé pour le trafic HTTPS, et éventuellement le port 80 pour le trafic HTTP. L’entrée transfère les requêtes à votre application sur son port cible.

Si votre application a besoin de métadonnées sur la requête d’origine, elle peut utiliser des en-têtes X-forwarded.

Pour plus d’informations, consultez Entrées HTTP dans Azure Container Apps.

Définir un port cible

Pour recevoir le trafic, l’entrée est configurée sur un port cible où votre application écoute le trafic.

Lorsque ASP.NET Core est en cours d’exécution dans un conteneur, l’application écoute les ports comme configurés dans l’image conteneur. Lorsque vous utilisez les images officielles ASP.NET Core, votre application est configurée pour écouter HTTP sur un port par défaut. Le port par défaut dépend de la version ASP.NET Core.

Runtime Port cible
ASP.NET Core 7 et versions antérieures 80
ASP.NET Core 8 et versions ultérieures 8080

Lorsque vous configurez l’entrée, définissez le port cible sur le numéro correspondant à l’image conteneur que vous utilisez.

Définir des en-têtes X-forwarded

À mesure que l’entrée gère la requête HTTP d’origine, votre application voit l’entrée en tant que client. Il existe certaines situations où votre application doit connaître l’adresse IP du client d’origine ou le protocole d’origine (HTTP ou HTTPS). Vous pouvez accéder au protocole et aux informations IP via l’en-tête X-Forwarded-* de la requête.

Vous pouvez lire les valeurs d’origine à partir de ces en-têtes en accédant à l’objet ForwardedHeaders.

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

Pour plus d’informations sur l’utilisation des en-têtes de requête, consultez Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

Créez des applications natives Cloud .NET

Les applications déployées sur Container Apps fonctionnent souvent mieux lorsque vous créez des bases de principes natifs Cloud. Les sections suivantes vous aident à détailler les problèmes courants liés aux applications natives Cloud.

Configuration de l’application

Lors du déploiement de votre application .NET sur Azure Container Apps, utilisez des variables d’environnement pour stocker des informations de configuration au lieu d’utiliser appsettings.json. Cette pratique vous permet de configurer votre application de différentes manières dans différents environnements. En outre, l’utilisation de variables d’environnement facilite la gestion des valeurs de configuration sans avoir à regénérer et redéployer votre image conteneur.

Dans Azure Container Apps, vous définissez des variables d’environnement lorsque vous définissez le conteneur de votre application ou de votre travail. Stockez des valeurs sensibles dans les secrets et référencez-les en tant que variables d’environnement. Pour en savoir plus sur la gestion des secrets, consultez Gérer les secrets dans Azure Container Apps.

Identité managée

Azure Container Apps prend en charge l’identité managée, ce qui permet à votre application d’accéder à d’autres services Azure sans avoir à échanger d’informations d’identification. Pour en savoir plus sur la communication sécurisée entre les services Azure, consultez Identités managées dans Azure Container Apps.

Logging

Dans un environnement natif Cloud, la journalisation est essentielle pour le monitoring et la résolution des problèmes de vos applications. Par défaut, Azure Container Apps utilise Azure Log Analytics pour collecter des journaux à partir de vos conteneurs. Vous pouvez configurer d’autres fournisseurs de journalisation. Pour en savoir plus sur la journalisation d’applications, consultez Options de stockage et de monitoring des journaux dans Azure Container Apps.

Lorsque vous configurez un fournisseur de journalisation qui écrit des journaux dans la console, Azure Container Apps collecte et stocke les messages de journal pour vous.

Sondes d’intégrité

Azure Container Apps inclut la prise en charge intégrée des sondes d’intégrité, ce qui vous permet de surveiller l’intégrité de vos applications. Si une sonde détermine que votre application est dans un état non sain, votre conteneur est alors automatiquement redémarré. Pour en savoir plus sur les sondes d’intégrité, consultez Sondes d’intégrité dans Azure Container Apps.

Pour pouvoir implémenter une logique personnalisée afin de déterminer l’intégrité de votre application, vous pouvez configurer un point de terminaison de contrôle d’intégrité. Pour en savoir plus sur les points de terminaison de contrôle d’intégrité, consultez Contrôles d’intégrité dans ASP.NET Core.

Considérations relatives à la mise à l’échelle automatique

Par défaut, Azure Container Apps met automatiquement à l’échelle vos applications ASP.NET Core en fonction du nombre de requêtes HTTP entrantes. Vous pouvez également configurer des règles de mise à l’échelle automatique personnalisées en fonction d’autres métriques, telles que l’utilisation du processeur ou de la mémoire. Pour en savoir plus sur la mise à l’échelle, consultez Définir des règles de mise à l’échelle dans Azure Container Apps.

Dans .NET 8.0.4 et les versions ultérieures, les applications ASP.NET Core qui utilisent la protection des données sont automatiquement configurées pour conserver les données protégées accessibles à tous les répliques pendant que l’application est mise à l’échelle. Lorsque votre application commence à être mise à l’échelle, un gestionnaire de clés gère l’écriture et le partage de clés entre plusieurs révisions. Lors du déploiement de l’application, la variable d’environnement autoConfigureDataProtection est automatiquement définie sur true pour activer cette fonctionnalité. Pour plus d’informations sur cette configuration automatique, consultez cette demande de tirage GitHub.

La mise à l’échelle automatique modifie le nombre de réplicas de votre application en fonction des règles que vous définissez. Par défaut, Container Apps achemine de façon aléatoire le trafic entrant vers les réplicas de votre application ASP.NET Core. Étant donné que le trafic peut être divisé entre différents réplicas, votre application doit être sans état afin que votre application ne rencontre pas de problèmes liés à l’état.

Les fonctionnalités telles que l’anti-falsification, l’authentification, SignalR, Blazor Server et Razor Pages dépendent de la protection des données et nécessitent une configuration supplémentaire pour fonctionner correctement lors de la mise à l’échelle vers plusieurs réplicas.

Configurer la protection des données

ASP.NET Core dispose de fonctionnalités spéciales pour protéger et annuler la protection des données, telles que les données de session et les jetons anti-falsification. Par défaut, les clés de protection des données sont stockées sur le système de fichiers, ce qui n’est pas adapté à un environnement natif Cloud.

Si vous déployez une application .NET Aspire, la protection des données est automatiquement configurée pour vous. Dans toutes les autres situations, vous devez configurer la protection des données manuellement.

Configurer ASP.NET Core SignalR

ASP.NET Core SignalR nécessite une infrastructure d’intégration (backplane) pour distribuer des messages à plusieurs réplicas serveur. Lors du déploiement de votre application ASP.NET Core avec SignalR sur Azure Container Apps, vous devez configurer l’une des infrastructures d’intégration (backplanes) prises en charge, tels qu’Azure SignalR Service ou Redis. Pour en savoir plus sur les infrastructures d’intégration (backplanes), consultez Hébergement et mise à l’échelle d’ASP.NET Core SignalR.

Configurer Blazor Server

Les applications ASP.NET Core Blazor Server stockent l’état sur le serveur, ce qui signifie que chaque client doit être connecté au même réplica de serveur pendant leur session. Lors du déploiement de votre application Blazor Server sur Azure Container Apps, vous devez activer les sessions temporaires pour vous assurer que les clients sont routés vers le même réplica. Pour plus d’informations, consultez Affinité de session dans Azure Container Apps.