Konfigurera en ASP.NET Core-app för Azure App Service
Kommentar
ASP.NET i .NET Framework finns i 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, medan App Service-distributionsmotorn distribuerar kodlagringsplatsen först och sedan kompilerar binärfilerna.
Den här guiden innehåller viktiga begrepp och instruktioner för ASP.NET Core-utvecklare. Om du aldrig har använt 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 visa de .NET Core-körnings- och SDK-versioner som är tillgängliga för dig går du till https://<app-name>.scm.azurewebsites.net/DebugConsole och 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 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 i .NET Core-dokumentationen.
Kör följande kommando i Cloud Shell för att ange .NET Core-versionen till 8.0:
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
Anpassa versionsautomatisering
Kommentar
Det finns ännu inte stöd för att skapa .NET 9-appar (STS) med Windows App Service med hjälp av MSBuild eller SCM_DO_BUILD. Stöd för dessa byggscenarier kommer efter det första ga-datumet och den 4 december 2024. Distributioner som bygger utanför App Service via Visual Studio, Visual Studio Code, GitHub Actions och Azure DevOps stöds fullt ut.
Om du distribuerar din app med Git eller zip-paket med versionsautomation aktiverat går App Service Build Automation igenom följande sekvens:
- Kör anpassat skript om det anges av
PRE_BUILD_SCRIPT_PATH. - Kör
dotnet restoreför att återställa NuGet-beroenden. - Kör
dotnet publishför att skapa en binär fil för produktion. - 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. Om du vill köra fördefinierade kommandon definierar du 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 för att anpassa versionsautomatisering 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. Sedan kan du komma åt dem i vilken klass som helst 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 det appsettings.json värdet. Med det lokala appsettings.json-värdet kan du felsöka appen lokalt, men med App Service-värdet kan du köra appen i produktion med produktionsinställningar. Anslutningssträngar fungerar på samma sätt. På så sätt kan du hålla dina programhemligheter utanför kodlagringsplatsen och komma åt lämpliga värden utan att ändra koden.
Kommentar
Överväg säkrare anslutningsalternativ som inte kräver anslutningshemligheter alls. Mer information finns i Säker anslutning till Azure-tjänster och -databaser från Azure App Service.
Kommentar
Observera att hierarkiska konfigurationsdata i appsettings.json används med den __ avgränsare (dubbla understreck) 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"
Kommentar
Observera att hierarkiska konfigurationsdata i appsettings.json nås 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 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 innehåller Visual Studio-publiceringsprocessen redan att välja det projekt som ska distribueras. När du distribuerar till App Service-distributionsmotorn, till exempel med Git eller med ZIP-distribution med versionsautomation aktiverad, väljer App Service-distributionsmotorn den första webbplatsen eller webbprogramprojektet som hittas som App Service-appen. 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 tillhandahåller en inbyggd loggningsprovider för App Service. I Program.cs av projektet 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 i din programkod i App Service aktiverar du diagnostisk loggning 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, Info och Verbose. Varje efterföljande nivå omfattar den föregående nivån. Exempel: Error omfattar endast felmeddelanden och Verbose omfattar alla meddelanden.
När diagnostisk loggning har aktiverats kör du följande kommando för att visa loggströmmen:
az webapp log tail --resource-group <resource-group-name> --name <app-name>
Om du inte ser konsolloggarna omedelbart kan du titta efter igen efter 30 sekunder.
Kommentar
Du kan även granska loggfilerna från din webbläsare via https://<app-name>.scm.azurewebsites.net/api/logs/docker.
Skriv Ctrl+C när som helst för att stoppa loggströmningen.
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
Hämta sida med detaljerade undantag
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 inträffade när begäran bearbetades. Om du vill visa den detaljerade undantagssidan i App Service lägger du till appinställningen ASPNETCORE_ENVIRONMENT i din app 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 eller inte konfigurerar du mellanprogrammet Vidarebefordrade rubriker i Startup.cs:
- Konfigurera mellanprogrammet med ForwardedHeadersOptions för att vidarebefordra rubrikerna
X-Forwarded-ForochX-Forwarded-ProtoiStartup.ConfigureServices. - Lägg till privata IP-adressintervall till de kända nätverken så att mellanprogrammet kan lita på App Service-lastbalanseraren.
- Anropa metoden UseForwardedHeaders i
Startup.Configureinnan du anropar andra mellanprogram.
Om du sätter ihop alla 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 URL använder du URL:en för att skriva om mellanprogram i ASP.NET Core.
Öppna en SSH-session i webbläsaren
Om du ska öppna en SSH-direktsession med din container måste appen vara igång.
Klistra in följande URL i webbläsaren och ersätt <app-name> med namnet på appen:
https://<app-name>.scm.azurewebsites.net/webssh/host
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.
Kommentar
Eventuella ändringar som du gör utanför katalogen /start lagras i själva containern och finns inte kvar om appen startas om.
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.
robots933456 i loggar
Följande meddelande kan visas 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 dummysökväg för URL:en som App Service använder till att kontrollera om containern kan hantera begäranden. Ett 404-svar innebär helt enkelt att sökvägen inte finns, men det låter App Service veta att containern är felfri och redo att svara på begäranden.
Nästa steg
Eller se fler resurser: