Konfigurera en ASP.NET Core app för Azure App Service

Anteckning

ASP.NET i .NET Framework finns i Konfigurera en ASP.NET app för Azure App Service. Om din ASP.NET Core app körs i en anpassad Windows- eller Linux-container kan du läsa Konfigurera en anpassad container för Azure App Service.

ASP.NET Core appar måste distribueras till Azure App Service som kompilerade binärfiler. Visual Studio-publiceringsverktyget skapar lösningen och distribuerar sedan de kompilerade binärfilerna direkt, medan den App Service distributionsmotorn distribuerar kodlagringsplatsen först och sedan kompilerar binärfilerna.

Den här guiden innehåller viktiga begrepp och instruktioner för ASP.NET Core utvecklare. Om du aldrig har använt Azure App Service följer du ASP.NET Core snabbstart och ASP.NET Core med SQL Database självstudiekurs först.

Visa .NET Core-körningsversioner som stöds

I App Service har Windows-instanserna redan alla .NET Core-versioner som stöds installerade. Om du vill visa de .NET Core-körnings- och SDK-versioner som är tillgängliga för dig går du till https://<app-name>.scm.azurewebsites.net/DebugConsole och kör följande kommando i den webbläsarbaserade konsolen:

dotnet --info

Visa .NET Core-version

Om du vill visa den aktuella .NET Core-versionen kör du följande kommando i Cloud Shell:

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

Om du vill visa alla .NET Core-versioner som stöds kör du följande kommando i Cloud Shell:

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

Ange .NET Core-version

Ange målramverket i projektfilen för ditt ASP.NET Core projekt. Mer information finns i Välj den .NET Core-version som ska användas i .NET Core-dokumentationen.

Kör följande kommando i Cloud Shell för att ange .NET Core-versionen till 3.1:

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

Anpassa versionsautomatisering

Om du distribuerar din app med Git eller zip-paket med versionsautomatisering aktiverat stegar App Service skapa automatisering genom följande sekvens:

  1. Kör anpassat skript om det anges av PRE_BUILD_SCRIPT_PATH.
  2. Kör dotnet restore för att återställa NuGet-beroenden.
  3. Kör dotnet publish för att skapa en binär fil för produktion.
  4. Kör anpassat skript om det anges av POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND och POST_BUILD_COMMAND är miljövariabler som är tomma som standard. Om du vill köra förhandsversionskommandon definierar du PRE_BUILD_COMMAND. Om du vill köra kommandon efter kompilering definierar du POST_BUILD_COMMAND.

I följande exempel anges de två variablerna till en serie kommandon, avgränsade med kommatecken.

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"

Andra miljövariabler för att anpassa versionsautomatisering finns i Oryx-konfiguration.

Mer information om hur App Service kör och skapar ASP.NET Core appar i Linux finns i Oryx-dokumentationen: Hur .NET Core-appar identifieras och skapas.

Få åtkomst till miljövariabler

I App Service kan du ange appinställningar utanför din appkod. Sedan kan du komma åt dem i vilken klass som helst med hjälp av standardmönstret för ASP.NET Core beroendeinmatning:

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

Om du konfigurerar en appinställning med samma namn i App Service och i appsettings.json, till exempel, har App Service-värdet företräde framför värdet appsettings.json. Med värdet local appsettings.json kan du felsöka appen lokalt, men med det App Service värdet kan du köra appen i produktion med produktionsinställningar. Anslutningssträngar fungerar på samma sätt. På så sätt kan du hålla dina programhemligheter utanför kodlagringsplatsen och komma åt lämpliga värden utan att ändra koden.

Anteckning

Observera att hierarkiska konfigurationsdata i appsettings.json används med den __ (dubbla understreck) avgränsare som är standard i Linux till .NET Core. Om du vill åsidosätta en specifik hierarkisk konfigurationsinställning i App Service anger du appinställningens namn med samma avgränsade format i nyckeln. du kan köra följande exempel i Cloud Shell:

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

Anteckning

Observera att hierarkiska konfigurationsdata i appsettings.json används med den : avgränsare som är standard för .NET Core. Om du vill åsidosätta en specifik hierarkisk konfigurationsinställning i App Service anger du appinställningens namn med samma avgränsade format i nyckeln. du kan köra följande exempel i Cloud Shell:

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

Distribuera lösningar för flera projekt

När en Visual Studio-lösning innehåller flera projekt inkluderar Visual Studio-publiceringsprocessen redan att välja det projekt som ska distribueras. När du distribuerar till App Service distributionsmotorn, till exempel med Git eller med ZIP-distribution med versionsautomatisering aktiverad, väljer App Service distributionsmotorn den första webbplatsen eller webbprogramprojektet som hittas som App Service app. Du kan ange vilket projekt App Service ska använda genom att ange appinställningenPROJECT. Kör till exempel följande kommando i Cloud Shell:

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

Få åtkomst till diagnostikloggar

ASP.NET Core tillhandahåller en inbyggd loggningsprovider för App Service. I Program.cs för projektet lägger du till providern i ditt program via ConfigureLogging tilläggsmetoden, som du ser i följande exempel:

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

Du kan sedan konfigurera och generera loggar med standardmönstret .NET Core.

Om du vill komma åt konsolloggarna som genereras i din programkod i App Service aktiverar du diagnostisk loggning genom att köra följande kommando i Cloud Shell:

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

Möjliga värden för --level är: Error, Warning, Info och Verbose. Varje efterföljande nivå omfattar den föregående nivån. Exempel: Error omfattar endast felmeddelanden och Verbose omfattar alla meddelanden.

När diagnostisk loggning har aktiverats kör du följande kommando för att visa loggströmmen:

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

Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.

Anteckning

Du kan även granska loggfilerna från din webbläsare via https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Skriv Ctrl+C när som helst för att stoppa loggströmningen.

Mer information om hur du felsöker ASP.NET Core appar i App Service finns i Felsöka ASP.NET Core på Azure App Service och IIS

Sidan Hämta detaljerade undantag

När din ASP.NET Core app genererar ett undantag i Visual Studio-felsökningsprogrammet visar webbläsaren en detaljerad undantagssida, men i App Service ersätts den sidan av ett allmänt HTTP 500-fel eller Ett fel uppstod när begäran bearbetades. Om du vill visa den detaljerade undantagssidan i App Service lägger du till appinställningen ASPNETCORE_ENVIRONMENT i appen genom att köra följande kommando i Cloud Shell.

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

Identifiera HTTPS-sessionen

I App Service sker TLS/SSL-avslutning hos nätverkslastbalanserarna, så alla HTTPS-begäranden når din app som okrypterade HTTP-begäranden. Om din applogik behöver veta om användarbegäranden är krypterade eller inte konfigurerar du mellanprogrammet Vidarebefordrade rubriker i Startup.cs:

  • Konfigurera mellanprogrammet med ForwardedHeadersOptions för att vidarebefordra rubrikerna X-Forwarded-For och X-Forwarded-Proto i Startup.ConfigureServices.
  • Lägg till privata IP-adressintervall i de kända nätverken så att mellanprogrammet kan lita på App Service lastbalanserare.
  • Anropa metoden UseForwardedHeaders i Startup.Configure innan du anropar andra mellanprogram.

Om du sätter ihop alla tre elementen ser koden ut som i följande exempel:

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

Mer information finns i Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare.

Öppna en SSH-session i webbläsaren

Om du ska öppna en SSH-direktsession med din container måste appen vara igång.

Klistra in följande URL i webbläsaren och ersätt <app-name> med namnet på appen:

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

Om du inte redan har autentiserats måste du autentisera dig med din Azure-prenumeration för att kunna ansluta. När autentiseringen är klar visas ett gränssnitt i webbläsaren där du kan köra kommandon i containern.

SSH-anslutning

Anteckning

Eventuella ändringar som du gör utanför katalogen /start lagras i själva containern och finns inte kvar om appen startas om.

Om du vill öppna en SSH-fjärrsession från den lokala datorn, kan du läsa mer i Öppna SSH-session från fjärrgränssnitt.

robots933456 i loggar

Följande meddelande kan visas i containerloggarna:

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

Du kan ignorera det här meddelandet. /robots933456.txt är en dummysökväg för URL:en som App Service använder till att kontrollera om containern kan hantera begäranden. Ett 404-svar innebär helt enkelt att sökvägen inte finns, men det låter App Service veta att containern är felfri och redo att svara på begäranden.

Nästa steg

Eller se fler resurser:

Referens för miljövariabler och appinställningar