Konfigurowanie aplikacji ASP.NET Core dla usługi aplikacja systemu Azure
Uwaga
Aby uzyskać ASP.NET w programie .NET Framework, zobacz Konfigurowanie aplikacji ASP.NET dla usługi aplikacja systemu Azure. Jeśli aplikacja ASP.NET Core działa w niestandardowym kontenerze systemu Windows lub Linux, zobacz Konfigurowanie niestandardowego kontenera dla usługi aplikacja systemu Azure Service.
aplikacje ASP.NET Core muszą być wdrażane w usłudze aplikacja systemu Azure jako skompilowane pliki binarne. Narzędzie do publikowania programu Visual Studio kompiluje rozwiązanie, a następnie wdraża skompilowane pliki binarne bezpośrednio, podczas gdy aparat wdrażania usługi App Service najpierw wdraża repozytorium kodu, a następnie kompiluje pliki binarne.
Ten przewodnik zawiera kluczowe pojęcia i instrukcje dla deweloperów ASP.NET Core. Jeśli nigdy nie używasz usługi aplikacja systemu Azure Service, najpierw postępuj zgodnie z przewodnikiem Szybki start ASP.NET Core i ASP.NET Core z usługą SQL Database.
Pokaż obsługiwane wersje środowiska uruchomieniowego platformy .NET Core
W usłudze App Service wystąpienia systemu Windows mają już zainstalowane wszystkie obsługiwane wersje platformy .NET Core. Aby wyświetlić dostępne wersje środowiska uruchomieniowego i zestawu SDK platformy .NET Core, przejdź do https://<app-name>.scm.azurewebsites.net/DebugConsole i uruchom następujące polecenie w konsoli opartej na przeglądarce:
dotnet --info
Pokaż wersję .NET Core
Aby wyświetlić bieżącą wersję platformy .NET Core, uruchom następujące polecenie w usłudze Cloud Shell:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
Aby wyświetlić wszystkie obsługiwane wersje platformy .NET Core, uruchom następujące polecenie w usłudze Cloud Shell:
az webapp list-runtimes --os linux | grep DOTNET
Ustaw wersję .NET Core
Ustaw strukturę docelową w pliku projektu dla projektu ASP.NET Core. Aby uzyskać więcej informacji, zobacz Wybieranie wersji platformy .NET Core do użycia w dokumentacji platformy .NET Core.
Uruchom następujące polecenie w usłudze Cloud Shell, aby ustawić wersję platformy .NET Core na 8.0:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
Dostosowywanie automatyzacji kompilacji
Uwaga
Kompilowanie aplikacji .NET 9 (STS) w usłudze Windows App Service przy użyciu programu MSBuild lub SCM_DO_BUILD nie jest jeszcze obsługiwane. Obsługa tych scenariuszy kompilacji nastąpi po początkowej dacie ogólnodostępnej i do 4 grudnia 2024 r. Wdrożenia tworzone poza usługą App Service za pośrednictwem programu Visual Studio, programu Visual Studio Code, funkcji GitHub Actions i usługi Azure DevOps są w pełni obsługiwane.
Jeśli wdrażasz aplikację przy użyciu pakietu Git lub zip z włączoną automatyzacją kompilacji, procedura automatyzacji kompilacji usługi App Service przebiega przez następującą sekwencję:
- Uruchom skrypt niestandardowy, jeśli jest określony przez
PRE_BUILD_SCRIPT_PATHpolecenie . - Uruchom polecenie
dotnet restore, aby przywrócić zależności NuGet. - Uruchom polecenie
dotnet publish, aby utworzyć plik binarny dla środowiska produkcyjnego. - Uruchom skrypt niestandardowy, jeśli jest określony przez
POST_BUILD_SCRIPT_PATHpolecenie .
PRE_BUILD_COMMAND i POST_BUILD_COMMAND są zmiennymi środowiskowymi, które są domyślnie puste. Aby uruchomić polecenia przed kompilacją, zdefiniuj polecenie PRE_BUILD_COMMAND. Aby uruchomić polecenia po kompilacji, zdefiniuj polecenie POST_BUILD_COMMAND.
Poniższy przykład określa dwie zmienne do serii poleceń rozdzielonych przecinkami.
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"
Aby uzyskać informacje o innych zmiennych środowiskowych w celu dostosowania automatyzacji kompilacji, zobacz Konfiguracja Oryx.
Aby uzyskać więcej informacji na temat sposobu uruchamiania i kompilowania aplikacji ASP.NET Core w systemie Linux, zobacz dokumentację oryx: jak są wykrywane i kompilowane aplikacje platformy .NET Core.
Uzyskiwanie dostępu do zmiennych środowiskowych
W usłudze App Service można określić ustawienia aplikacji poza kodem aplikacji. Następnie można uzyskać do nich dostęp w dowolnej klasie przy użyciu standardowego wzorca wstrzykiwania zależności ASP.NET Core:
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");
}
}
}
Jeśli skonfigurujesz ustawienie aplikacji o tej samej nazwie w usłudze App Service i w appsettings.json, na przykład wartość usługi App Service ma pierwszeństwo przed wartością appsettings.json . Lokalna wartość appsettings.json umożliwia lokalne debugowanie aplikacji, ale wartość usługi App Service umożliwia uruchamianie aplikacji w środowisku produkcyjnym przy użyciu ustawień produkcyjnych. Parametry połączenia działają w taki sam sposób. Dzięki temu możesz przechowywać wpisy tajne aplikacji poza repozytorium kodu i uzyskiwać dostęp do odpowiednich wartości bez konieczności zmieniania kodu.
Uwaga
Rozważ bardziej bezpieczne opcje łączności, które w ogóle nie wymagają wpisów tajnych połączenia. Aby uzyskać więcej informacji, zobacz Zabezpieczanie łączności z usługami i bazami danych platformy Azure z usługi aplikacja systemu Azure Service.
Uwaga
Zwróć uwagę, że dostęp do danych konfiguracji hierarchicznej w appsettings.json jest uzyskiwany przy użyciu __ ogranicznika (podwójnego podkreślenia), który jest standardowy w systemie Linux do platformy .NET Core. Aby zastąpić określone ustawienie konfiguracji hierarchicznej w usłudze App Service, ustaw nazwę ustawienia aplikacji o tym samym formacie rozdzielonym w kluczu. W usłudze Cloud Shell można uruchomić następujący przykład:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
Uwaga
Zwróć uwagę, że dostęp do danych konfiguracji hierarchicznej w appsettings.json jest uzyskiwany przy użyciu ogranicznika standardowego : dla platformy .NET Core. Aby zastąpić określone ustawienie konfiguracji hierarchicznej w usłudze App Service, ustaw nazwę ustawienia aplikacji o tym samym formacie rozdzielonym w kluczu. W usłudze Cloud Shell można uruchomić następujący przykład:
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"
Wdrażanie rozwiązań wieloprojektowych
Gdy rozwiązanie programu Visual Studio zawiera wiele projektów, proces publikowania programu Visual Studio zawiera już wybór projektu do wdrożenia. Po wdrożeniu w akomponecie wdrażania usługi App Service, takim jak w usłudze Git lub wdrożeniu zip z włączoną automatyzacją kompilacji, aparat wdrażania usługi App Service wybiera pierwszą witrynę internetową lub projekt aplikacji internetowej, który znajduje jako aplikację usługi App Service. Możesz określić, który projekt ma być używany przez usługę PROJECT App Service, określając ustawienie aplikacji. Na przykład uruchom następujące polecenie w usłudze Cloud Shell:
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
Uzyskiwanie dostępu do dzienników diagnostycznych
ASP.NET Core udostępnia wbudowanego dostawcę rejestrowania dla usługi App Service. W Program.cs projektu dodaj dostawcę do aplikacji za pomocą ConfigureLogging metody rozszerzenia, jak pokazano w poniższym przykładzie:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.AddAzureWebAppDiagnostics();
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
Następnie można skonfigurować i wygenerować dzienniki przy użyciu standardowego wzorca platformy .NET Core.
Aby uzyskać dostęp do dzienników konsoli wygenerowanych wewnątrz kodu aplikacji w usłudze App Service, włącz rejestrowanie diagnostyczne, uruchamiając następujące polecenie w usłudze Cloud Shell:
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
Możliwe wartości parametru --level to: Error, Warning, Info i Verbose. Każdy kolejny poziom obejmuje poprzedni poziom. Na przykład poziom Error obejmuje tylko komunikaty o błędach, a poziom Verbose obejmuje wszystkie komunikaty.
Po włączeniu rejestrowania diagnostycznego uruchom następujące polecenie, aby wyświetlić strumień dziennika:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Jeśli nie widzisz dzienników konsoli, sprawdź ponownie w ciągu 30 sekund.
Uwaga
Pliki dzienników można także sprawdzać w przeglądarce pod adresem https://<app-name>.scm.azurewebsites.net/api/logs/docker.
Aby w dowolnym momencie zatrzymać przesyłanie strumieniowe dzienników, naciśnij kombinację klawiszy Ctrl+C.
Aby uzyskać więcej informacji na temat rozwiązywania problemów z aplikacjami ASP.NET Core w usłudze App Service, zobacz Rozwiązywanie problemów z programem ASP.NET Core w usłudze aplikacja systemu Azure i usługach IIS
Uzyskiwanie strony szczegółowych wyjątków
Gdy aplikacja ASP.NET Core generuje wyjątek w debugerze programu Visual Studio, w przeglądarce jest wyświetlana szczegółowa strona wyjątku, ale w usłudze App Service ta strona jest zastępowana przez ogólny http 500 lub wystąpił błąd podczas przetwarzania żądania. Aby wyświetlić szczegółową stronę wyjątku w usłudze App Service, dodaj ASPNETCORE_ENVIRONMENT ustawienie aplikacji do aplikacji, uruchamiając następujące polecenie w usłudze Cloud Shell.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"
Wykrywanie sesji protokołu HTTPS
W usłudze App Service kończenie żądań PROTOKOŁU TLS/SSL odbywa się w modułach równoważenia obciążenia sieciowego, więc wszystkie żądania HTTPS docierają do aplikacji jako niezaszyfrowane żądania HTTP. Jeśli logika aplikacji musi wiedzieć, czy żądania użytkownika są szyfrowane, czy nie, skonfiguruj oprogramowanie pośredniczące nagłówków przekazywanych w Startup.cs:
- Skonfiguruj oprogramowanie pośredniczące za pomocą polecenia ForwardedHeadersOptions , aby przekazać nagłówki
X-Forwarded-ForiX-Forwarded-Protow plikuStartup.ConfigureServices. - Dodaj zakresy prywatnych adresów IP do znanych sieci, dzięki czemu oprogramowanie pośredniczące może ufać modułowi równoważenia obciążenia usługi App Service.
- Przed wywołaniem innego oprogramowania pośredniczącego wywołaj metodę
Startup.ConfigureUseForwardedHeaders.
Umieszczenie wszystkich trzech elementów w kodzie wygląda następująco:
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();
}
Aby uzyskać więcej informacji, zobacz Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia.
Ponowne zapisywanie lub przekierowywanie adresu URL
Aby przepisać lub przekierować adres URL, użyj adresu URL ponownego zapisywania oprogramowania pośredniczącego w ASP.NET Core.
Otwieranie sesji SSH w przeglądarce
Aby otworzyć bezpośrednią sesję SSH w kontenerze, należy uruchomić aplikację.
Wklej następujący adres URL do przeglądarki i zastąp wartość <app-name> nazwą swojej aplikacji:
https://<app-name>.scm.azurewebsites.net/webssh/host
Jeśli nie masz jeszcze uwierzytelnienia, musisz uwierzytelnić się w subskrypcji platformy Azure, aby nawiązać połączenie. Po uwierzytelnieniu zostanie wyświetlona powłoka w przeglądarce umożliwiająca uruchamianie poleceń w kontenerze.
Uwaga
Wszelkie zmiany wprowadzone poza katalogiem /home są przechowywane w samym kontenerze i nie są zachowywane po ponownym uruchomieniu aplikacji.
Aby otworzyć zdalną sesję SSH z komputera lokalnego, zobacz Otwieranie sesji SSH z poziomu powłoki zdalnej.
robots933456 w dziennikach
W dziennikach kontenera może zostać wyświetlony następujący komunikat:
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
Możesz bezpiecznie zignorować ten komunikat. /robots933456.txt jest fikcyjną ścieżką adresu URL, za pomocą której usługa App Service sprawdza, czy kontener jest w stanie obsługiwać żądania. Odpowiedź 404 oznacza po prostu, że ścieżka nie istnieje, ale pozwala usłudze App Service sprawdzić, czy kontener jest w dobrej kondycji i jest gotowy do reagowania na żądania.
Następne kroki
Lub zobacz więcej zasobów: