Konfigurace aplikace ASP.NET Core pro Azure App Service

Poznámka

ASP.NET v rozhraní .NET Framework najdete v tématu Konfigurace aplikace ASP.NET pro Azure App Service. Pokud vaše ASP.NET Core aplikace běží ve vlastním kontejneru Windows nebo Linuxu, přečtěte si téma Konfigurace vlastního kontejneru pro Azure App Service.

ASP.NET Core aplikace musí být nasazeny do Azure App Service jako kompilované binární soubory. Nástroj pro publikování sady Visual Studio sestaví řešení a pak přímo nasadí zkompilované binární soubory, zatímco modul pro nasazení App Service nejprve nasadí úložiště kódu a pak zkompiluje binární soubory.

Tato příručka obsahuje klíčové koncepty a pokyny pro vývojáře ASP.NET Core. Pokud jste Azure App Service nikdy nepoužívali, nejprve si projděte rychlý start k ASP.NET Core a ASP.NET Core s SQL Database kurzem.

Zobrazení podporovaných verzí modulu runtime .NET Core

V App Service už mají instance Windows nainstalované všechny podporované verze .NET Core. Pokud chcete zobrazit modul runtime .NET Core a verze sady SDK, které máte k dispozici, přejděte v konzole založené na prohlížeči na https://<app-name>.scm.azurewebsites.net/DebugConsole následující příkaz a spusťte ho:

dotnet --info

Zobrazení verze .NET Core

Pokud chcete zobrazit aktuální verzi .NET Core, spusťte v Cloud Shell následující příkaz:

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

Pokud chcete zobrazit všechny podporované verze .NET Core, spusťte v Cloud Shell následující příkaz:

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

Nastavení verze .NET Core

Nastavte cílovou architekturu v souboru projektu pro váš projekt ASP.NET Core. Další informace najdete v dokumentaci k výběru verze .NET Core, která se má použít v .NET Core.

Spuštěním následujícího příkazu v Cloud Shell nastavte verzi .NET Core na 3.1:

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

Přizpůsobení automatizace sestavení

Pokud nasadíte aplikaci pomocí Gitu nebo balíčků ZIP s povolenou automatizací sestavení, App Service automatizace sestavení provede následující postup:

  1. Pokud je zadaný parametrem PRE_BUILD_SCRIPT_PATH, spusťte vlastní skript.
  2. Spuštěním příkazu dotnet restore obnovte závislosti NuGet.
  3. Spuštěním příkazu dotnet publish sestavte binární soubor pro produkční prostředí.
  4. Pokud je zadaný parametrem POST_BUILD_SCRIPT_PATH, spusťte vlastní skript.

PRE_BUILD_COMMAND a POST_BUILD_COMMAND jsou proměnné prostředí, které jsou ve výchozím nastavení prázdné. Pokud chcete spouštět příkazy před sestavením, definujte PRE_BUILD_COMMAND. Pokud chcete spouštět příkazy po sestavení, definujte POST_BUILD_COMMAND.

Následující příklad určuje dvě proměnné pro řadu příkazů oddělených čárkami.

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"

Další proměnné prostředí pro přizpůsobení automatizace sestavení najdete v tématu Konfigurace Oryxu.

Další informace o tom, jak App Service spouštět a sestavovat ASP.NET Core aplikace v Linuxu, najdete v dokumentaci k nástroji Oryx: Jak se detekují a sestavují aplikace .NET Core.

Přístup k proměnným prostředí

V App Service můžete nastavit nastavení aplikace mimo kód vaší aplikace. Pak k nim můžete přistupovat v libovolné třídě pomocí standardního vzoru injektáže závislostí 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");
        }
    }
}

Pokud například v souboru App Service a v souboru appsettings.json nakonfigurujete nastavení aplikace se stejným názvem, bude mít hodnota App Service přednost před hodnotou appsettings.json. Místní hodnota appsettings.json umožňuje ladit aplikaci místně, ale hodnota App Service umožňuje spustit aplikaci v produkčním prostředí s produkčním nastavením. Připojovací řetězce fungují stejným způsobem. Tímto způsobem můžete uchovávat tajné kódy aplikace mimo úložiště kódu a přistupovat k příslušným hodnotám beze změny kódu.

Poznámka

Všimněte si, že k hierarchickým konfiguračním datům v souboru appsettings.json se přistupuje pomocí __ oddělovače (dvojité podtržítko), který je v Linuxu standardní pro .NET Core. Pokud chcete přepsat konkrétní nastavení konfigurace hierarchie v App Service, nastavte název nastavení aplikace ve stejném formátu s oddělovači v klíči. V Cloud Shell můžete spustit následující příklad:

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

Poznámka

Všimněte si, že k hierarchickým konfiguračním datům v souboru appsettings.json se přistupuje pomocí : oddělovače, který je standardní pro .NET Core. Pokud chcete přepsat konkrétní nastavení konfigurace hierarchie v App Service, nastavte název nastavení aplikace ve stejném formátu s oddělovači v klíči. V Cloud Shell můžete spustit následující příklad:

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

Nasazení víceprojektových řešení

Pokud řešení sady Visual Studio zahrnuje více projektů, proces publikování sady Visual Studio již zahrnuje výběr projektu k nasazení. Když nasadíte do modulu nasazení App Service, například pomocí Gitu, nebo s nasazením ZIP s povolenou automatizací sestavení, modul nasazení App Service vybere první web nebo projekt webové aplikace, který najde jako App Service aplikaci. Zadáním nastavení aplikace můžete určit, který projekt App Service používatPROJECT. Například spusťte následující příkaz v Cloud Shell:

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

Přístup k diagnostickým protokolům

ASP.NET Core poskytuje integrovaného zprostředkovatele protokolování pro App Service. V souboru Program.cs vašeho projektu přidejte zprostředkovatele do aplikace pomocí ConfigureLogging rozšiřující metody, jak je znázorněno v následujícím příkladu:

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

Pak můžete nakonfigurovat a generovat protokoly se standardním vzorem .NET Core.

Pokud chcete získat přístup k protokolům konzoly vygenerovaným v rámci kódu aplikace ve službě App Service, zapněte protokolování diagnostiky spuštěním následujícího příkazu v Cloud Shellu:

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

Možné hodnoty pro --level jsou: Error, Warning, Info a Verbose. Každá další úroveň zahrnuje předchozí úroveň. Například Error zahrnuje jenom chybové zprávy a Verbose zahrnuje všechny zprávy.

Jakmile je aktivované protokolování diagnostiky, spusťte následující příkaz pro zobrazení streamu protokolů:

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

Pokud nevidíte protokoly konzoly okamžitě, podívejte se znovu za 30 sekund.

Poznámka

Soubory protokolu můžete také zkontrolovat v prohlížeči na https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Streamování protokolů můžete kdykoli zastavit zadáním Ctrl+C.

Další informace o řešení potíží s ASP.NET Core aplikacemi v App Service najdete v tématu Řešení potíží s ASP.NET Core ve službě Azure App Service a iis.

Stránka s podrobnými informacemi o výjimkách

Když aplikace ASP.NET Core vygeneruje výjimku v ladicím programu sady Visual Studio, prohlížeč zobrazí stránku s podrobnostmi o výjimce, ale v App Service je tato stránka nahrazena obecnou chybou HTTP 500 nebo zprávou Došlo k chybě při zpracování požadavku. Pokud chcete zobrazit stránku s podrobnostmi o výjimce v App Service, přidejte ASPNETCORE_ENVIRONMENT do aplikace nastavení aplikace spuštěním následujícího příkazu v Cloud Shell.

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

Detekce relace HTTPS

V App Service dochází k ukončení protokolu TLS/SSL u nástrojů pro vyrovnávání zatížení sítě, takže všechny požadavky HTTPS dorazí do vaší aplikace jako nešifrované požadavky HTTP. Pokud logika aplikace potřebuje vědět, jestli jsou požadavky uživatelů šifrované nebo ne, nakonfigurujte middleware Forwarded Headers v souboru Startup.cs:

  • Nakonfigurujte middleware pomocí možnosti ForwardedHeadersOptions pro předávání X-Forwarded-For hlaviček a X-Forwarded-Proto v Startup.ConfigureServicesnástroji .
  • Přidejte do známých sítí rozsahy privátních IP adres, aby middleware mohl App Service nástroji pro vyrovnávání zatížení důvěřovat.
  • Před voláním jiného middlewaru vyvolejte metodu UseForwardedHeaders v Startup.Configure .

Když spojíte všechny tři prvky dohromady, váš kód bude vypadat jako v následujícím příkladu:

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

Další informace najdete v tématu Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení.

Otevření relace SSH v prohlížeči

Pokud chcete otevřít přímou relaci SSH s kontejnerem, vaše aplikace by měla být spuštěná.

Vložte následující adresu URL do vašeho prohlížeče a <app-name> nahraďte názvem vaší aplikace:

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

Pokud ještě nejste ověření, budete se muset ověřit s vaším předplatným Azure, abyste se mohli připojit. Po ověření se vám zobrazí prostředí prohlížeče, ve kterém můžete spouště příkazy uvnitř vašeho kontejneru.

Připojení SSH

Poznámka

Všechny změny provedené mimo adresář /home se uloží ve vlastním kontejneru a po restartování aplikace se neuchovají.

Pokud chcete otevřít vzdálenou relaci SSH z místního počítače, projděte si téma věnované otevření relace SSH ze vzdáleného prostředí.

robots933456 v protokolech

V protokolech kontejneru se může zobrazit následující zpráva:

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

Tuto zprávu klidně ignorujte. /robots933456.txt je fiktivní cesta URL, kterou App Service používá ke kontrole, jestli kontejner dokáže obsloužit požadavky. Odpověď 404 jednoduše indikuje, že příslušná cesta neexistuje, ale dá službě App Service vědět, že kontejner je v pořádku a je připravený reagovat na požadavky.

Další kroky

Nebo si projděte další zdroje informací:

Referenční informace k proměnným prostředí a nastavením aplikací