Delen via

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. De Implementatie-engine van App Service implementeert eerst de codeopslagplaats en compileert vervolgens de binaire bestanden.

Deze handleiding bevat belangrijke concepten en instructies voor ASP.NET Core-ontwikkelaars. Als dit de eerste keer is dat u Azure App Service gebruikt, volgt u eerst de quickstart ASP.NET Core en ASP.NET Core met SQL Database.

Ondersteunde .NET Core-runtimeversies weergeven

In App Service hebben de Windows-exemplaren al alle ondersteunde .NET Core-versies geïnstalleerd. Als u de .NET Core-runtime- en SDK-versies wilt zien die voor u beschikbaar zijn, gaat u naar uw Kudu-site.

Ga naar uw app in de Azure-portal en selecteer vervolgens Ontwikkelhulpmiddelen>. Selecteer Go. Selecteer in Kudu debug-console voor CMD of PowerShell.

Voer de volgende opdracht uit in de browserconsole:

dotnet --info

Versie van .NET Core weergeven

Als u de huidige .NET Core-versie wilt weergeven, voert u de volgende opdracht uit in Azure 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 Cloud Shell:

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

Versie van .NET Core instellen

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

Als u de .NET Core-versie wilt instellen op 8.0, voert u de volgende opdracht uit in Cloud Shell:

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

Wat gebeurt er met verouderde runtimes in App Service?

Verouderde runtimes worden afgedaan door de organisatie die ze onderhoudt of blijken aanzienlijke beveiligingsproblemen te hebben. Dienovereenkomstig worden ze verwijderd uit het maken en configureren van pagina's in de portal. Wanneer een verouderde runtime is verborgen in de portal, blijft elke app die die runtime gebruikt, nog steeds actief.

Als u een app wilt maken met een verouderde runtimeversie die niet meer wordt weergegeven in de portal, gebruikt u de Azure CLI, ARM-sjabloon of Bicep. Met deze implementatiealternatieven kunt u afgeschafte runtimes maken die zijn verwijderd in de portal, maar die nog steeds worden ondersteund.

Als een runtime volledig is verwijderd uit het App Service-platform, ontvangt de eigenaar van uw Azure-abonnement een e-mailmelding voordat deze wordt verwijderd.

De automatisering van bouwbewerkingen aanpassen

Als u uw app implementeert met behulp van Git- of ZIP-pakketten waarvoor buildautomatisering is ingeschakeld, volgt de buildautomatisering van App Service deze reeks:

  1. Voer aangepast script uit als dit is opgegeven door PRE_BUILD_SCRIPT_PATH.
  2. Als u NuGet-afhankelijkheden wilt herstellen, voert u uit dotnet restore.
  3. Als u een binair bestand wilt bouwen voor productie, voert u de opdracht uit dotnet publish.
  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 prebuild-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 De Oryx-configuratie voor andere omgevingsvariabelen die u kunt gebruiken om buildautomatisering aan te passen.

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

Toegang tot omgevingsvariabelen

In App Service kunt u app-instellingen instellen buiten uw app-code. U kunt deze vervolgens 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 een app-instelling met dezelfde naam in App Service configureert en in appsettings.jsonbijvoorbeeld de App Service-waarde voorrang heeft op de appsettings.json waarde. Met behulp van de lokale appsettings.json waarde kunt u lokaal fouten opsporen in de app, maar met behulp van de App Service-waarde kunt u de app uitvoeren in productie met productie-instellingen. Connection strings werken op de dezelfde manier. Met deze methode kunt u uw toepassingsgeheimen buiten uw codeopslagplaats bewaren en de juiste waarden openen zonder uw code te wijzigen.

Notitie

U kunt ook veiligere connectiviteitsopties overwegen waarvoor geen verbindingsgeheimen zijn vereist. Zie Beveiligde connectiviteit met Azure-services en -databases vanuit Azure App Service voor meer informatie.

De hiërarchische configuratiegegevens in appsettings.json worden geopend met behulp van het __ (dubbele onderstrepingsteken) scheidingsteken dat standaard is op Linux naar .NET Core. Om een specifieke hiërarchische configuratie-instelling in App Service te overschrijven, stelt u de app-instellingsnaam in met hetzelfde begrensde formaat in de sleutel. U kunt het volgende voorbeeld uitvoeren in Cloud Shell:

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

De hiërarchische configuratiegegevens in appsettings.json worden geopend met behulp van het : scheidingsteken dat standaard is voor .NET Core. Om een specifieke hiërarchische configuratie-instelling in App Service te overschrijven, stelt u de app-instellingsnaam in met hetzelfde begrensde formaat in de sleutel. U kunt het volgende voorbeeld uitvoeren in Azure 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, selecteert het publicatieproces van Visual Studio automatisch het te implementeren project. Wanneer u implementeert in de App Service-implementatie-engine, zoals met Git of met ZIP-implementatie waarvoor buildautomatisering is ingeschakeld, kiest de App Service-implementatie-engine het eerste website- of 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 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 het bestand van program.cs 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>();
        });

Vervolgens kunt u logboeken configureren en genereren met het standaard .NET Core-patroon.

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

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

Mogelijke waarden voor --level zijn Error, Warning, Info en Verbose. Elk hoger niveau omvat het vorige niveau. Error bevat bijvoorbeeld alleen foutberichten. Verbose bevat alle berichten.

Nadat u diagnostische logboekregistratie hebt 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 consolelogboeken niet onmiddellijk worden weergegeven, controleert u het na 30 seconden opnieuw.

Als u wilt stoppen met logboekstreaming, selecteert u Ctrl+C.

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

Toegang tot een gedetailleerde pagina met uitzonderingen

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 of 'Er is een fout opgetreden tijdens het verwerken van uw aanvraag'. Als u de gedetailleerde uitzonderingspagina in App Service wilt weergeven, voegt u de app-instelling ASPNETCORE_ENVIRONMENT toe aan uw app door de volgende opdracht uit te voeren in 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 gebruikersaanvragen zijn versleuteld, configureer dan de Forwarded Headers-middleware in Startup.cs:

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

Wanneer u de drie elementen samenstelt, 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 ASP.NET Core configureren voor gebruik met proxyservers en load balancers voor meer informatie.

URL herschrijven of omleiden

Als u een URL wilt herschrijven of omleiden, gebruikt u de middleware voor het herschrijven van url's in ASP.NET Core.

SSH-sessie in de browser openen

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

Gebruik de opdracht az webapp ssh .

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 /home map aanbrengt, worden opgeslagen in de container zelf en blijven niet behouden na het opnieuw opstarten van de app.

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

Het robots933456-bericht negeren in logboeken

Mogelijk ziet u 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 aan dat het pad niet bestaat en geeft aan App Service aan dat de container in orde is en klaar is om te reageren op aanvragen.

Verwante inhoud