Configurare un'app ASP.NET Core per Servizio app di Azure
Nota
Per ASP.NET in .NET Framework, vedere Configurare un'app ASP.NET per Servizio app di Azure. Se l'app ASP.NET Core viene eseguita in un contenitore Windows o Linux personalizzato, vedere Configurare un contenitore personalizzato per Servizio app di Azure.
ASP.NET Core le app devono essere distribuite in Servizio app di Azure come file binari compilati. Lo strumento di pubblicazione di Visual Studio compila la soluzione e quindi distribuisce direttamente i file binari compilati, mentre il motore di distribuzione servizio app distribuisce prima il repository del codice e quindi compila i file binari.
Questa guida fornisce concetti chiave e istruzioni per gli sviluppatori di ASP.NET Core. Se non è mai stato usato Servizio app di Azure, seguire prima l'esercitazione introduttiva ASP.NET Core e ASP.NET Core con database SQL esercitazione.
Visualizzare le versioni di runtime di .NET Core supportate
In servizio app le istanze di Windows hanno già tutte le versioni di .NET Core supportate installate. Per visualizzare le versioni di runtime e SDK di .NET Core disponibili, passare a https://<app-name>.scm.azurewebsites.net/DebugConsole ed eseguire il comando seguente nella console basata su browser:
dotnet --info
Mostra versione di .NET Core
Per visualizzare la versione corrente di .NET Core, eseguire il comando seguente nella Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Per visualizzare tutte le versioni di .NET Core supportate, eseguire il comando seguente nella Cloud Shell:
az webapp list-runtimes --os linux | grep DOTNET
Impostare la versione di .NET Core
Impostare il framework di destinazione nel file di progetto per il progetto ASP.NET Core. Per altre informazioni, vedere Selezionare la versione di .NET Core da usare nella documentazione di .NET Core .
Eseguire il comando seguente nella Cloud Shell per impostare la versione di .NET Core su 3.1:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|3.1"
Personalizzare l'automazione della compilazione
Se si distribuisce l'app usando Git o pacchetti zip con automazione di compilazione abilitata, la procedura di automazione della compilazione servizio app tramite la sequenza seguente:
- Esegue lo script personalizzato se specificato da
PRE_BUILD_SCRIPT_PATH. - Eseguire
dotnet restoreper ripristinare le dipendenze NuGet. - Eseguire
dotnet publishper compilare un file binario per la produzione. - Esegue lo script personalizzato se specificato da
POST_BUILD_SCRIPT_PATH.
PRE_BUILD_COMMAND e POST_BUILD_COMMAND sono variabili di ambiente vuote per impostazione predefinita. Per eseguire comandi pre-compilazione, definire PRE_BUILD_COMMAND. Per eseguire comandi post-compilazione, definire POST_BUILD_COMMAND.
Nell'esempio seguente vengono specificate le due variabili, separate da virgole, per una serie di comandi.
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"
Per altre variabili di ambiente per personalizzare l'automazione della compilazione, vedere Configurazione di Oryx.
Per altre informazioni su come servizio app vengono eseguite e compilate app ASP.NET Core in Linux, vedere La documentazione di Oryx: Come vengono rilevate e compilate le app .NET Core.
Accedere alle variabili di ambiente
Nel servizio app è possibile configurare le impostazioni dell'app al di fuori del codice dell'app. È quindi possibile accedervi in qualsiasi classe usando lo standard ASP.NET Core modello di inserimento delle dipendenze:
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 in servizio app e in appsettings.json, ad esempio, il valore servizio app ha la precedenza sul valore appsettings.json. Il valore appsettings.json locale consente di eseguire il debug dell'app in locale, ma il valore servizio app consente di eseguire l'app in produzione con impostazioni di produzione. Le stringhe di connessione funzionano nello stesso modo. In questo modo, è possibile mantenere i segreti dell'applicazione all'esterno del repository di codice e accedere ai valori appropriati senza modificare il codice.
Nota
Si noti che i dati di configurazione gerarchici in appsettings.json vengono accessibili usando il __ delimitatore (doppia sottolineatura) standard in Linux in .NET Core. Per eseguire l'override di un'impostazione di configurazione gerarchica specifica in servizio app, impostare il nome dell'impostazione dell'app con lo stesso formato delimitato nella chiave. È possibile eseguire l'esempio seguente nella Cloud Shell:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
Nota
Si noti che i dati di configurazione gerarchici in appsettings.json vengono accessibili usando il : delimitatore standard di .NET Core. Per eseguire l'override di un'impostazione di configurazione gerarchica specifica in servizio app, impostare il nome dell'impostazione dell'app con lo stesso formato delimitato nella chiave. È possibile eseguire l'esempio seguente nella Cloud Shell:
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 include già la selezione del progetto da distribuire. Quando si distribuisce nel motore di distribuzione servizio app, ad esempio con Git o con distribuzione ZIP con automazione di compilazione abilitata, il motore di distribuzione servizio app seleziona il primo sito Web o il progetto applicazione Web che trova come app servizio app. È possibile specificare quale servizio app progetto deve usare specificando l'impostazione dell'appPROJECT. Ad esempio, eseguire il comando seguente nella 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 fornisce un provider di registrazione predefinito per servizio app. In Program.cs del progetto aggiungere il provider all'applicazione tramite il ConfigureLogging metodo di estensione, 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, Info e Verbose. Ogni livello successivo include il livello precedente. Ad esempio, Error include solo i messaggi di errore, mentre Verbose include tutti i messaggi.
Dopo aver attivato la registrazione diagnostica, eseguire il comando seguente per visualizzare il flusso di registrazione:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Se i log di console non sono immediatamente visibili, controllare nuovamente dopo 30 secondi.
Nota
È anche possibile esaminare i file di log nel browser all'indirizzo https://<app-name>.scm.azurewebsites.net/api/logs/docker.
Per interrompere lo streaming dei log in qualsiasi momento, digitare Ctrl+C.
Per altre informazioni sulla risoluzione dei problemi delle app ASP.NET Core in servizio app, vedere Risolvere i problemi ASP.NET Core in Servizio app di Azure e IIS
Pagina Informazioni dettagliate sulle eccezioni
Quando l'app ASP.NET Core genera un'eccezione nel debugger di Visual Studio, il browser visualizza una pagina di eccezione dettagliata, ma in servizio app tale pagina viene sostituito da un errore HTTP 500 generico o si è verificato un errore durante l'elaborazione della richiesta. Per visualizzare la pagina dettagliata dell'eccezione in servizio app, Aggiungere l'impostazione dell'app ASPNETCORE_ENVIRONMENT all'app eseguendo il comando seguente nella Cloud Shell.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"
Rilevare una sessione HTTPS
In servizio app la terminazione TLS/SSL si verifica 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 conoscere se le richieste utente sono crittografate o meno, configurare il middleware Intestazioni inoltrate in Startup.cs:
- Configurare il middleware con ForwardedHeadersOptions per l'inoltro delle intestazioni
X-Forwarded-ForeX-Forwarded-ProtoinStartup.ConfigureServices. - Aggiungere intervalli di indirizzi IP privati alle reti note, in modo che il middleware possa considerare attendibile il servizio di bilanciamento del carico servizio app.
- Richiamare il metodo UseForwardedHeaders in
Startup.Configureprima di chiamare altri middleware.
L'inserimento di tutti e tre gli elementi è 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'utilizzo di server proxy e servizi di bilanciamento del carico.
Aprire una sessione SSH nel browser
Per aprire una sessione SSH diretta con il contenitore, l'app deve essere in esecuzione.
Incollare l'URL seguente nel browser e sostituire <app-name> con il nome dell'app:
https://<app-name>.scm.azurewebsites.net/webssh/host
Se non lo si è già fatto, per connettersi è necessario eseguire l'autenticazione con la sottoscrizione di Azure. Al termine dell'autenticazione viene visualizzata una shell nel browser, in cui è possibile eseguire i comandi all'interno del contenitore.
Nota
Le eventuali modifiche apportate all'esterno della directory /home vengono archiviate nel contenitore stesso e non persistono oltre il riavvio dell'app.
Per aprire una sessione SSH remota dal computer locale, vedere Aprire una sessione SSH dalla shell remota.
robots933456 nei log
È possibile che nei log del contenitore venga visualizzato il messaggio seguente:
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
È possibile ignorare tale errore. /robots933456.txt è un percorso URL fittizio usato dal servizio app per verificare se il contenitore è in grado di gestire le richieste. Una risposta 404 indica semplicemente che il percorso non esiste, ma consente al servizio app di capire che il contenitore è integro e pronto per rispondere alle richieste.
Passaggi successivi
In alternativa, vedere altre risorse:
Informazioni di riferimento sulle variabili di ambiente e sulle impostazioni dell'app