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

Notitie

Zie ASP.NET app voor .NET Framework in ASP.NET configureren voor Azure App Service

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

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

Ondersteunde .NET Core-runtimeversies tonen

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

dotnet --info

.NET Core-versie tonen

Als u de huidige versie van .NET Core wilt zien, moet u de volgende opdracht uitvoeren in Cloud Shell:

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

Als u alle ondersteunde .NET Core-versies wilt zien, moet u de volgende opdracht uitvoeren in Cloud Shell:

az webapp list-runtimes --linux | grep DOTNETCORE

.NET Core-versie instellen

Stel het doel-framework in het projectbestand in voor uw ASP.NET Core project. Zie Select the .NET Core version to use in .NET Core documentation (De .NET Core-versie selecteren die moet worden gebruikt in de .NET Core-documentatie) voor meer informatie.

Voer de volgende opdracht uit in Cloud Shell .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 behulp van Git of zip-pakketten met ingeschakeldebuildautomatisering, moet App Service stappen voor het bouwen van automatisering in de volgende volgorde 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 dotnet publish uit om een binair bestand voor productie te bouwen.
  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 aanvullende omgevingsvariabelen om bouwautomatisering aan te passen.

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

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 een app-instelling met dezelfde naam configureert in App Service en in appsettings.jsop, heeft de waarde App Service bijvoorbeeld voorrang op de waarde appsettings.jswaarde. Met de lokaleappsettings.js op kunt u lokaal fouten opsporen in de app, 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

Houd er rekening mee dat de hiërarchische configuratiegegevens inappsettings.jsworden gebruikt met behulp van het scheidingsteken dat standaard is : voor .NET Core. Als u een specifieke hiërarchische configuratie-instelling in App Service, stelt u de naam van de app-instelling in met dezelfde scheidingstekennotatie 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 meerdere projecten bevat, omvat Visual Studio publicatieproces al het project dat u wilt implementeren. Wanneer u implementeert in de App Service-implementatie-engine, zoals met Git, of met ZIP-implementatie met buildautomatisering ingeschakeld,kiest de App Service-implementatie-engine de eerste website of webtoepassing Project die 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 het volgende 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>();
        });

Vervolgens kunt u 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 Troubleshoot ASP.NET Core on Azure App Service and IIS (Problemen met ASP.NET Core en IIS oplossen) voor meer ASP.NET Core het oplossen van problemen met apps in App Service

Pagina Met gedetailleerde uitzonderingen

Wanneer uw ASP.NET Core-app een uitzondering genereert in het Visual Studio-foutopsporingsproces, geeft de browser een gedetailleerde uitzonderingspagina weer, maar in App Service wordt die pagina vervangen door een algemene HTTP 500-fout of een fout opgetreden tijdens het verwerken van uw aanvraag. . Als u de gedetailleerde uitzonderingspagina wilt weergeven in App Service, voegt u de app-instelling toe aan uw app door de volgende opdracht uit te voeren ASPNETCORE_ENVIRONMENT 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 TLS/SSL-beëindiging vindt plaats bij de load balancers van het netwerk, zodat alle HTTPS-aanvragen uw app bereiken als niet-versleutelde HTTP-aanvragen. Als uw app-logica moet weten of de aanvragen van gebruikers al dan niet zijn versleuteld, configureert u de Middleware voor doorgestuurde headers in Startup.cs:

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

Door alle drie de elementen samen te voegen, ziet uw code eruit zoals 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 Configureer ASP.NET Core te werken 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

U kunt ook aanvullende resources bekijken:

Naslag voor omgevingsvariabelen en app-instellingen