Freigeben über

Konfigurieren einer ASP.NET Core-App für Azure App Service

Hinweis

Informationen zu ASP.NET in .NET Framework finden Sie unter Konfigurieren einer ASP.NET-App für Azure App Service. Wenn Ihre ASP.NET Core-App in einem benutzerdefinierten Windows- oder Linux-Container ausgeführt wird, finden Sie weitere Informationen unter Konfigurieren eines benutzerdefinierten Containers für Azure App Service.

ASP.NET Core-Apps müssen in Azure App Service als kompilierte Binärdateien bereitgestellt werden. Das Visual Studio-Veröffentlichungstool erstellt die Projektmappe und stellt dann die kompilierten Binärdateien direkt bereit. Das App Service-Bereitstellungsmodul stellt zuerst das Code-Repository bereit und kompiliert dann die Binärdateien.

Dieser Leitfaden enthält wichtige Konzepte und Anweisungen für ASP.NET Core-Entwickler. Wenn Sie Azure App Service zum ersten Mal verwenden, folgen Sie zuerst der Schnellstartanleitung ASP.NET Core und ASP.NET Core mit SQL-Datenbanklernprogramm.

Anzeigen unterstützter .NET Core-Runtimeversionen

In App Service sind auf den Windows-Instanzen bereits alle unterstützten .NET Core-Versionen installiert. Um die .NET Core-Runtime- und SDK-Versionen anzuzeigen, die Ihnen zur Verfügung stehen, wechseln Sie zu Ihrer Kudu-Website.

Wechseln Sie im Azure-Portal zu Ihrer App, und wählen Sie dann Entwicklungstools>, Erweiterte Tools aus. Klicken Sie auf Starten. Wählen Sie in Kudu die Debugkonsole für CMD oder PowerShell aus.

Führen Sie den folgenden Befehl in der browserbasierten Konsole aus:

dotnet --info

Anzeigen der .NET Core-Version

Führen Sie zum Anzeigen der aktuellen .NET Core-Version den folgenden Befehl in Azure Cloud Shell aus:

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

Um alle unterstützten .NET Core-Versionen anzuzeigen, führen Sie den folgenden Befehl in Cloud Shell aus:

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

Festlegen der .NET Core-Version

Legen Sie das Zielframework in der Projektdatei für das ASP.NET Core-Projekt fest. Weitere Informationen finden Sie unter Auswählen der zu verwendenden .NET Core-Version.

Um die .NET Core-Version auf 8.0 festzulegen, führen Sie den folgenden Befehl in Cloud Shell aus:

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

Was geschieht mit veralteten Laufzeiten in App Service?

Veraltete Runtimes werden von der verwaltenden Organisation nicht mehr unterstützt oder weisen erhebliche Schwachstellen auf. Dementsprechend werden sie aus dem Erstellen und Konfigurieren von Seiten im Portal entfernt. Wenn eine veraltete Laufzeit im Portal ausgeblendet ist, wird jede App, die diese Laufzeit verwendet, weiterhin ausgeführt.

Wenn Sie eine App mit einer veralteten Laufzeitversion erstellen möchten, die nicht mehr im Portal angezeigt wird, verwenden Sie die Azure CLI-, ARM-Vorlage oder Bicep. Mit diesen Bereitstellungsalternativen können Sie veraltete Laufzeiten erstellen, die im Portal entfernt wurden, aber weiterhin unterstützt werden.

Wenn eine Laufzeit vollständig von der App Service-Plattform entfernt wird, erhält Ihr Azure-Abonnementbesitzer vor dem Entfernen eine E-Mail-Benachrichtigung.

Anpassen der Buildautomatisierung

Wenn Sie Ihre App mithilfe von Git- oder ZIP-Paketen mit aktivierter Buildautomatisierung bereitstellen, folgt die App Service-Buildautomatisierung dieser Sequenz:

  1. Ausführen eines benutzerdefinierten Skripts, falls durch PRE_BUILD_SCRIPT_PATH angegeben
  2. Führen Sie dotnet restore aus, um NuGet-Abhängigkeiten wiederherzustellen.
  3. Führen Sie dotnet publish aus, um eine Binärdatei für die Produktion zu erstellen.
  4. Ausführen eines benutzerdefinierten Skripts, falls durch POST_BUILD_SCRIPT_PATH angegeben

PRE_BUILD_COMMAND und POST_BUILD_COMMAND sind Umgebungsvariablen, die standardmäßig leer sind. Um vordefinierte Befehle auszuführen, definieren Sie PRE_BUILD_COMMAND. Um Postbuildbefehle auszuführen, definieren Sie POST_BUILD_COMMAND.

Im folgenden Beispiel werden die beiden Variablen für eine Reihe von Befehlen angegeben, die durch Kommas getrennt sind.

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"

Weitere Umgebungsvariablen, die Sie zum Anpassen der Buildautomatisierung verwenden können, finden Sie unter Oryx-Konfiguration.

Weitere Informationen, wie App Service ASP.NET Core-Apps in Linux ausführt und erstellt, finden Sie unter Oryx-Dokumentation: Erkennen und Erstellen von .NET Core-Apps.

Zugreifen auf Umgebungsvariablen

In App Service können Sie App-Einstellungen außerhalb Ihres App-Codes festlegen. Anschließend können Sie in jeder Klasse mithilfe des standardmäßigen ASP.NET Core-Abhängigkeitsinjektionsmusters auf sie zugreifen:

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

Wenn Sie eine App-Einstellung mit demselben Namen in App Service und in appsettings.jsonkonfigurieren, hat beispielsweise der App Service-Wert Vorrang vor dem appsettings.json Wert. Mithilfe des lokalen appsettings.json Werts können Sie die App lokal debuggen, aber mithilfe des App Service-Werts können Sie die App in der Produktion mit Produktionseinstellungen ausführen. Verbindungszeichenfolgen funktionieren auf die gleiche Weise. Mithilfe dieser Methode können Sie ihre Anwendungsgeheimnisse außerhalb Ihres Code-Repositorys beibehalten und auf die entsprechenden Werte zugreifen, ohne den Code zu ändern.

Hinweis

Sie können auch sicherere Konnektivitätsoptionen berücksichtigen, die keine Verbindungsschlüssel erfordern. Weitere Informationen finden Sie unter Sichere Konnektivität mit Azure-Diensten und -Datenbanken aus Azure App Service.

Es wird auf die hierarchischen Konfigurationsdaten in der Datei appsettings.json mit dem __-Trennzeichen (doppelter Unterstrich) zugegriffen, das standardmäßig auf Linux in .NET Core Verwendung findet. Wenn Sie eine bestimmte hierarchische Konfigurationseinstellung in App Service außer Kraft setzen möchten, legen Sie den Namen der App-Einstellung mit dem gleichen Trennzeichenformat im Schlüssel fest. Sie können das folgende Beispiel in Cloud Shell ausführen:

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

Es wird auf die hierarchischen Konfigurationsdaten in der Datei appsettings.json mit dem :-Trennzeichen zugegriffen, das standardmäßig in .NET Core Verwendung findet. Wenn Sie eine bestimmte hierarchische Konfigurationseinstellung in App Service außer Kraft setzen möchten, legen Sie den Namen der App-Einstellung mit dem gleichen Trennzeichenformat im Schlüssel fest. Sie können das folgende Beispiel in Azure Cloud Shell ausführen:

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

Bereitstellen von Projektmappen mit mehreren Projekten

Wenn eine Visual Studio-Projektmappe mehrere Projekte enthält, wählt der Veröffentlichungsprozess von Visual Studio automatisch das bereitzustellende Projekt aus. Wenn Sie für die App Service-Bereitstellungs-Engine bereitstellen, z. B. mit Git oder einer ZIP-Bereitstellung mit aktivierter Buildautomatisierung , wählt die App Service-Bereitstellungs-Engine das erste Website- oder Webanwendungsprojekt aus, das als App Service-App gefunden wird. Sie können angeben, welches Projekt App Service verwenden soll, indem Sie die App-Einstellung PROJECT angeben. Führen Sie beispielsweise den folgenden Befehl in Cloud Shell aus:

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

Zugreifen auf Diagnoseprotokolle

ASP.NET Core bietet einen integrierten Protokollierungsanbieter für App Service. Fügen Sie in der Datei Ihres Projekts program.cs den Anbieter über die ConfigureLogging Erweiterungsmethode zu Ihrer Anwendung hinzu, wie im folgenden Beispiel gezeigt:

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

Anschließend können Sie Protokolle mit dem standardmäßigen .NET Core-Muster konfigurieren und generieren.

Um auf die Konsolenprotokolle zuzugreifen, die aus Ihrem Anwendungscode in App Service generiert wurden, aktivieren Sie die Diagnoseprotokollierung, indem Sie den folgenden Befehl in Cloud Shell ausführen:

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

Mögliche Werte für --level sind Error, Warning, Info und Verbose. Jede nachfolgende Ebene enthält die vorherige Ebene. Enthält z. B. Error nur Fehlermeldungen. Verbose enthält alle Nachrichten.

Führen Sie nach dem Aktivieren der Diagnoseprotokollierung den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen:

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

Wenn Konsolenprotokolle nicht sofort angezeigt werden, überprüfen Sie es in 30 Sekunden erneut.

Wenn Sie das Protokollstreaming jederzeit beenden möchten, wählen Sie STRG+C aus.

Weitere Informationen zur Problembehandlung ASP.NET Core-Apps in App Service finden Sie unter Problembehandlung ASP.NET Core für Azure App Service und IIS.

Zugreifen auf eine detaillierte Ausnahmeseite

Wenn Ihre ASP.NET Core-App eine Ausnahme im Visual Studio-Debugger generiert, zeigt der Browser eine detaillierte Ausnahmeseite an, aber in App Service wird diese Seite durch einen generischen "HTTP 500" oder "Fehler beim Verarbeiten Ihrer Anforderung" ersetzt. Um die detaillierte Ausnahmeseite in App Service anzuzeigen, fügen Sie ihrer App die ASPNETCORE_ENVIRONMENT App-Einstellung hinzu, indem Sie den folgenden Befehl in Cloud Shell ausführen.

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

Erkennen einer HTTPS-Sitzung

In App Service erfolgt die TLS/SSL-Terminierung in den Modulen für den Netzwerklastenausgleich, sodass alle HTTPS-Anforderungen Ihre App als unverschlüsselte HTTP-Anforderungen erreichen. Wenn Ihre App-Logik wissen muss, ob Benutzeranforderungen verschlüsselt sind, konfigurieren Sie die Forwarded Headers Middleware in Startup.cs:

  • Konfigurieren Sie die Middleware mit ForwardedHeadersOptions so, dass die Header X-Forwarded-For und X-Forwarded-Proto in Startup.ConfigureServices weitergeleitet werden.
  • Fügen Sie den bekannten Netzwerken private IP-Adressbereiche hinzu, damit die Middleware dem App Service-Lastenausgleich vertrauen kann.
  • Rufen Sie die Methode UseForwardedHeaders in Startup.Configure auf, bevor Sie andere Middleware aufrufen.

Wenn Sie die drei Elemente zusammenstellen, sieht ihr Code wie im folgenden Beispiel aus:

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

Weitere Informationen finden Sie unter Konfigurieren von ASP.NET Core für die Arbeit mit Proxyservern und Lastenausgleichen.

Umschreibungs- oder Umleitungs-URL

Um eine URL umzuschreiben oder umzuleiten, verwenden Sie die URL-Umschreibungs-Middleware in ASP.NET Core.

Öffnen einer SSH-Sitzung im Browser

Um eine direkte SSH-Sitzung mit Ihrem Container zu öffnen, sollte Ihre App ausgeführt werden.

Verwenden Sie den Befehl az webapp ssh .

Wenn Sie noch nicht authentifiziert sind, müssen Sie sich mit Ihrem Azure-Abonnement für die Verbindung authentifizieren. Nach der Authentifizierung wird im Browser eine Shell angezeigt, über die Sie Befehle innerhalb Ihres Containers ausführen können.

SSH-Verbindung

Hinweis

Alle Änderungen, die Sie außerhalb des /home Verzeichnisses vornehmen, werden im Container selbst gespeichert und bleiben nicht über einen App-Neustart hinaus bestehen.

Informationen zum Öffnen einer SSH-Remotesitzung von Ihrem lokalen Computer aus finden Sie unter Öffnen einer SSH-Sitzung per Remote-Shell.

Die Roboter933456-Nachricht in den Protokollen ignorieren.

Möglicherweise wird die folgende Meldung in den Containerprotokollen angezeigt:

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

Diese Meldung können Sie problemlos ignorieren. /robots933456.txt ist ein Dummy-URL-Pfad, den App Service verwendet, um zu überprüfen, ob der Container in der Lage ist, Anforderungen zu verarbeiten. Eine 404-Antwort gibt an, dass der Pfad nicht vorhanden ist, und signalisiert dem App-Dienst, dass der Container fehlerfrei ist und bereit ist, auf Anforderungen zu reagieren.

Verwandte Inhalte