Konfigurowanie aplikacji ASP.NET Core dla Azure App Service

Artykuł
06/01/2023

Uwaga

Aby uzyskać ASP.NET w .NET Framework, zobacz Konfigurowanie aplikacji ASP.NET dla Azure App Service. Jeśli aplikacja ASP.NET Core działa w niestandardowym kontenerze systemu Windows lub Linux, zobacz Konfigurowanie niestandardowego kontenera dla Azure App Service.

ASP.NET Core aplikacje muszą być wdrażane w Azure App Service jako skompilowane pliki binarne. Narzędzie do publikowania programu Visual Studio kompiluje rozwiązanie, a następnie wdraża skompilowane pliki binarne bezpośrednio, natomiast aparat wdrażania 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 Azure App Service, najpierw postępuj zgodnie z przewodnikiem Szybki start ASP.NET Core i ASP.NET Core z samouczkiem SQL Database.

Pokaż obsługiwane wersje środowiska uruchomieniowego platformy .NET Core

W 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ę platformy .NET Core

Aby wyświetlić bieżącą wersję platformy .NET Core, uruchom następujące polecenie w 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 Cloud Shell:

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

Ustawianie wersji platformy .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 Cloud Shell, aby ustawić wersję platformy .NET Core na 3.1:

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

Dostosowywanie automatyzacji kompilacji

Jeśli aplikacja jest wdrażana przy użyciu narzędzia Git lub pakietów zip z włączoną automatyzacją kompilacji, App Service kroki automatyzacji kompilacji w ramach następującej sekwencji:

Uruchom skrypt niestandardowy, jeśli został określony przez PRE_BUILD_SCRIPT_PATHpolecenie .
Uruchom polecenie dotnet restore , aby przywrócić zależności NuGet.
Uruchom polecenie dotnet publish , aby skompilować plik binarny dla środowiska produkcyjnego.
Uruchom skrypt niestandardowy, jeśli został 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 element POST_BUILD_COMMAND.

Poniższy przykład określa dwie zmienne 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 kompilowanie App Service ASP.NET Core aplikacji 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żesz 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 App Service i w pliku appsettings.json, na przykład wartość App Service ma pierwszeństwo przed wartością appsettings.json. Wartość local appsettings.json umożliwia lokalne debugowanie aplikacji, ale wartość 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

Zwróć uwagę, że dostęp do danych konfiguracji hierarchicznej w pliku 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 App Service, ustaw nazwę ustawienia aplikacji o tym samym formacie rozdzielanym w kluczu. W 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 pliku appsettings.json jest uzyskiwany przy użyciu ogranicznika standardowego : dla platformy .NET Core. Aby zastąpić określone ustawienie konfiguracji hierarchicznej w App Service, ustaw nazwę ustawienia aplikacji o tym samym formacie rozdzielanym w kluczu. W 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 obejmuje już wybór projektu do wdrożenia. Podczas wdrażania w akomponecie wdrażania App Service, takim jak w usłudze Git, lub w przypadku wdrożenia zip z włączoną automatyzacją kompilacji aparat wdrażania App Service wybiera pierwszą witrynę sieci Web lub projekt aplikacji sieci Web, który znajduje jako aplikację App Service. Możesz określić, którego projektu App Service użyć, określając PROJECT ustawienie aplikacji. Na przykład uruchom następujące polecenie w 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 App Service. W pliku 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 ASP.NET Core w usługach Azure App Service i 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 App Service ta strona jest zastępowana ogólnym błędem HTTP 500 lub Wystąpił błąd podczas przetwarzania komunikatu żądania. Aby wyświetlić szczegółową stronę wyjątku w App Service, dodaj ASPNETCORE_ENVIRONMENT ustawienie aplikacji do aplikacji, uruchamiając następujące polecenie w 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 App Service zakończenie 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 pliku Startup.cs:

Skonfiguruj oprogramowanie pośredniczące za pomocą polecenia ForwardedHeadersOptions , aby przekazywać X-Forwarded-For nagłówki i X-Forwarded-Proto w pliku Startup.ConfigureServices.
Dodaj zakresy prywatnych adresów IP do znanych sieci, aby oprogramowanie pośredniczące ufało App Service modułowi równoważenia obciążenia.
Przed wywołaniem innego oprogramowania pośredniczącego wywołaj metodę Startup.ConfigureUseForwardedHeaders.

Umieszczenie wszystkich trzech elementów w kodzie wygląda podobnie do następującego przykładu:

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.

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.

Połączenie SSH

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

Samouczek: ASP.NET Core aplikacja z SQL Database

App Service dla systemu Linux — często zadawane pytania

Lub zobacz więcej zasobów:

Dokumentacja zmiennych środowiskowych i ustawień aplikacji

Konfigurowanie aplikacji ASP.NET Core dla Azure App Service

Pokaż obsługiwane wersje środowiska uruchomieniowego platformy .NET Core

Pokaż wersję platformy .NET Core

Ustawianie wersji platformy .NET Core

Dostosowywanie automatyzacji kompilacji

Uzyskiwanie dostępu do zmiennych środowiskowych

Wdrażanie rozwiązań wieloprojektowych

Uzyskiwanie dostępu do dzienników diagnostycznych

Uzyskiwanie strony szczegółowych wyjątków

Wykrywanie sesji protokołu HTTPS

Otwieranie sesji SSH w przeglądarce

robots933456 w dziennikach

Następne kroki

Dodatkowe zasoby