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 Veröffentlichungstool für Visual Studio erstellt die Projektmappe und stellt dann die kompilierten Binärdateien direkt bereit, während die App Service-Bereitstellungs-Engine zuerst das Coderepository und dann die Binärdateien kompiliert.
Dieser Leitfaden enthält wichtige Konzepte und Anweisungen für ASP.NET Core-Entwickler. Wenn Sie Azure App Service noch nie verwendet haben, folgen Sie zunächst dem ASP.NET Core-Schnellstart und dem Tutorial zu ASP.NET Core mit SQL-Datenbank.
Anzeigen unterstützter .NET Core-Runtimeversionen
In App Service sind auf den Windows-Instanzen bereits alle unterstützten .NET Core-Versionen installiert. Navigieren Sie zu https://<app-name>.scm.azurewebsites.net/DebugConsole, und führen Sie den folgenden Befehl in der browserbasierten Konsole aus, um die für Sie verfügbaren .NET Core-Runtime- und .NET Core SDK-Versionen anzuzeigen:
dotnet --info
Anzeigen der .NET Core-Version
Führen Sie in Cloud Shell den folgenden Befehl aus, um die aktuelle .NET Core-Version anzuzeigen:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Führen Sie in Cloud Shell den folgenden Befehl aus, um alle unterstützten .NET Core-Version anzuzeigen:
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 in der .NET Core-Dokumentation.
Führen Sie in Cloud Shell den folgenden Befehl aus, um die .NET Core-Version auf 3.1 festzulegen:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|3.1"
Anpassen der Buildautomatisierung
Wenn Sie Ihre App mithilfe von Git oder mit ZIP-Paketen mit aktivierter Buildautomatisierung bereitstellen, durchläuft die App Service-Buildautomatisierung die Schritte der folgenden Sequenz:
- Ausführen eines benutzerdefinierten Skripts, falls mittels
PRE_BUILD_SCRIPT_PATHangegeben. - Ausführen von
dotnet restore, um NuGet-Abhängigkeiten wiederherzustellen. - Ausführen von
dotnet publish, um eine Binärdatei für die Produktion zu erstellen. - Ausführen eines benutzerdefinierten Skripts, falls mittels
POST_BUILD_SCRIPT_PATHangegeben.
PRE_BUILD_COMMAND und POST_BUILD_COMMAND sind Umgebungsvariablen, die standardmäßig leer sind. Um Präbuildbefehle 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 zum Anpassen der Buildautomatisierung 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 beispielsweise eine App-Einstellung mit demselben Namen in App Service und in appsettings.json konfigurieren, hat der App Service-Wert Vorrang vor dem Wert für appsettings.json. Mit dem lokalen Wert für appsettings.json können Sie die App lokal debuggen, aber mit dem App Service-Wert können Sie die App in der Produktion mit Produktionseinstellungen ausführen. Verbindungszeichenfolgen funktionieren auf dieselbe Weise. Auf diese Weise können Sie Ihre Anwendungsgeheimnisse außerhalb Ihres Coderepositorys aufbewahren und auf die entsprechenden Werte zugreifen, ohne Ihren Code zu ändern.
Hinweis
Beachten Sie, dass auf die hierarchischen Konfigurationsdaten in der Datei appsettings.json mit dem __-Trennzeichen (doppelter Unterstrich) zugegriffen wird, 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 der Cloud Shell ausführen:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
Hinweis
Beachten Sie, dass auf die hierarchischen Konfigurationsdaten in der Datei appsettings.json mit dem :-Trennzeichen zugegriffen wird, 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 der 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, umfasst der Veröffentlichungsprozess von Visual Studio bereits das Auswählen des bereitzustellenden Projekts. 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 z. B. den folgenden Befehl in der 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 Protokollanbieter für App Service. Fügen Sie in der Datei Program.cs Ihres Projekts den Anbieter mithilfe der ConfigureLogging-Erweiterungsmethode zu Ihrer Anwendung hinzu, wie dies im folgenden Beispiel gezeigt wird:
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.
Aktivieren Sie die Diagnoseprotokollierung, indem Sie den folgenden Befehl in Cloud Shellausführen, um auf die Konsolenprotokolle zuzugreifen, die innerhalb des Anwendungscodes in App Service generiert wurden:
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, WarningInfo oder Verbose. Jede nachfolgende Ebene enthält die vorherige Ebene. Beispiel: Error enthält nur Fehlermeldungen, und Verbose enthält alle Meldungen.
Führen Sie den folgenden Befehl aus, um den Protokolldatenstrom anzuzeigen, nachdem die Diagnoseprotokollierung aktiviert wurde:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Falls Sie nicht sofort Konsolenprotokolle sehen, können Sie es nach 30 Sekunden noch einmal versuchen.
Hinweis
Sie können die Protokolldateien auch im Browser unter https://<app-name>.scm.azurewebsites.net/api/logs/docker untersuchen.
Um das Protokollstreaming jederzeit zu beenden, geben Sie Ctrl+C ein.
Weitere Informationen zur Problembehandlung von ASP.NET Core-Apps in App Service finden Sie unter Problembehandlung bei ASP.NET Core in Azure App Service und IIS.
Abrufen einer detaillierten Ausnahmenseite
Wenn Ihre ASP. NET Core-App eine Ausnahme im Visual Studio-Debugger erzeugt, zeigt der Browser eine detaillierte Ausnahmeseite an, aber in App Service wird diese Seite durch einen allgemeinen HTTP 500-Fehler oder durch die Meldung Fehler beim Bearbeiten Ihrer Anforderung aufgetreten ersetzt. Um die detaillierte Ausnahmenseite in App Service anzuzeigen, fügen Sie die App-Einstellung ASPNETCORE_ENVIRONMENT zu Ihrer App hinzu, indem Sie den folgenden Befehl in der 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 die Benutzeranforderungen verschlüsselt sind, konfigurieren Sie die Forwarded Headers Middleware in Startup.cs:
- Konfigurieren Sie die Middleware mit ForwardedHeadersOptions, um die Header
X-Forwarded-ForundX-Forwarded-ProtoinStartup.ConfigureServicesweiterzuleiten. - 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.Configureauf, bevor Sie andere Middleware aufrufen.
Wenn Sie alle drei Elemente zusammensetzen, 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.
Öffnen einer SSH-Sitzung im Browser
Um eine direkte SSH-Sitzung mit Ihrem Container zu öffnen, sollte Ihre App ausgeführt werden.
Fügen Sie die folgende URL in Ihren Browser ein, und ersetzen Sie <app-name> durch den Namen Ihrer App:
https://<app-name>.scm.azurewebsites.net/webssh/host
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.
Hinweis
Alle Änderungen, die Sie, außerhalb des Verzeichnisses /home vornehmen, werden im Container selbst gespeichert und bleiben nicht über einen Neustart der App hinaus erhalten.
Informationen zum Öffnen einer SSH-Remotesitzung von Ihrem lokalen Computer aus finden Sie unter Öffnen einer SSH-Sitzung per Remote-Shell.
„robots933456“ in Protokollen
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 zeigt lediglich an, dass der Pfad nicht vorhanden ist, informiert App Service aber darüber, dass der Container fehlerfrei und bereit ist, um auf Anforderungen zu antworten.
Nächste Schritte
Oder sehen Sie sich weitere Ressourcen an: