Configurer une application ASP.NET Core pour Azure App Service

Les applications ASP.NET Core doivent être déployées pour Azure App Service en tant que fichiers binaires compilés. L’outil de publication Visual Studio génère la solution, puis déploie directement les fichiers binaires compilés. Le moteur de déploiement App Service déploie d’abord le référentiel de code, puis compile les fichiers binaires.

Ce guide fournit des concepts clés et des instructions pour les développeurs ASP.NET Core. Si cet article est votre première utilisation d’Azure App Service, suivez d’abord Déployer une application web ASP.NET et déployer une application ASP.NET Core et Azure SQL Database sur Azure App Service.

dotnet --info

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

az webapp list-runtimes --os linux | grep DOTNET

Définir la version de .NET Core

az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"

Que se passe-t-il pour les runtimes obsolètes dans App Service ?

Les runtimes obsolètes sont déconseillés par l’organisation de maintenance ou présentent des vulnérabilités importantes. En conséquence, ils sont supprimés de la création et de la configuration des pages dans le portail. Lorsqu’un runtime obsolète est masqué dans le portail, toute application qui utilise toujours ce runtime continue à s’exécuter.

Si vous souhaitez créer une application avec une version d’exécution obsolète qui n’est plus affichée sur le portail, utilisez Azure CLI, un modèle ARM ou Bicep. Ces alternatives de déploiement vous permettent de créer des moteurs d’exécution obsolètes qui ont été supprimés du portail, mais qui sont toujours pris en charge.

Si un runtime est entièrement supprimé de la plateforme App Service, le propriétaire de votre abonnement Azure reçoit un e-mail avant la suppression.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Accéder aux variables d’environnement

Dans App Service, vous pouvez définir les paramètres d’application en dehors de votre code d’application. Vous pouvez ensuite y accéder dans n’importe quelle classe à l’aide du modèle d’injection de dépendance standard ASP.NET Core :

using Microsoft.Extensions.Configuration;

namespace SomeNamespace 
{
    public class SomeClass
    {
        private IConfiguration _configuration;
    
        public SomeClass(IConfiguration configuration)
        {
            _configuration = configuration;
        }
    
        public SomeMethod()
        {
            // retrieve nested App Service app setting
            var myHierarchicalConfig = _configuration["My:Hierarchical:Config:Data"];
            // retrieve App Service connection string
            var myConnString = _configuration.GetConnectionString("MyDbConnection");
        }
    }
}

Si vous configurez un paramètre d’application portant le même nom dans App Service et dans appsettings.json, la valeur App Service est prioritaire sur la appsettings.json valeur. En utilisant la valeur locale appsettings.json , vous pouvez déboguer l’application localement. En utilisant la valeur App Service, vous pouvez exécuter l’application en production avec des paramètres de production. Les chaînes de connexion fonctionnent de la même façon. À l’aide de cette méthode, vous pouvez conserver vos secrets d’application en dehors de votre référentiel de code et accéder aux valeurs appropriées sans modifier votre code.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"

Déployer des solutions à projets multiples

Lorsqu’une solution Visual Studio inclut plusieurs projets, le processus de publication de Visual Studio sélectionne le projet à déployer. Lorsque vous effectuez un déploiement sur le moteur de déploiement App Service, tel que Git ou zip deploy avec l’automatisation de build activée, le moteur de déploiement App Service sélectionne le premier projet d’application web ou de site web qu’il trouve comme application App Service. Vous pouvez spécifier le projet qu’App Service doit utiliser en spécifiant le paramètre d’application PROJECT. Par exemple, exécutez la commande suivante dans Cloud Shell :

az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"

Accéder aux journaux de diagnostic

ASP.NET Core offre un fournisseur de journalisation intégré pour App Service. Dans le fichier de program.cs votre projet, ajoutez le fournisseur à votre application via la ConfigureLogging méthode d’extension, comme illustré dans l’exemple suivant :

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureLogging(logging =>
        {
            logging.AddAzureWebAppDiagnostics();
        })
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.UseStartup<Startup>();
        });

Vous pouvez ensuite configurer et générer des journaux avec le modèle standard .NET Core. Consultez la journalisation dans .NET Core et ASP.NET Core.

Pour accéder aux journaux de console générés à partir du code de votre application dans App Service, activez la journalisation des diagnostics en exécutant la commande suivante dans Cloud Shell :

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Les valeurs possibles pour --level sont Error, Warning, Info, et Verbose. Chaque niveau suivant comprend le niveau précédent. Par exemple, Error inclut uniquement les messages d’erreur. Verbose inclut tous les messages.

Après avoir activé la journalisation des diagnostics, exécutez la commande suivante pour afficher le flux de journaux :

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Si les journaux de console ne s’affichent pas immédiatement, vérifiez à nouveau dans 30 secondes.

Pour arrêter le streaming de journaux à tout moment, sélectionnez Ctrl+C.

Pour plus d’informations sur la résolution des problèmes d’applications ASP.NET Core dans App Service, consultez Résoudre les problèmes ASP.NET Core sur Azure App Service et IIS.

Accéder à une page d’exceptions détaillées

Lorsque votre application ASP.NET Core génère une exception dans le débogueur Visual Studio, le navigateur affiche une page d’exception détaillée. Dans App Service, un message générique « HTTP 500 » ou « Une erreur s’est produite lors du traitement de votre demande » remplace cette page. Pour afficher la page d’exception détaillée dans App Service, ajoutez le ASPNETCORE_ENVIRONMENT paramètre d’application à votre application en exécutant la commande suivante dans Cloud Shell.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"

Détecter une session HTTPS

Dans App Service, l’arrêt TLS se produit au niveau des équilibreurs de charge réseau. Toutes les requêtes HTTPS atteignent votre application en tant que requêtes HTTP non chiffrées. Si votre logique d’application a besoin de savoir si les demandes utilisateur sont chiffrées, configurez l’intergiciel Forwarded Headers dans Startup.cs :

• Configurez l’intergiciel avec ForwardedHeadersOptions pour transférer les en-têtes X-Forwarded-For et X-Forwarded-Proto dans Startup.ConfigureServices.
• Ajoutez des plages d’adresses IP privées aux réseaux connus afin que l’intergiciel puisse approuver l’équilibreur de charge d’App Service.
• Appelez la méthode UseForwardedHeaders dans Startup.Configure avant d’appeler d’autres intergiciels.

Lorsque vous assemblez les trois éléments, votre code ressemble à l’exemple suivant :

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders =
            ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
        // These three subnets encapsulate the applicable Azure subnets. At the moment, it's not possible to narrow it down further.
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:10.0.0.0"), 104));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:192.168.0.0"), 112));
        options.KnownNetworks.Add(new IPNetwork(IPAddress.Parse("::ffff:172.16.0.0"), 108));
    });
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseForwardedHeaders();

    ...

    app.UseMvc();
}

Pour plus d’informations, consultez l’article Configurer ASP.NET Core pour l’utilisation de serveurs proxy et d’équilibreurs de charge.

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Contenu connexe

• Tutoriel : Déployer une application ASP.NET Core et Azure SQL Database

• Informations de référence sur les variables d’environnement et les paramètres d’application