다음을 통해 공유


Visual Studio에서 Docker 컨테이너 사용자 지정하기

프로젝트에 Docker 지원을 추가할 때 Visual Studio에서 생성하는 Dockerfile을 편집하여 컨테이너 이미지를 사용자 지정할 수 있습니다. Visual Studio IDE에서 사용자 지정 컨테이너를 빌드하거나 명령줄 빌드를 설정하는 경우, Visual Studio에서 Dockerfile을 사용하여 프로젝트를 빌드하는 방법을 알고 있어야 합니다. 성능상의 이유로 Visual Studio는 Dockerfile에서 명확하지 않은 컨테이너화된 앱을 빌드하고 실행하기 위한 특별한 프로세스를 따르기 때문에 이러한 세부 정보를 알아야 합니다.

Dockerfile을 변경하고 디버깅 및 프로덕션 컨테이너 모두에서 결과를 확인하려는 경우를 가정해 보겠습니다. 이 경우 Dockerfile에서 명령을 추가하여 첫 번째 단계(일반적으로 base)를 수정할 수 있습니다. 디버깅 및 프로덕션에 대한 컨테이너 이미지 수정을 참조하세요. 그러나 프로덕션이 아닌 디버깅할 때만 변경하려면 다른 단계를 만들고 DockerfileFastModeStage 빌드 설정을 사용하여 Visual Studio에서 디버그 빌드에 해당 단계를 사용하도록 지시해야 합니다. 디버깅에 대해서만 컨테이너 이미지 수정을 참조하세요.

이 문서에서는 컨테이너화된 앱에 대한 Visual Studio 빌드 프로세스를 자세히 설명한 다음, 디버깅 및 프로덕션 빌드 모두에 영향을 주도록 Dockerfile을 수정하거나 디버깅에만 영향을 미치는 방법에 대한 정보를 포함합니다.

Visual Studio에서 도커파일 빌드하기

참고 항목

이 섹션에서는 Dockerfile 컨테이너 빌드 유형을 선택할 때 Visual Studio에서 사용하는 컨테이너 빌드 프로세스에 대해 설명합니다. .NET SDK 빌드 유형을 사용하는 경우 사용자 지정 옵션이 다르며 이 섹션의 정보는 적용되지 않습니다. 대신 닷넷 게시를 사용하여 .NET 앱 컨테이너화하기를 참조하고 컨테이너 사용자 지정하기에 설명된 속성을 사용하여 컨테이너 빌드 프로세스를 구성하세요.

다단계 빌드

Visual Studio는 Docker 컨테이너를 사용하지 않는 프로젝트를 빌드할 때, 로컬 컴퓨터에서 MSBuild를 호출하고 로컬 솔루션 폴더 아래에 있는 폴더(일반적으로 bin)에 출력 파일을 생성합니다. 그러나 컨테이너화된 프로젝트의 경우 빌드 프로세스에서 컨테이너화된 앱 빌드에 대한 Dockerfile의 지침을 고려합니다. Visual Studio에서 사용하는 Dockerfile은 여러 스테이지로 나누어져 있습니다. 이 프로세스는 Docker의 ‘다단계 빌드’ 기능을 사용합니다.

다단계 빌드 기능을 사용하면 컨테이너 빌드 프로세스를 보다 효율적으로 수행할 수 있으며, 앱이 런타임에 필요로 하는 비트만 포함하여 컨테이너를 더 작게 만들 수 있습니다. 다단계 빌드는 .NET Framework 프로젝트가 아닌 .NET Core 프로젝트에 사용됩니다.

다단계 빌드를 사용하면 중간 이미지를 생성하는 스테이지에서 컨테이너 이미지를 만들 수 있습니다. 예를 들어 일반적인 Dockerfile을 고려합니다. 도구에는 해당 이름이 필요하지는 않지만 첫 번째 단계는 Visual Studio가 생성하는 Dockerfile에서 base를 호출합니다.

# This stage is used when running from VS in fast mode (Default for Debug configuration)
FROM mcr.microsoft.com/dotnet/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

Dockerfile의 줄은 Microsoft Container Registry(mcr.microsoft.com)의 ASP.NET 이미지로 시작하며 포트 80 및 443을 공개하는 중간 이미지 base를 만든 다음, 작업 디렉터리를 /app으로 설정합니다.

다음 스테이지는 build이며 다음과 같이 표시됩니다.

# This stage is used to build the service project
FROM mcr.microsoft.com/dotnet/sdk:3.1-buster-slim AS build
WORKDIR /src
COPY ["WebApplication43/WebApplication43.csproj", "WebApplication43/"]
RUN dotnet restore "WebApplication43/WebApplication43.csproj"
COPY . .
WORKDIR "/src/WebApplication43"
RUN dotnet build "WebApplication43.csproj" -c Release -o /app/build

build 스테이지는 base에서 계속되는 것이 아니라 레지스트리의 다른 원본 이미지(aspnet 대신 sdk)에서 시작되는 것을 확인할 수 있습니다. sdk 이미지에는 모든 빌드 도구가 포함되어 있으므로, 런타임 구성 요소만 포함하는 aspnet 이미지보다 훨씬 더 큽니다. Dockerfile의 나머지 부분을 살펴보면 개별 이미지를 사용해야 하는 이유가 명확해집니다.

# This stage is used to publish the service project to be copied to the final stage
FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish

# This stage is used in production or when running from VS in regular mode (Default when not using the Debug configuration)
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication43.dll"]

최종 스테이지는 다시 base에서 시작되며, 게시된 출력을 최종 이미지에 복사하는 COPY --from=publish를 포함합니다. 이 프로세스를 사용하면 sdk 이미지에 있던 모든 빌드 도구를 포함할 필요가 없으므로 최종 이미지가 훨씬 더 작아질 수 있습니다.

다음 표에는 Visual Studio에서 만든 일반적인 Dockerfile에 사용되는 단계가 요약되어 있습니다.

단계 설명
base 빌드된 앱이 게시되는 기본 런타임 이미지를 만듭니다. 런타임에 사용할 수 있어야 하는 설정(예: 포트 및 환경 변수)으로 이동합니다. 이 단계는 VS에서 빠른 모드로 실행할 때 사용됩니다(디버그 구성의 경우 기본값).
build 프로젝트는 이 단계에서 빌드됩니다. 프로젝트 빌드에 필요한 구성 요소가 포함된 .NET SDK 기본 이미지가 사용됩니다.
publish 이 단계는 빌드 단계에서 파생되어 프로젝트를 게시하며 최종 단계로 복사됩니다.
final 이 단계는 앱을 시작하는 방법을 구성하며 프로덕션 또는 일반 모드에서 VS에서 실행할 때 사용됩니다(디버그 구성을 사용하지 않는 경우 기본값).
aotdebug 이 단계는 일반 모드에서 디버깅을 지원하기 위해 VS에서 실행할 때 최종 단계의 기본으로 사용됩니다(디버그 구성을 사용하지 않을 때는 기본값).

참고 항목

aotdebug 단계는 Linux 컨테이너에 대해서만 지원됩니다. 프로젝트에서 네이티브 AOT(Ahead Of Time) 배포를 사용하는 경우 Visual Studio 2022 17.11 이상에서 사용됩니다.

프로젝트 준비

프로젝트 준비는 후속 실행의 성능을 향상하기 위해 프로젝트에 대해 Docker 프로필이 선택될 때(즉 프로젝트가 로드되거나 Docker 지원이 추가될 때) 발생하는 일련의 단계를 의미합니다(F5 또는 Ctrl+F5). >>이 동작은 도구옵션컨테이너 도구에서 구성할 수 있습니다. 다음은 백그라운드에서 실행되는 작업입니다.

  • Docker Desktop이 설치되어 실행 중인지 확인합니다.
  • Docker Desktop이 프로젝트와 동일한 운영 체제로 설정되어 있는지 확인합니다.
  • Dockerfile의 첫 번째 스테이지(대부분 Dockerfile의 base 스테이지)에서 이미지를 풀합니다.
  • Dockerfile을 빌드하고 컨테이너를 시작합니다.

워밍업은 Fast 모드에서만 수행되므로 실행 중인 컨테이너에는 app 폴더 볼륨이 마운트되어 있습니다. 즉, 앱이 변경되더라도 컨테이너가 무효화되지 않습니다. 이 동작은 디버깅 성능을 크게 개선하고 대용량 이미지 가져오기와 같이 오래 실행되는 작업의 대기 시간을 줄여줍니다.

자세한 컨테이너 도구 로그 사용

진단 목적으로 특정 컨테이너 도구 로그를 활성화할 수 있습니다. 특정 환경 변수를 설정하여 이러한 로그를 활성화할 수 있습니다. 단일 컨테이너 프로젝트의 경우 환경 변수는 MS_VS_CONTAINERS_TOOLS_LOGGING_ENABLED이며 %tmp%\Microsoft.VisualStudio.Containers.Tools에 로그됩니다. MS_VS_DOCKER_TOOLS_LOGGING_ENABLED%tmp%\Microsoft.VisualStudio.DockerCompose.Tools도커 컴포즈 프로젝트의 경우 , 그 다음에는 로 로그인합니다.

Warning

로깅을 사용하도록 설정하고 Azure 인증에 토큰 프록시를 사용하는 경우 인증 자격 증명이 일반 텍스트로 기록될 수 있습니다. Azure 인증 구성를 참조하세요

다음 단계

Dockerfile 단계를 사용하여 디버깅 및 프로덕션에 사용되는 이미지를 사용자 지정하는 방법(예: 디버깅할 때만 이미지에 도구를 설치하는 방법)에 대해 알아봅니다. 디버깅을 위한 컨테이너 이미지 구성을 참조하세요.