참고 항목
.NET Framework의 ASP.NET 경우 Azure App Service에 대한 ASP.NET 앱 구성을 참조하세요. ASP.NET Core 앱이 사용자 지정 Windows 또는 Linux 컨테이너에서 실행되는 경우 Azure App Service에 대한 사용자 지정 컨테이너 구성을 참조하세요.
ASP.NET Core 앱은 컴파일된 이진 파일로 Azure App Service에 배포해야 합니다. Visual Studio 게시 도구는 솔루션을 빌드한 다음 컴파일된 이진 파일을 직접 배포합니다. App Service 배포 엔진은 먼저 코드 리포지토리를 배포한 다음 이진 파일을 컴파일합니다.
이 가이드는 ASP.NET Core 개발자를 위한 주요 개념 및 지침을 제공합니다. Azure App Service를 처음 사용하는 경우, 먼저 ASP.NET Core 빠른 시작을 따르고 ASP.NET Core 및 SQL 데이터베이스 자습서를 수행하십시오.
지원되는 .NET Core 런타임 버전 표시
App Service의 Windows 인스턴스에는 지원되는 모든 .NET Core 버전이 이미 설치되어 있습니다. 사용할 수 있는 .NET Core 런타임 및 SDK 버전을 보려면 Kudu 사이트로 이동합니다.
Azure Portal에서 앱으로 이동한 다음, 개발 도구> 선택합니다. 이동을 선택합니다. Kudu에서 CMD 또는 PowerShell에 대한 디버그 콘솔을 선택합니다.
브라우저 기반 콘솔에서 다음 명령을 실행합니다.
dotnet --info
.NET Core 버전 표시
현재 .NET Core 버전을 표시하려면 Azure Cloud Shell에서 다음 명령을 실행합니다.
az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
지원되는 모든 .NET Core 버전을 표시하려면 Cloud Shell에서 다음 명령을 실행합니다.
az webapp list-runtimes --os linux | grep DOTNET
.NET Core 버전 설정
프로젝트 파일에서 ASP.NET Core 프로젝트에 대한 대상 프레임워크를 설정합니다. 자세한 내용은 사용할 .NET Core 버전 선택을 참조하세요.
.NET Core 버전을 8.0으로 설정하려면 Cloud Shell에서 다음 명령을 실행합니다.
az webapp config set --name <app-name> --resource-group <resource-group-name> --linux-fx-version "DOTNETCORE|8.0"
App Service에서 오래된 런타임은 어떻게 되나요?
오래된 런타임은 유지 관리 조직에서 더 이상 사용되지 않거나 심각한 취약성이 있는 것으로 확인됩니다. 따라서 포털의 만들기 및 구성 페이지에서 제거됩니다. 오래된 런타임이 포털에서 숨겨지면 해당 런타임을 계속 사용하는 모든 앱이 계속 실행됩니다.
더 이상 포털에 표시되지 않는 오래된 런타임 버전으로 앱을 만들려면 Azure CLI, ARM 템플릿 또는 Bicep을 사용합니다. 이러한 배포 대안을 사용하면 포털에서 제거되었지만 여전히 지원되는 사용되지 않는 런타임을 만들 수 있습니다.
런타임이 App Service 플랫폼에서 완전히 제거된 경우 Azure 구독 소유자는 제거 전에 이메일 알림을 받습니다.
빌드 자동화 사용자 지정
빌드 자동화를 사용하도록 설정된 Git 또는 ZIP 패키지를 사용하여 앱을 배포하는 경우 App Service 빌드 자동화는 다음 순서를 따릅니다.
-
PRE_BUILD_SCRIPT_PATH에 지정된 경우 사용자 지정 스크립트를 실행합니다. - NuGet 종속성을 복원하려면
dotnet restore을 실행하십시오. - 프로덕션용 바이너리를 빌드하려면
dotnet publish를 실행합니다. -
POST_BUILD_SCRIPT_PATH에 지정된 경우 사용자 지정 스크립트를 실행합니다.
PRE_BUILD_COMMAND 및 POST_BUILD_COMMAND는 기본적으로 비어 있는 환경 변수입니다. 사전 빌드 명령을 실행하려면 .를 정의 PRE_BUILD_COMMAND합니다. 빌드 후 명령을 실행하려면 POST_BUILD_COMMAND를 정의합니다.
다음 예제에서는 일련의 명령에 대한 두 변수를 쉼표로 구분하여 지정합니다.
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"
빌드 자동화를 사용자 지정하는 데 사용할 수 있는 다른 환경 변수는 Oryx 구성을 참조하세요.
App Service가 Linux에서 ASP.NET Core 앱을 실행하고 빌드하는 방법에 대한 자세한 내용은 Oryx 설명서: .NET Core 앱이 검색되고 빌드되는 방법을 참조하세요.
환경 변수에 액세스
App Service에서 앱 코드 외부에서 앱 설정을 설정할 수 있습니다. 그런 다음, 표준 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");
}
}
}
App Service와 appsettings.json에서 동일한 이름의 앱 설정을 구성하는 경우, 예를 들어, App Service 값이 appsettings.json 값보다 우선합니다. 로컬 appsettings.json 값을 사용하여 로컬로 앱을 디버그할 수 있지만 App Service 값을 사용하여 프로덕션 설정으로 프로덕션 환경에서 앱을 실행할 수 있습니다. 연결 문자열은 동일한 방식으로 작동합니다. 이 방법을 사용하면 코드 리포지토리 외부에 애플리케이션 비밀을 유지하고 코드를 변경하지 않고 적절한 값에 액세스할 수 있습니다.
참고 항목
또한 연결 비밀이 필요하지 않은 보다 안전한 연결 옵션을 고려할 수 있습니다. 자세한 내용은 Azure App Service에서 Azure 서비스 및 데이터베이스에 대한 보안 연결을 참조하세요.
Linux에서 .NET Core로 표준인 (이중 밑줄) 구분 기호를 사용하여 계층적 구성 데이터에 appsettings.json 액세스합니다. App Service에서 특정 계층 구성 설정을 재정의하려면 키에서 동일하게 분리된 형식으로 앱 설정 이름을 설정합니다.
Cloud Shell에서 다음 예제를 실행할 수 있습니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My__Hierarchical__Config__Data="some value"
.NET Core에 대한 표준 구분 기호를 appsettings.json 사용하여 : 액세스합니다. App Service에서 특정 계층 구성 설정을 재정의하려면 키에서 동일하게 분리된 형식으로 앱 설정 이름을 설정합니다.
Azure Cloud Shell에서 다음 예제를 실행할 수 있습니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings My:Hierarchical:Config:Data="some value"
다중 프로젝트 솔루션 배포
Visual Studio 솔루션에 여러 프로젝트가 포함된 경우 Visual Studio 게시 프로세스는 배포할 프로젝트를 자동으로 선택합니다. Git과 같은 App Service 배포 엔진에 배포하거나 빌드 자동화를 사용하도록 설정된 ZIP 배포를 사용하는 경우 App Service 배포 엔진은 App Service 앱으로 찾은 첫 번째 웹 사이트 또는 웹 애플리케이션 프로젝트를 선택합니다.
PROJECT 앱 설정을 지정하여 App Service가 사용해야 하는 프로젝트를 지정할 수 있습니다. 예를 들어 Cloud Shell에서 다음 명령을 실행합니다.
az webapp config appsettings set --resource-group <resource-group-name> --name <app-name> --settings PROJECT="<project-name>/<project-name>.csproj"
진단 로그 액세스
ASP.NET Core는 App Service용 기본 제공 로깅 공급자를 제공합니다. 다음 예제와 같이 프로젝트 program.cs 파일에서 확장 메서드를 ConfigureLogging 통해 애플리케이션에 공급자를 추가합니다.
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureLogging(logging =>
{
logging.AddAzureWebAppDiagnostics();
})
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.UseStartup<Startup>();
});
그런 다음 표준 .NET Core 패턴을 사용하여 로그를 구성하고 생성할 수 있습니다.
App Service의 애플리케이션 코드 내에서 생성된 콘솔 로그에 액세스하려면 Cloud Shell에서 다음 명령을 실행하여 진단 로깅을 설정합니다.
az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose
가능한 값 --level 은 Error, Warning, Info및 Verbose. 각 후속 수준에는 이전 수준이 포함됩니다. 예를 들어 Error 오류 메시지만 포함합니다.
Verbose 에는 모든 메시지가 포함됩니다.
진단 로깅을 켠 후 다음 명령을 실행하여 로그 스트림을 확인합니다.
az webapp log tail --resource-group <resource-group-name> --name <app-name>
콘솔 로그가 즉시 나타나지 않으면 30초 후에 다시 확인합니다.
언제든지 로그 스트리밍을 중지하려면 Ctrl+를 선택합니다.
App Service의 ASP.NET Core 앱 문제 해결에 대한 자세한 내용은 Azure App Service 및 IIS에서 ASP.NET Core 문제 해결을 참조하세요.
자세한 예외 페이지에 액세스
ASP.NET Core 앱이 Visual Studio 디버거에서 예외를 생성하면 브라우저에 자세한 예외 페이지가 표시되지만 App Service에서 해당 페이지는 일반 "HTTP 500" 또는 "요청을 처리하는 동안 오류가 발생했습니다."로 바뀝니다. App Service에서 자세한 예외 페이지를 표시하려면 ASPNETCORE_ENVIRONMENT에서 다음 명령을 실행하여 앱에 앱 설정을 추가 합니다.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings ASPNETCORE_ENVIRONMENT="Development"
HTTPS 세션 검색
App Service에서 TLS/SSL 종료 는 네트워크 부하 분산 장치에서 발생하므로 모든 HTTPS 요청은 암호화되지 않은 HTTP 요청으로 앱에 도달합니다. 사용자 요청이 암호화되었는지 앱 논리가 알아야 하는 경우, Startup.cs에서 Forwarded Headers 미들웨어를 구성합니다.
-
ForwardedHeadersOptions를 사용하여X-Forwarded-For의X-Forwarded-Proto및Startup.ConfigureServices헤더를 전달하도록 미들웨어를 구성합니다. - 미들웨어가 App Service 부하 분산 장치를 신뢰할 수 있도록 개인 IP 주소 범위를 알려진 네트워크에 추가합니다.
- 다른 미들웨어를 호출하기 전에
UseForwardedHeaders의Startup.Configure메서드를 호출합니다.
세 요소를 어셈블할 때 코드는 다음 예제와 같습니다.
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();
}
자세한 내용은 프록시 서버 및 부하 분산 장치에서 작동하도록 ASP.NET Core 구성을 참조하세요.
URL 다시 쓰기 또는 리디렉션
URL을 다시 쓰거나 리디렉션하려면 ASP.NET Core에서 URL 재작성 미들웨어를 사용합니다.
브라우저에서 SSH 세션 열기
컨테이너를 사용하여 직접 SSH 세션을 열려면 앱이 실행 중이어야 합니다.
az webapp ssh 명령을 사용합니다.
아직 인증을 받지 못한 경우 연결하기 위해서는 Azure 구독에서 인증을 받아야 합니다. 인증되면 컨테이너 내부에서 명령을 실행할 수 있는 브라우저 내부 셸을 확인합니다.
참고 항목
디렉터리 외부에서 /home 변경한 내용은 컨테이너 자체에 저장되며 앱 다시 시작 후에도 유지되지 않습니다.
로컬 컴퓨터에서 원격 SSH 세션을 열려면 원격 셸에서 SSH 세션 열기를 참조하세요.
로그에서 robots933456 메시지 무시
컨테이너 로그에 다음 메시지가 표시될 수 있습니다.
2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"
이 메시지는 무시해도 괜찮습니다.
/robots933456.txt는 App Service에서 컨테이너가 요청을 처리할 수 있는지 확인하기 위해 사용하는 더미 URL 경로입니다. 404 응답은 경로가 존재하지 않음을 나타내며, 컨테이너가 정상이며 요청에 응답할 준비가 되었음을 App Service에 알릴 수 있습니다.