Configurare un'app ASP.NET Core per Servizio app di Azure

Le app ASP.NET Core devono essere distribuite su Azure App Service sotto forma di file binari compilati. Lo strumento di pubblicazione di Visual Studio compila la soluzione e quindi distribuisce direttamente i file binari compilati. Il motore di distribuzione del servizio app distribuisce prima il repository di codice e quindi compila i file binari.

Questa guida fornisce concetti chiave e istruzioni per gli sviluppatori ASP.NET Core. Se è la prima volta che si usa il servizio app di Azure, seguire prima l'esercitazione di avvio rapido di ASP.NET Core e ASP.NET Core con il database SQL.

dotnet --info

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

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

Impostare la versione di .NET Core

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

Cosa accade ai runtime obsoleti nel servizio app?

I runtime obsoleti sono deprecati dall'organizzazione di gestione o hanno rilevato vulnerabilità significative. Di conseguenza, vengono rimossi dalle pagine di creazione e configurazione nel portale. Quando un runtime obsoleto è nascosto dal portale, qualsiasi app che usa ancora tale runtime continua a essere eseguita.

Se si vuole creare un'app con una versione di runtime obsoleta non più visualizzata nel portale, usare l'interfaccia della riga di comando di Azure, il modello arm o Bicep. Queste alternative di distribuzione consentono di creare runtime obsoleti, che sono stati rimossi dal portale, ma sono ancora supportati.

Se un runtime viene rimosso completamente dalla piattaforma del servizio app, il proprietario della sottoscrizione di Azure riceve un avviso di posta elettronica prima della rimozione.

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"

Accedere alle variabili di ambiente

Nel servizio app è possibile impostare le impostazioni dell'app all'esterno del codice dell'app. È quindi possibile accedervi in qualsiasi classe usando il modello standard di inserimento delle dipendenze 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");
        }
    }
}

Se si configura un'impostazione dell'app con lo stesso nome nel Servizio App e in appsettings.json, ad esempio, il valore del Servizio App ha la precedenza su quello di appsettings.json. Usando il valore locale appsettings.json , è possibile eseguire il debug dell'app in locale, ma usando il valore del servizio app, è possibile eseguire l'app nell'ambiente di produzione con le impostazioni di produzione. Le stringhe di connessione funzionano allo stesso modo. Usando questo metodo, è possibile mantenere i segreti dell'applicazione all'esterno del repository di codice e accedere ai valori appropriati senza modificare il codice.

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"

Distribuire soluzioni multiprogetto

Quando una soluzione di Visual Studio include più progetti, il processo di pubblicazione di Visual Studio seleziona automaticamente il progetto da distribuire. Quando si esegue la distribuzione nel motore di distribuzione del servizio app, ad esempio con Git o con distribuzione ZIP con automazione della compilazione abilitata, il motore di distribuzione del servizio app seleziona il primo sito Web o il progetto di applicazione Web trovato come app del servizio app. È possibile specificare quale servizio app di progetto usare specificando l'impostazione dell'app PROJECT. Ad esempio, eseguire il comando seguente in Cloud Shell:

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

Accedere ai log di diagnostica

ASP.NET Core offre un provider di logging integrato per il Servizio App. Nel file program.cs del progetto, aggiungere il provider all'applicazione tramite il metodo di estensione ConfigureLogging, come illustrato nell'esempio seguente:

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

È quindi possibile configurare e generare log con il modello .NET Core standard.

Per accedere ai log della console generati dall'interno del codice dell'applicazione nel servizio app, attivare la registrazione diagnostica eseguendo il comando seguente in Cloud Shell:

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

I valori possibili per --level sono Error, Warning, Infoe Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo messaggi di errore. Verbose include tutti i messaggi.

Dopo aver attivato la registrazione diagnostica, eseguire il comando seguente per visualizzare il flusso di log:

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

Se i log della console non vengono visualizzati immediatamente, controllare di nuovo in 30 secondi.

Per arrestare lo streaming dei log in qualsiasi momento, selezionare CTRL+C.

Per altre informazioni sulla risoluzione dei problemi ASP.NET app Core nel servizio app, vedere Risolvere i problemi di ASP.NET Core nel servizio app di Azure e IIS.

Accedere a una pagina dettagliata delle eccezioni

Quando l'app ASP.NET Core genera un'eccezione nel debugger di Visual Studio, il browser visualizza una pagina dettagliata dell'eccezione, ma nel servizio app tale pagina viene sostituita da un generico "HTTP 500" o "Si è verificato un errore durante l'elaborazione della richiesta". Per visualizzare la pagina dettagliata delle eccezioni nel servizio app, aggiungere l'impostazione dell'app ASPNETCORE_ENVIRONMENT all'app eseguendo il comando seguente in Cloud Shell.

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

Rilevare una sessione HTTPS

Nel servizio app la terminazione TLS/SSL avviene nei servizi di bilanciamento del carico di rete, quindi tutte le richieste HTTPS raggiungono l'app come richieste HTTP non crittografate. Se la logica dell'app deve sapere se le richieste dell'utente sono crittografate o meno, configurare il middleware intestazioni inoltrate in Startup.cs:

• Configurare il middleware con ForwardedHeadersOptions per inoltrare le intestazioni X-Forwarded-For e X-Forwarded-Proto in Startup.ConfigureServices.
• Aggiungere intervalli di indirizzi IP privati alle reti note, in modo che il middleware possa considerare attendibile il bilanciamento del carico di Servizio app.
• Richiamare il UseForwardedHeaders metodo in Startup.Configure prima di chiamare un altro middleware.

Quando si assemblano i tre elementi, il codice sarà simile all'esempio seguente:

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();
}

Per altre informazioni, vedere Configurare ASP.NET Core per l'uso con server proxy e servizi di bilanciamento del carico.

https://<app-name>.scm.azurewebsites.net/webssh/host

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

Contenuti correlati

• Esercitazione: Applicazione ASP.NET Core con SQL Database

• Informazioni di riferimento sulle variabili di ambiente e sulle impostazioni dell'app