다음을 통해 공유

Azure Container Apps의 .NET 개요

  • 아티클

Azure Container Apps와 같은 클라우드 네이티브 환경에 .NET 애플리케이션을 배포하려면 애플리케이션이 원활하고 안전하게 실행되도록 하기 위해 결정해야 할 사항이 있습니다. 이 가이드에서는 .NET 애플리케이션을 Azure Container Apps에 배포하는 것과 관련된 주요 개념을 다룹니다.

Azure Container Apps는 기본 인프라를 관리할 필요 없이 컨테이너화된 애플리케이션을 실행할 수 있도록 하는 완전 관리형 서버리스 컨테이너 서비스입니다. Container Apps에는 자동 크기 조정, 상태 검사, TLS(전송 계층 보안) 인증서를 포함한 기능에 대한 기본 지원이 포함되어 있습니다.

이 문서에서는 Azure Container Apps에 .NET 애플리케이션을 배포할 때 중요한 개념과 고려 사항을 자세히 설명합니다.

리소스 종류 선택

Container Apps는 앱과 작업이라는 두 가지 형식의 리소스를 지원합니다. 앱은 지속적으로 서비스를 실행하는 반면, 작업은 완료될 때까지 실행되도록 설계된 단기 작업입니다.

앱 배포를 준비할 때 두 애플리케이션 형식의 동작이 .NET 애플리케이션 관리 방법에 영향을 미치므로 이러한 애플리케이션 형식 간의 차이점을 고려합니다. 다음 표에서는 작업 간의 사용 사례 차이를 설명합니다.

사용 사례 리소스 종류
HTTP 요청을 처리하는 ASP.NET Core 웹 API App
일부 데이터를 처리한 후 종료되는 .NET Core 콘솔 애플리케이션 작업
큐의 메시지를 처리하는 지속적으로 실행되는 백그라운드 서비스 App
대용량 이미지가 스토리지 계정에 저장된 경우에만 실행되는 이미지 최적화 서비스. 작업
Hangfire, Quartz.NET 또는 Azure WebJobs SDK와 같은 프레임워크를 사용하는 애플리케이션 App

.NET 애플리케이션 컨테이너화 및 배포

앱 또는 작업에 대해 .NET 애플리케이션을 패키지하려면 컨테이너 이미지를 빌드해야 합니다. 컨테이너 이미지 빌드에 대한 자세한 내용은 ASP.NET Core의 Docker 이미지를 참조하세요.

설정한 후에는 다음 가이드에 따라 애플리케이션을 Azure Container Apps에 배포할 수 있습니다.

HTTP 수신 사용

Azure Container Apps에는 컨테이너 외부에서 들어오는 트래픽에 앱을 노출할 수 있는 기본 제공 HTTP 수신이 포함되어 있습니다. Container Apps 수신은 앱과 최종 사용자 사이에 위치합니다. 수신은 매개자 역할을 하기 때문에 최종 사용자가 보는 모든 것은 수신에서 끝나고, 앱에서 보는 모든 것은 수신에서 시작됩니다.

수신은 TLS 종료 및 사용자 지정 도메인을 관리하므로 앱에서 이를 수동으로 구성할 필요가 없습니다. 수신을 통해 HTTPS 트래픽용으로 포트 443이 노출되고 선택적으로 HTTP 트래픽용으로 포트 80이 노출됩니다. 수신은 대상 포트에서 앱으로 요청을 전달합니다.

앱에 원래 요청에 대한 메타데이터가 필요한 경우 X-전달 헤더를 사용할 수 있습니다.

자세한 내용은 Azure Container Apps의 HTTP 수신을 참조하세요.

대상 포트 정의

트래픽을 수신하기 위해 앱이 트래픽을 수신 대기하는 대상 포트에 수신이 구성됩니다.

ASP.NET Core가 컨테이너에서 실행 중인 경우 애플리케이션은 컨테이너 이미지에 구성된 대로 포트를 수신 대기합니다. 공식 ASP.NET Core 이미지를 사용하면 앱이 기본 포트에서 HTTP를 수신 대기하도록 구성됩니다. 기본 포트는 ASP.NET Core 버전에 따라 다릅니다.

런타임 대상 포트
ASP.NET Core 7 이하 80
ASP.NET Core 8 이상 8080

수신을 구성할 때 대상 포트를 사용 중인 컨테이너 이미지에 해당하는 번호로 설정합니다.

X 전달 헤더 정의

수신이 원래 HTTP 요청을 처리할 때 앱은 수신을 클라이언트로 간주합니다. 앱이 원래 클라이언트의 IP 주소나 원래 프로토콜(HTTP 또는 HTTPS)을 알아야 하는 상황이 있습니다. 요청의 X-Forwarded-* 헤더를 통해 프로토콜 및 IP 정보에 액세스할 수 있습니다.

ForwardedHeaders 개체에 액세스하여 이러한 헤더에서 원래 값을 읽을 수 있습니다.

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

요청 헤더 작업에 대한 자세한 내용은 프록시 서버 및 부하 분산 장치와 작동하도록 ASP.NET Core 구성을 참조하세요.

클라우드 네이티브 .NET 애플리케이션 빌드

Container Apps에 배포된 애플리케이션은 클라우드 네이티브 원칙을 기반으로 빌드할 때 가장 잘 작동하는 경우가 많습니다. 다음 섹션에서는 클라우드 네이티브 애플리케이션과 관련된 일반적인 문제를 자세히 설명합니다.

애플리케이션 구성

.NET 애플리케이션을 Azure Container Apps에 배포할 때 appsettings.json을 사용하는 대신 구성 정보를 저장하기 위한 환경 변수를 사용합니다. 이 방법을 사용하면 다양한 환경에서 다양한 방식으로 애플리케이션을 구성할 수 있습니다. 또한 환경 변수를 사용하면 컨테이너 이미지를 다시 빌드하고 다시 배포할 필요 없이 구성 값을 더 쉽게 관리할 수 있습니다.

Azure Container Apps에서는 앱이나 작업의 컨테이너를 정의할 때 환경 변수를 설정합니다. 중요한 값을 비밀에 저장하고 환경 변수로 참조하세요. 비밀 관리에 대해 자세히 알아보려면 Azure Container Apps에서 비밀 관리를 참조하세요.

관리 ID

Azure Container Apps는 자격 증명을 교환할 필요 없이 앱이 다른 Azure 서비스에 액세스할 수 있도록 하는 관리 ID를 지원합니다. Azure 서비스 간 안전한 통신에 대해 자세히 알아보려면 Azure Container Apps의 관리 ID를 참조하세요.

로깅

클라우드 네이티브 환경에서 로깅은 애플리케이션을 모니터링하고 문제를 해결하는 데 중요합니다. 기본적으로 Azure Container Apps는 Azure Log Analytics를 사용하여 컨테이너에서 로그를 수집합니다. 다른 로깅 공급자를 구성할 수 있습니다. 애플리케이션 로깅에 대해 자세히 알아보려면 Azure Container Apps의 로그 스토리지 및 모니터링 옵션을 참조하세요.

콘솔에 로그를 로깅하는 로깅 공급자를 구성하면 Azure Container Apps가 로그 메시지를 수집하고 저장합니다.

상태 프로브

Azure Container Apps에는 애플리케이션의 상태를 모니터링할 수 있는 상태 프로브에 대한 기본 지원이 포함되어 있습니다. 프로브가 애플리케이션이 비정상 상태에 있다고 판단하면 컨테이너가 자동으로 다시 시작됩니다. 상태 프로브에 대해 자세히 알아보려면 Azure Container Apps의 상태 프로브를 참조하세요.

애플리케이션의 상태를 확인하기 위해 사용자 지정 논리를 구현하려면 상태 검사 엔드포인트를 구성하면 됩니다. 상태 검사 엔드포인트에 대해 자세히 알아보려면 ASP.NET Core의 상태 검사를 참조하세요.

자동 크기 조정 고려 사항

기본적으로 Azure Container Apps는 들어오는 HTTP 요청 수에 따라 ASP.NET Core 앱의 크기를 자동으로 조정합니다. CPU 또는 메모리 사용량과 같은 다른 메트릭을 기반으로 사용자 지정 자동 크기 조정 규칙을 구성할 수도 있습니다. 크기 조정에 대해 자세히 알아보려면 Azure Container Apps에서 크기 조정 규칙 설정을 참조하세요.

.NET 8.0.4 이상에서는 데이터 보호를 사용하는 ASP.NET Core 앱은 애플리케이션이 확장될 때 모든 복제본에서 보호된 데이터에 액세스할 수 있도록 자동으로 구성됩니다. 앱의 크기 조정이 시작되면 키 관리자는 여러 수정 버전에서 쓰기 및 공유 키를 처리합니다. 앱이 배포되면 autoConfigureDataProtection 환경 변수가 이 기능을 사용하도록 true을(를) 자동으로 설정합니다. 이 자동 구성에 대한 자세한 내용은 이 GitHub 끌어오기 요청을 참조하세요.

자동 크기 조정은 정의한 규칙에 따라 앱의 복제본 수를 변경합니다. 기본적으로 Container Apps는 들어오는 트래픽을 ASP.NET Core 앱의 복제본으로 임의로 라우팅합니다. 트래픽이 여러 복제본으로 분할될 수 있으므로 앱은 상태 비저장이어야 애플리케이션에서 상태 관련 문제가 발생하지 않습니다.

위조 방지, 인증, SignalR, Blazor Server 및 Razor Pages와 같은 기능은 데이터 보호에 따라 다르며 여러 복제본으로 크기 조정할 때 올바르게 작동하려면 추가 구성이 필요합니다.

데이터 보호 구성

ASP.NET Core에는 세션 데이터 및 위조 방지 토큰과 같은 데이터를 보호하고 보호 해제하는 특수 기능이 있습니다. 기본적으로 데이터 보호 키는 파일 시스템에 저장되므로 클라우드 네이티브 환경에 적합하지 않습니다.

.NET Aspire 애플리케이션을 배포하는 경우 데이터 보호가 자동으로 구성됩니다. 다른 모든 상황에서는 데이터 보호를 수동으로 구성해야 합니다.

ASP.NET Core SignalR 구성

ASP.NET Core SignalR에는 메시지를 여러 서버 복제본에 배포하기 위한 백플레인이 필요합니다. SignalR을 사용하여 ASP.NET Core 앱을 Azure Container Apps에 배포하는 경우 Azure SignalR Service 또는 Redis와 같은 지원되는 백플레인 중 하나를 구성해야 합니다. 백플레인에 대해 자세히 알아보려면 ASP.NET Core SignalR 호스팅 및 크기 조정을 참조하세요.

Blazor Server 구성

ASP.NET Core Blazor Server 앱은 상태를 서버에 저장합니다. 즉, 각 클라이언트는 세션 중에 동일한 서버 복제본에 연결되어야 합니다. Blazor Server 앱을 Azure Container Apps에 배포할 때 클라이언트가 동일한 복제본으로 라우팅되도록 고정 세션을 사용하도록 설정해야 합니다. 자세한 내용은 Azure Container Apps의 세션 선호도를 참조하세요.