Een ASP.NET Core-app configureren voor Azure App Service

Notitie

Zie Een ASP.NET-app configureren voor Azure App Service voor ASP.NET in .NET Framework. Als uw ASP.NET Core-app wordt uitgevoerd in een aangepaste Windows- of Linux-container, raadpleegt u Een aangepaste container configureren voor Azure App Service.

ASP.NET Core-apps moeten worden geïmplementeerd in Azure App Service als gecompileerde binaire bestanden. Het visual Studio-publicatieprogramma bouwt de oplossing en implementeert vervolgens de gecompileerde binaire bestanden rechtstreeks, terwijl de App Service-implementatie-engine eerst de codeopslagplaats implementeert en vervolgens de binaire bestanden compileert.

Deze handleiding bevat belangrijke concepten en instructies voor ASP.NET Core ontwikkelaars. Als u Azure App Service nog nooit hebt gebruikt, volgt u eerst de snelstartgids voor ASP.NET Core en ASP.NET Core met SQL Database zelfstudie.

Ondersteunde runtimeversies van .NET Core weergeven

In App Service zijn op de Windows-exemplaren al alle ondersteunde .NET Core-versies geïnstalleerd. Als u de .NET Core-runtime- en SDK-versies wilt weergeven die voor u beschikbaar zijn, gaat u naar https://<app-name>.scm.azurewebsites.net/DebugConsole en voert u de volgende opdracht uit in de browserconsole:

dotnet --info

.NET Core-versie weergeven

Als u de huidige .NET Core-versie wilt weergeven, voert u de volgende opdracht uit in de Cloud Shell:

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

Als u alle ondersteunde .NET Core-versies wilt weergeven, voert u de volgende opdracht uit in de Cloud Shell:

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

.NET Core-versie instellen

Stel het doelframework in het projectbestand in voor uw ASP.NET Core-project. Zie De .NET Core-versie selecteren die u wilt gebruiken in de .NET Core-documentatie voor meer informatie.

Voer de volgende opdracht uit in de Cloud Shell om de .NET Core-versie in te stellen op 3.1:

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

De automatisering van bouwbewerkingen aanpassen

Als u uw app implementeert met git of zip-pakketten waarvoor buildautomatisering is ingeschakeld, worden de App Service stappen voor het automatiseren van het bouwen door de volgende reeks te doorlopen:

  1. Voer aangepast script uit als dit is opgegeven door PRE_BUILD_SCRIPT_PATH.
  2. Voer uit dotnet restore om NuGet-afhankelijkheden te herstellen.
  3. Voer uit dotnet publish om een binair bestand te maken voor productie.
  4. Voer aangepast script uit als dit is opgegeven door POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND en POST_BUILD_COMMAND zijn omgevingsvariabelen die standaard leeg zijn. Als u vooraf gebouwde opdrachten wilt uitvoeren, definieert u PRE_BUILD_COMMAND. Als u achteraf gebouwde opdrachten wilt uitvoeren, definieert u POST_BUILD_COMMAND.

In het volgende voorbeeld worden de twee variabelen voor een reeks opdrachten opgegeven, gescheiden door komma's.

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"

Zie Oryx-configuratie voor andere omgevingsvariabelen voor het aanpassen van bouwautomatisering.

Zie Oryx-documentatie: Hoe .NET Core-apps worden gedetecteerd en gebouwd voor meer informatie over hoe App Service wordt uitgevoerd en ASP.NET Core apps in Linux bouwt.

Toegang tot omgevingsvariabelen

In App Service kunt u app-instellingen configureren buiten uw app-code. Vervolgens kunt u ze in elke klasse openen met behulp van het standaardpatroon ASP.NET Core afhankelijkheidsinjectie:

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

Als u bijvoorbeeld een app-instelling met dezelfde naam configureert in App Service en in appsettings.json, heeft de waarde App Service voorrang op de waarde appsettings.json. Met de lokale appettings.json-waarde kunt u lokaal fouten in de app opsporen, maar met de waarde App Service kunt u de app in productie uitvoeren met productie-instellingen. Verbindingsreeksen werken op dezelfde manier. Op deze manier kunt u uw toepassingsgeheimen buiten uw codeopslagplaats houden en toegang krijgen tot de juiste waarden zonder uw code te wijzigen.

Notitie

Let op: de hiërarchische configuratiegegevens in appsettings.json worden geopend met behulp van het __ scheidingsteken (dubbel onderstrepingsteken) dat standaard is op Linux naar .NET Core. Als u een specifieke hiërarchische configuratie-instelling in App Service wilt overschrijven, stelt u de naam van de app-instelling in met dezelfde indeling met scheidingstekens in de sleutel. u kunt het volgende voorbeeld uitvoeren in de Cloud Shell:

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

Notitie

Let op: de hiërarchische configuratiegegevens in appsettings.json worden geopend met behulp van het : scheidingsteken dat standaard is voor .NET Core. Als u een specifieke hiërarchische configuratie-instelling in App Service wilt overschrijven, stelt u de naam van de app-instelling in met dezelfde indeling met scheidingstekens in de sleutel. u kunt het volgende voorbeeld uitvoeren in de Cloud Shell:

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

Oplossingen voor meerdere projecten implementeren

Wanneer een Visual Studio-oplossing meerdere projecten bevat, omvat het publicatieproces van Visual Studio al het selecteren van het project dat u wilt implementeren. Wanneer u implementeert in de App Service-implementatie-engine, zoals met Git, of wanneer ZIP-implementatie is ingeschakeld met buildautomatisering, kiest de App Service-implementatie-engine de eerste website of het webtoepassingsproject dat wordt gevonden als de App Service-app. U kunt opgeven welk project App Service moet gebruiken door de PROJECT app-instelling op te geven. Voer bijvoorbeeld de volgende opdracht uit in de Cloud Shell:

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

Toegang tot diagnostische logboeken

ASP.NET Core biedt een ingebouwde provider voor logboekregistratie voor App Service. Voeg in Program.cs van uw project de provider toe aan uw toepassing via de ConfigureLogging extensiemethode, zoals wordt weergegeven in het volgende voorbeeld:

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

U kunt vervolgens logboeken configureren en genereren met het standaard .NET Core-patroon.

Als u toegang wilt tot de consolelogboeken die worden gegenereerd binnen uw toepassingscode in de App Service, schakelt u diagnostische logboekregistratie in door de volgende opdracht in de Cloud Shell uit te voeren:

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

Mogelijk waarden voor --level zijn: Error, Warning, Info en Verbose. Elk hoger niveau omvat het vorige niveau. Bijvoorbeeld: Error omvat alleen foutberichten en Verbose omvat alle berichten.

Nadat diagnostische logboekregistratie is ingeschakeld, voert u de volgende opdracht uit om de logboekstream te zien:

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

Als u de consolelogboeken niet meteen ziet, probeert u het opnieuw na 30 seconden.

Notitie

U kunt ook de logboekbestanden van de browser inspecteren op https://<app-name>.scm.azurewebsites.net/api/logs/docker.

U kunt op elk gewenst moment Ctrl+C typen om te stoppen met logboekstreaming.

Zie Problemen met ASP.NET Core in Azure App Service en IIS oplossen voor meer informatie over het oplossen van problemen met ASP.NET Core apps in App Service

Gedetailleerde uitzonderingenpagina ophalen

Wanneer uw ASP.NET Core-app een uitzondering genereert in het foutopsporingsprogramma van Visual Studio, wordt in de browser een gedetailleerde uitzonderingspagina weergegeven, maar in App Service wordt die pagina vervangen door een algemene HTTP 500-fout of een fout die is opgetreden tijdens het verwerken van uw aanvraag. bericht. Als u de gedetailleerde uitzonderingspagina in App Service wilt weergeven, voegt u de ASPNETCORE_ENVIRONMENT app-instelling toe aan uw app door de volgende opdracht uit te voeren in de Cloud Shell.

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

HTTPS-sessie detecteren

In App Service vindt TLS/SSL-beëindiging plaats bij de netwerktaakverdelers, zodat alle HTTPS-aanvragen uw app bereiken als niet-versleutelde HTTP-aanvragen. Als uw app-logica moet weten of de gebruikersaanvragen zijn versleuteld of niet, configureert u de middleware voor doorgestuurde headers in Startup.cs:

  • Configureer de middleware met ForwardedHeadersOptions om de X-Forwarded-For headers en X-Forwarded-Proto door te sturen in Startup.ConfigureServices.
  • Voeg privé-IP-adresbereiken toe aan de bekende netwerken, zodat de middleware de App Service load balancer kan vertrouwen.
  • Roep de methode UseForwardedHeaders aan in Startup.Configure voordat u andere middleware aanroept.

Als u alle drie de elementen samenbrengt, ziet uw code eruit als in het volgende voorbeeld:

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

Zie Configure ASP.NET Core to work with proxy servers and load balancers (ASP.NET Core configureren voor gebruik met proxyservers en load balancers) voor meer informatie.

SSH-sessie in de browser openen

Als u een directe SSH-sessie opent met uw container, moet uw app worden uitgevoerd.

Plak de volgende URL in uw browser en vervang <app-name> door de naam van uw app:

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

Als u nog niet bent geverifieerd moet u zich verifiëren met uw Azure-abonnement om verbinding te maken. Nadat u bent geverifieerd, ziet u een shell in de browser waarin u opdrachten binnen uw container kunt uitvoeren.

SSH-verbinding

Notitie

Wijzigingen die u buiten de map /home aanbrengt, worden in de container zelf opgeslagen en blijven niet behouden na het opnieuw opstarten van de app.

Als u een externe SSH-sessie wilt openen vanaf uw lokale machine, raadpleegt u SSH-sessie openen vanaf een externe shell.

robots933456 in logboeken

U ziet mogelijk het volgende bericht in de containerlogboeken:

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

U kunt dit bericht veilig negeren. /robots933456.txt is een dummy-URL-pad dat App Service gebruikt om te controleren of de container aanvragen kan verwerken. Een 404-antwoord geeft alleen aan dat het pad niet bestaat, maar laat App Service wel weten dat de container in orde is en klaar is om te reageren op aanvragen.

Volgende stappen

Of bekijk meer resources:

Naslaginformatie over omgevingsvariabelen en app-instellingen