다음을 통해 공유


Azure App Service용 ASP.NET Core 앱 구성

참고 항목

.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 빠른 시작SQL Database를 사용한 ASP.NET Core 자습서를 먼저 따릅니다.

지원되는 .NET Core 런타임 버전 표시

App Service의 Windows 인스턴스에는 지원되는 모든 .NET Core 버전이 이미 설치되어 있습니다. 사용할 수 있는 .NET Core 런타임 및 SDK 버전을 표시하려면 https://<app-name>.scm.azurewebsites.net/DebugConsole로 이동한 다음 브라우저 기반 콘솔에서 다음 명령을 실행합니다.

dotnet --info

.NET Core 버전 표시

현재 .NET Core 버전을 표시하려면 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 버전 선택을 참조하세요.

Cloud Shell에서 다음 명령을 실행하여 .NET Core 버전을 8.0으로 설정합니다.

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

빌드 자동화 사용자 지정

참고 항목

MSBuild 또는 SCM_DO_BUILD 사용하여 Windows App Service를 사용하여 .NET 9(STS) 앱을 빌드하는 것은 아직 지원되지 않습니다. 이러한 빌드 시나리오에 대한 지원은 초기 GA 날짜 이후와 2024년 12월 4일까지 제공됩니다. Visual Studio, Visual Studio Code, GitHub Actions 및 Azure DevOps를 통해 App Service 외부에서 빌드되는 배포는 완전히 지원됩니다.

Git을 사용하여 앱을 배포하거나 빌드 자동화가 활성화된 압축 패키지를 배포하는 경우 App Service 빌드 자동화 단계는 다음 순서입니다.

  1. PRE_BUILD_SCRIPT_PATH에 지정된 경우 사용자 지정 스크립트를 실행합니다.
  2. dotnet restore를 실행하여 모든 NuGet 종속성을 복원합니다.
  3. dotnet publish를 실행하여 프로덕션용 이진 파일을 빌드합니다.
  4. POST_BUILD_SCRIPT_PATH에 지정된 경우 사용자 지정 스크립트를 실행합니다.

PRE_BUILD_COMMANDPOST_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 앱 Service에서 Azure 서비스 및 데이터베이스에 대한 보안 연결을 참조하세요.

참고 항목

appsettings.json계층적 구성 데이터는 Linux에서 .NET Core로의 표준인 __(이중 밑줄) 구분 기호를 사용하여 액세스합니다. 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에서 특정 계층 구성 설정을 재정의하려면 키에서 동일하게 분리된 형식으로 앱 설정 이름을 설정합니다. 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 또는 빌드 자동화가 활성화된 ZIP 배포와 같이 App Service 배포 엔진에 배포하는 경우 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, InfoVerbose입니다. 각 후속 수준에는 이전 수준이 포함됩니다. 예를 들어 Error에는 오류 메시지만 포함하고 Verbose에는 모든 메시지를 포함합니다.

진단 로깅이 설정되면 다음 명령을 실행하여 로그 스트림을 확인합니다.

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

콘솔 로그가 즉시 표시되지 않으면 30초 후에 다시 확인합니다.

참고 항목

https://<app-name>.scm.azurewebsites.net/api/logs/docker의 브라우저에서 로그 파일을 검사할 수도 있습니다.

언제든지 로그 스트리밍을 중지하려면 Ctrl+C를 입력합니다.

App Service에서 ASP.NET Core 앱 문제를 해결하는 방법에 대한 자세한 내용은 Azure App Service 및 IIS의 ASP.NET Core 문제 해결을 참조하세요.

자세한 예외 페이지 가져오기

ASP.NET Core 앱이 Visual Studio 디버거에서 예외를 생성하면 브라우저에 자세한 예외 페이지가 표시되지만 App Service에서는 해당 페이지가 일반 HTTP 500으로 대체되거나 요청을 처리하는 동안 오류가 발생했습니다. App Service에서 자세한 예외 페이지를 표시하려면 Cloud Shell에서 다음 명령을 실행하여 앱에 앱 설정을 추가 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에서 전달된 헤더 미들웨어를 구성합니다.

  • Startup.ConfigureServices에서 X-Forwarded-ForX-Forwarded-Proto 헤더를 전달하도록 ForwardedHeadersOptions를 사용하여 미들웨어를 구성합니다.
  • 미들웨어가 App Service 부하 분산 장치를 신뢰할 수 있도록 개인 IP 주소 범위를 알려진 네트워크에 추가합니다.
  • 다른 미들웨어를 호출하기 전에 Startup.Configure에서 UseForwardedHeaders 메서드를 호출합니다.

세 요소를 모두 함께 배치하면 코드는 다음 예제와 같습니다.

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 세션을 열려면 앱을 실행해야 합니다.

브라우저에 다음 URL을 붙여넣고 <app-name>을 앱 이름으로 바꿉니다.

https://<app-name>.scm.azurewebsites.net/webssh/host

아직 인증을 받지 못한 경우 연결하기 위해서는 Azure 구독에서 인증을 받아야 합니다. 인증되면 컨테이너 내부에서 명령을 실행할 수 있는 브라우저 내부 셸을 확인합니다.

SSH 연결

참고 항목

/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에 알려줍니다.

다음 단계

또는 더 많은 리소스를 참조하세요.

환경 변수 및 앱 설정 참조