Dela via

Konfigurera en ASP.NET Core-app för Azure App Service

Kommentar

För ASP.NET i .NET Framework, se Konfigurera en ASP.NET-app för Azure App Service. Om din ASP.NET Core-app körs i en anpassad Windows- eller Linux-container läser du Konfigurera en anpassad container för Azure App Service.

ASP.NET Core-appar måste distribueras till Azure App Service som kompilerade binärfiler. Visual Studio-publiceringsverktyget skapar lösningen och distribuerar sedan de kompilerade binärfilerna direkt. App Service-distributionsmotorn distribuerar först kodlagringsplatsen och kompilerar sedan binärfilerna.

Den här guiden innehåller viktiga begrepp och instruktioner för ASP.NET Core-utvecklare. Om det här är första gången du använder Azure App Service följer du först snabbstarten ASP.NET Core och ASP.NET Core med SQL Database.

Visa .NET Core-körningsversioner som stöds

I App Service har Windows-instanserna redan alla .NET Core-versioner som stöds installerade. Om du vill se de .NET Core-runtime- och SDK-versioner som är tillgängliga för dig går du till din Kudu-webbplats.

Gå till din app i Azure-portalen och välj sedan Utvecklingsverktyg>Avancerade verktyg. Välj Gå. I Kudu väljer du Felsökningskonsol för CMD eller PowerShell.

Kör följande kommando i den webbläsarbaserade konsolen:

dotnet --info

Visa .NET Core version

Om du vill visa den aktuella .NET Core-versionen kör du följande kommando i Azure Cloud Shell:

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

Om du vill visa alla .NET Core-versioner som stöds kör du följande kommando i Cloud Shell:

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

Ange .NET Core version

Ange målramverket i projektfilen för ditt ASP.NET Core-projekt. Mer information finns i Välj den .NET Core-version som ska användas.

Om du vill ange .NET Core-versionen till 8.0 kör du följande kommando i Cloud Shell:

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

Vad händer med inaktuella körmiljöer i App Service?

Inaktuella körningsmiljöer avvecklas av den underhållande organisationen eller har visat sig ha betydande säkerhetsrisker. Därför tas de bort från skapa och konfigurera sidor i portalen. När en föråldrad runtime är dold från portalen fortsätter alla appar som fortfarande använder den att köra.

Om du vill skapa en app med en inaktuell körningsversion som inte längre visas på portalen använder du Azure CLI, ARM-mallen eller Bicep. Med de här distributionsalternativen kan du skapa inaktuella körmiljöer som har tagits bort i portalen, men som fortfarande stöds.

Om en runtime tas bort helt från App Service-plattformen får ägaren till din Azure-prenumeration ett e-postmeddelande innan borttagningen.

Anpassa byggautomatisering

Om du distribuerar din app med hjälp av Git- eller ZIP-paket med versionsautomation aktiverat följer App Service Build Automation den här sekvensen:

  1. Kör anpassat skript om det anges av PRE_BUILD_SCRIPT_PATH.
  2. Om du vill återställa NuGet-beroenden kör du dotnet restore.
  3. Om du vill skapa en binär fil för produktion kör du dotnet publish.
  4. Kör anpassat skript om det anges av POST_BUILD_SCRIPT_PATH.

PRE_BUILD_COMMAND och POST_BUILD_COMMAND är miljövariabler som är tomma som standard. För att köra förberedda kommandon måste du definiera PRE_BUILD_COMMAND. Om du vill köra kommandon efter bygget definierar du POST_BUILD_COMMAND.

I följande exempel anges de två variablerna till en serie kommandon, avgränsade med kommatecken.

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"

Andra miljövariabler som du kan använda för att anpassa versionsautomation finns i Oryx-konfiguration.

Mer information om hur App Service kör och bygger ASP.NET Core-appar i Linux finns i Oryx-dokumentationen : Hur .NET Core-appar identifieras och skapas.

Få åtkomst till miljövariabler

I App Service kan du ange appinställningar utanför din appkod. Du kan sedan komma åt dem i valfri klass med hjälp av standardmönstret för ASP.NET Core-beroendeinmatning:

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

Om du konfigurerar en appinställning med samma namn i App Service och i appsettings.json, till exempel, har App Service-värdet företräde framför appsettings.json värdet. Genom att använda det lokala appsettings.json värdet kan du felsöka appen lokalt, men genom att använda App Service-värdet kan du köra appen i produktion med produktionsinställningar. Anslutningssträngar fungerar på samma sätt. Med den här metoden kan du behålla dina programhemligheter utanför kodlagringsplatsen och komma åt lämpliga värden utan att ändra koden.

Kommentar

Du kan också överväga säkrare anslutningsalternativ som inte kräver anslutningshemligheter. Mer information finns i Säker anslutning till Azure-tjänster och -databaser från Azure App Service.

Hierarkiska konfigurationsdata i appsettings.json används med hjälp av den __ (dubbla understreck) avgränsare som är standard i Linux till .NET Core. Om du vill åsidosätta en specifik hierarkisk konfigurationsinställning i App Service anger du namnet på appinställningen med samma avgränsade format i nyckeln. Du kan köra följande exempel i Cloud Shell:

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

Hierarkiska konfigurationsdata i appsettings.json används med hjälp av avgränsare : som är standard för .NET Core. Om du vill åsidosätta en specifik hierarkisk konfigurationsinställning i App Service anger du namnet på appinställningen med samma avgränsade format i nyckeln. Du kan köra följande exempel i Azure Cloud Shell:

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

Distribuera lösningar för flera projekt

När en Visual Studio-lösning innehåller flera projekt väljer Visual Studio-publiceringsprocessen automatiskt det projekt som ska distribueras. När du distribuerar till App Service-distributionsmotorn, till exempel med Git eller med ZIP-distribution med byggautomatisering aktiverad, väljer App Service-distributionsmotorn det första webbplats- eller webbprogramprojektet som den hittar som App Service-app. Du kan ange vilket projekt App Service ska använda genom att ange appinställningen PROJECT . Kör till exempel följande kommando i Cloud Shell:

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

Få åtkomst till diagnostikloggar

ASP.NET Core erbjuder en inbyggd loggningsprovider för App Service. I projektets program.cs fil lägger du till providern i ditt program via ConfigureLogging tilläggsmetoden, som du ser i följande exempel:

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

Du kan sedan konfigurera och generera loggar med standardmönstret .NET Core.

Om du vill komma åt konsolloggarna som genereras inifrån programkoden i App Service aktiverar du diagnostikloggning genom att köra följande kommando i Cloud Shell:

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

Möjliga värden för --level är Error, Warning, Infooch Verbose. Varje efterföljande nivå omfattar den föregående nivån. Till exempel innehåller Error endast felmeddelanden. Verbose innehåller alla meddelanden.

När du har aktiverat diagnostikloggning kör du följande kommando för att se loggströmmen:

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

Om konsolloggarna inte visas omedelbart kontrollerar du igen om 30 sekunder.

För att stoppa loggströmning när som helst, välj Ctrl+C.

Mer information om hur du felsöker ASP.NET Core-appar i App Service finns i Felsöka ASP.NET Core i Azure App Service och IIS.

Åtkomst till en detaljerad undantagssida

När din ASP.NET Core-app genererar ett undantag i Visual Studio-felsökningsprogrammet visar webbläsaren en detaljerad undantagssida, men i App Service ersätts den sidan av en allmän "HTTP 500" eller "Ett fel uppstod när din begäran bearbetades". Om du vill visa den detaljerade undantagssidan i App Service lägger du till appinställningen ASPNETCORE_ENVIRONMENT i appen genom att köra följande kommando i Cloud Shell.

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

Identifiera HTTPS-sessionen

I App Service sker TLS/SSL-avslutning hos nätverkslastbalanserarna, så alla HTTPS-begäranden når din app som okrypterade HTTP-begäranden. Om din applogik behöver veta om användarbegäranden är krypterade konfigurerar du det vidarebefordrade huvudets mellanprogram i Startup.cs:

  • Konfigurera mellanprogrammet med ForwardedHeadersOptions för att vidarebefordra X-Forwarded-For- och X-Forwarded-Proto-huvudena i Startup.ConfigureServices.
  • Lägg till privata IP-adressintervall till de kända nätverken så att mellanprogrammet kan lita på App Service-lastbalanseraren.
  • UseForwardedHeaders Anropa metoden i Startup.Configure innan du anropar andra mellanprogram.

När du monterar de tre elementen ser koden ut som i följande exempel:

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

Mer information finns i Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare.

Skriva om eller omdirigera URL

Om du vill skriva om eller omdirigera en URL använder du mellanprogrammet FÖR URL-omskrivning i ASP.NET Core.

Öppna en SSH-session i webbläsaren

Om du vill öppna en direkt SSH-session med containern bör appen köras.

Använd kommandot az webapp ssh .

Om du inte redan har autentiserats måste du autentisera dig med din Azure-prenumeration för att kunna ansluta. När autentiseringen är klar visas ett gränssnitt i webbläsaren där du kan köra kommandon i containern.

SSH-anslutning

Kommentar

Alla ändringar som du gör utanför /home katalogen lagras i själva containern och sparas inte längre än en appomstart.

Om du vill öppna en SSH-fjärrsession från den lokala datorn, kan du läsa mer i Öppna SSH-session från fjärrgränssnitt.

Ignorera robots933456-meddelandet i loggar

Du kan se följande meddelande i containerloggarna:

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

Du kan ignorera det här meddelandet. /robots933456.txt är en fiktiv URL-sökväg som App Service använder för att kontrollera om containern kan hantera förfrågningar. Ett 404-svar anger att sökvägen inte finns och signalerar till App Service att containern är felfri och redo att svara på begäranden.

Relaterat innehåll