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 il servizio app Azure. Se l'app ASP.NET Core viene eseguita in un contenitore Windows o Linux personalizzato, vedere Configurare un contenitore personalizzato per app Azure Servizio.
ASP.NET le app core devono essere distribuite in app Azure Servizio 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 di codice e quindi compila i file binari.
Questa guida fornisce concetti chiave e istruzioni per gli sviluppatori ASP.NET Core. Se non si è mai usato app Azure Service, seguire prima l'esercitazione ASP.NET Core e ASP.NET Core con database SQL.
Visualizzare le versioni di runtime di .NET Core supportate
In servizio app, tutte le versioni di .NET Core supportate sono già installate nelle istanze di Windows. Per visualizzare il runtime di .NET Core e le versioni dell'SDK disponibili, passare a https://<app-name>.scm.azurewebsites.net/DebugConsole ed eseguire il comando seguente nella console basata su browser:
dotnet --info
Mostrare la versione di .NET Core
Per visualizzare la versione corrente di .NET Core, eseguire il comando seguente in 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 in 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 in Cloud Shell per impostare la versione di .NET Core su 8.0:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
Personalizzare l'automazione della compilazione
Nota
La compilazione di app .NET 9 (STS) con Windows servizio app con MSBuild o SCM_DO_BUILD non è ancora supportata. Il supporto per questi scenari di compilazione sarà successivo alla data di disponibilità generale iniziale e entro il 4 dicembre 2024. Le distribuzioni compilate all'esterno di servizio app tramite Visual Studio, Visual Studio Code, GitHub Actions e Azure DevOps sono completamente supportate.
Se si distribuisce l'app usando pacchetti GIT, oppure ZIP con l'automazione della compilazione abilitata, l'automazione della compilazione del servizio app esegue 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 i comandi di precompilazione, 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 oryx.
Per altre informazioni su come servizio app viene eseguita e compilata ASP.NET app 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 modello di inserimento delle dipendenze 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 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 nell'ambiente di produzione con le 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
Prendere in considerazione opzioni di connettività più sicure che non richiedono affatto segreti di connessione. Per altre informazioni, vedere Proteggere la connettività ai servizi e ai database di Azure dal servizio app Azure.
Nota
Si noti che i dati di configurazione gerarchici in appsettings.json sono accessibili usando il __ delimitatore (doppio carattere di sottolineatura) standard in Linux per .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 in 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 sono accessibili usando il : delimitatore standard per .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 in 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 esegue la distribuzione nel motore di distribuzione servizio app, ad esempio con Git o con distribuzione ZIP con automazione della compilazione abilitata, il motore di distribuzione servizio app seleziona il primo sito Web o il progetto di applicazione Web trovato come app servizio app. È possibile specificare quale servizio app di progetto usare specificando l'impostazione dell'appPROJECT. 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 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 relativi a ASP.NET Core nel servizio app Azure e IIS
Pagina Get detailed exceptions (Ottieni eccezioni dettagliate)
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 sostituita da un HTTP 500 generico o Si è verificato un errore durante l'elaborazione della richiesta. Per visualizzare la pagina dettagliata delle eccezioni in 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 si verifica nei servizi di bilanciamento del carico di rete, pertanto 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 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 un altro 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.
Riscrivere o reindirizzare l'URL
Per riscrivere o reindirizzare l'URL, usare il middleware di riscrittura URL in ASP.NET Core.
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 "-" "-"
Questo messaggio può tranquillamente essere ignorato. /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 impostazioni dell'app