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

아티클
03/15/2024

프로젝트에 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를 호출합니다.

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이며 다음과 같이 표시됩니다.

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의 나머지 부분을 살펴보면 개별 이미지를 사용해야 하는 이유가 명확해집니다.

FROM build AS publish
RUN dotnet publish "WebApplication43.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication43.dll"]

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

MSBuild

참고 항목

이 섹션에서는 Docker파일 컨테이너 빌드 유형을 선택할 때 Docker 컨테이너를 사용자 지정하는 방법에 대해 설명합니다. .NET SDK 빌드 유형을 사용하는 경우 사용자 지정 옵션이 다르며 이 문서의 정보는 적용되지 않습니다. 대신 닷넷 게시를 사용하여 .NET 앱 컨테이너화를 참조하세요.

Visual Studio에서 만든 .NET Framework 프로젝트용(및 Visual Studio 2017 업데이트 4 이전 버전으로 만든 .NET Core 프로젝트용) Docker파일은 멀티스테이지 Docker파일이 아닙니다. 이러한 도커파일의 단계는 코드를 컴파일하지 않습니다. 대신, Visual Studio에서 .NET Framework Dockerfile을 빌드할 때 먼저 MSBuild를 사용하여 프로젝트를 컴파일합니다. 작업이 성공하면 Visual Studio에서 Dockerfile을 빌드합니다. 이 프로세스에서는 MSBuild의 빌드 출력을 결과 Docker 이미지에 복사하기만 합니다. 코드를 컴파일하는 단계가 Dockerfile에 포함되지 않기 때문에, 명령줄에서 docker build를 사용하여 .NET Framework Dockerfile을 빌드할 수 없습니다. 이러한 프로젝트를 빌드하려면 MSBuild를 사용해야 합니다.

단일 Docker 컨테이너 프로젝트의 이미지를 빌드하려면 /t:ContainerBuild 명령 옵션으로 MSBuild를 사용할 수 있습니다. ContainerBuildBuild이 명령은 기본 대상 가 아닌 대상 을 빌드하도록 MSBuild에 지시합니다. 예시:

MSBuild MyProject.csproj /t:ContainerBuild /p:Configuration=Release

Visual Studio IDE에서 솔루션을 빌드할 때 Output 창에 표시되는 것과 유사한 출력이 표시됩니다. Visual Studio에서 다단계 빌드 최적화 기능을 사용하는 경우 디버그 구성을 빌드할 때 결과가 예상과 다를 수 있으므로 항상 /p:Configuration=Release를 사용합니다. 디버깅을 참조하세요.

Docker Compose 프로젝트를 사용하는 경우 이 명령을 사용하여 이미지를 빌드하세요.

msbuild /p:SolutionPath=<solution-name>.sln /p:Configuration=Release docker-compose.dcproj

디버깅

참고 항목

이 섹션에서는 Docker파일 컨테이너 빌드 유형을 선택할 때 Docker 컨테이너를 사용자 지정하는 방법에 대해 설명합니다. NET SDK 빌드 유형을 사용하는 경우 사용자 지정 옵션이 다르며 이 섹션의 대부분의 정보는 적용되지 않습니다. 대신 닷넷 게시를 사용하여 .NET 앱 컨테이너화를 참조하세요.

Debug 구성으로 빌드할 때 컨테이너화된 프로젝트의 빌드 프로세스 성능에 도움이 되는 몇 가지 최적화가 Visual Studio에서 수행됩니다. 컨테이너화된 앱의 빌드 프로세스는 단순히 Docker파일에 설명된 단계를 따르는 것만큼 간단하지 않습니다. 컨테이너에서 빌드하는 것은 로컬 머신에서 빌드하는 것보다 속도가 느립니다. 따라서 디버그 구성으로 빌드하는 경우, Visual Studio는 실제로 로컬 컴퓨터에서 프로젝트를 빌드한 다음, 볼륨 탑재를 사용하여 출력 폴더를 컨테이너에 공유합니다. 이 최적화 기능을 사용하는 빌드를 ‘고속’ 모드 빌드라고 합니다.

docker buildbaseFast 모드에서 Visual Studio는 Docker파일의 첫 번째 단계(일반적으로 단계)만 빌드하도록 지시하는 인수를 사용하여 을 호출합니다. DockerfileFastModeStage컨테이너 도구 MSBuild 속성에 설명된 MSBuild 속성인 을 설정하여 이를 변경할 수 있습니다. Visual Studio는 Dockerfile의 내용에 관계없이 프로세스의 나머지 부분을 처리합니다. 따라서 컨테이너 환경을 사용자 지정하거나 추가 종속성을 설치하기 위해 Dockerfile을 수정하는 경우, 수정 내용을 첫 번째 스테이지에 배치해야 합니다. buildpublishfinal도커파일의 , 또는 단계에 배치된 모든 사용자 지정 단계는 실행되지 않습니다.

이 성능 최적화 기능은 디버그 구성으로 빌드하는 경우에만 수행됩니다. 릴리스 구성에서는 Dockerfile에 지정된 대로 컨테이너에서 빌드가 수행됩니다.

성능 최적화 기능을 사용하지 않고 Dockerfile에 지정된 대로 빌드하려면, 프로젝트 파일에서 다음과 같이 ContainerDevelopmentMode 속성을 Regular로 설정합니다.

<PropertyGroup>
   <ContainerDevelopmentMode>Regular</ContainerDevelopmentMode>
</PropertyGroup>

성능 최적화 기능을 복원하려면 프로젝트 파일에서 해당 속성을 제거합니다.

디버깅을 시작하면(F5) 이전에 시작한 컨테이너가 재사용됩니다(가능한 경우). 이전 컨테이너를 재사용하지 않으려는 경우, Visual Studio의 다시 빌드 또는 정리 명령을 사용하여 Visual Studio에서 새 컨테이너를 사용하도록 강제로 적용할 수 있습니다.

디버거를 실행하는 프로세스는 프로젝트 및 컨테이너 운영 체제의 형식에 따라 달라집니다.

시나리오	디버거 프로세스
.NET Core 앱(Linux 컨테이너)	Visual Studio는 `vsdbg`를 다운로드하여 컨테이너에 매핑한 다음, 프로그램 및 인수(`dotnet webapp.dll`)를 사용하여 호출합니다. 그러면 디버거가 프로세스에 연결됩니다.
.NET Core 앱(Windows 컨테이너)	Visual Studio는 `onecoremsvsmon`을 사용하여 컨테이너에 매핑하고 진입점으로 실행한 다음, Visual Studio에서 연결하여 프로그램에 연결합니다. 이는 일반적으로 다른 컴퓨터 또는 가상 머신에서 원격 디버깅을 설정하는 방법과 비슷합니다.
.NET Framework 앱	Visual Studio는 `msvsmon`을 사용하여 컨테이너에 매핑하고, Visual Studio가 연결할 수 있는 진입점으로 실행하여 프로그램에 연결합니다.

vsdbg.exe에 대한 자세한 정보는 Visual Studio의 Linux 및 OS X에서 .NET Core의 오프로드 디버깅을 참조하세요.

디버깅 및 프로덕션에 대한 컨테이너 이미지 수정

디버깅 및 프로덕션 모두에 대한 컨테이너 이미지를 수정하려면 base 단계를 수정합니다. 기본 단계 섹션(일반적으로 Dockerfile의 첫 번째 섹션)의 Dockerfile에 사용자 지정을 추가합니다. Dockerfile 명령에 대한 자세한 내용은 Docker 설명서의 Dockerfile 참조를 참조하세요.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
# <add your commands here>

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["WebApplication3/WebApplication3.csproj", "WebApplication3/"]
RUN dotnet restore "WebApplication3/WebApplication3.csproj"
COPY . .
WORKDIR "/src/WebApplication3"
RUN dotnet build "WebApplication3.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication3.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

디버깅에 대해서만 컨테이너 이미지 수정

이 시나리오는 진단 목적으로 무언가를 설치하는 것과 같이 디버깅 프로세스에 도움이 되도록 컨테이너를 사용하여 작업을 수행하려고 하지만 프로덕션 빌드에 설치하지 않으려는 경우에 적용됩니다.

디버깅에 대해서만 컨테이너를 수정하려면 단계를 만든 다음, MSBuild 속성 DockerfileFastModeStage를 사용하여 디버깅할 때 Visual Studio에 사용자 지정된 단계를 사용하도록 지시합니다. Dockerfile 명령에 대한 자세한 내용은 Docker 설명서의 Dockerfile 참조를 참조하세요.

다음 예제에서는 procps-ng 패키지를 설치하지만 디버그 모드에서만 설치합니다. pidof이 패키지는 Visual Studio에 필요하지만 여기에 사용된 Mariner 이미지에는 없는 명령 을 제공합니다. 빠른 모드 디버깅에 사용하는 단계는 여기에 정의된 사용자 지정 단계인 debug입니다. buildpublishbase빠른 모드 스테이지는 이 문서의 앞부분에서 설명한 대로 Visual Studio가 앱 실행에 필요한 모든 것을 포함하는 볼륨을 마운트하기 때문에 또는 스테이지에서 상속할 필요가 없으며 스테이지에서 직접 상속할 수 있습니다.

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:6.0-cbl-mariner2.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM base AS debug
RUN tdnf install procps-ng -y

FROM mcr.microsoft.com/dotnet/sdk:6.0-cbl-mariner2.0 AS build
WORKDIR /src
COPY ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
RUN dotnet restore "WebApplication1/WebApplication1.csproj"
COPY . .
WORKDIR "/src/WebApplication1"
RUN dotnet build "WebApplication1.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "WebApplication1.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "WebApplication1.dll"]

프로젝트 파일에서 이 설정을 추가하여 디버깅할 때 사용자 지정 단계 debug를 사용하도록 Visual Studio에 지시합니다.

  <PropertyGroup>
     <!-- other property settings -->
     <DockerfileFastModeStage>debug</DockerfileFastModeStage>
  </PropertyGroup>

다음 섹션에는 다른 진입점을 지정하려는 경우 또는 앱이 SSL을 지원하며 SSL 인증서 처리 방식에 영향을 줄 수 있는 사항을 변경하는 경우와 같은 특정 경우에 유용할 수 있는 정보가 포함되어 있습니다.

명령줄에서 빌드

docker buildMSBuilddotnet builddotnet publishVisual Studio 외부에서 Docker파일을 사용하여 컨테이너 프로젝트를 빌드하려는 경우 , , 또는 를 사용하여 명령줄에서 빌드할 수 있습니다.

docker buildMSBuilddotnet builddotnet publish.NET SDK 빌드 유형을 사용하는 경우 Docker파일이 없으므로 을 사용할 수 없으며, 대신 , 또는 를 사용하여 명령줄에서 빌드합니다.

Docker 빌드 사용

명령줄에서 컨테이너화된 솔루션을 빌드하려는 경우, 일반적으로 솔루션의 각 프로젝트에 대해 docker build <context> 명령을 사용할 수 있습니다. ‘빌드컨텍스트’ 인수를 제공합니다. Dockerfile의 ‘빌드 컨텍스트’는 이미지를 생성하기 위한 작업 폴더로 사용되는 로컬 컴퓨터의 폴더입니다. 예를 들어 컨테이너에 복사할 때, 복사할 파일이 들어 있는 폴더입니다. .NET Core 프로젝트에서는 솔루션 파일(.sln)이 포함된 폴더를 사용합니다. 이 인수는 상대 경로로 표시되며, 일반적으로 프로젝트 폴더의 Dockerfile과 부모 폴더의 솔루션 파일은 “..”으로 지정됩니다. .NET Framework 프로젝트의 빌드 컨텍스트는 솔루션 폴더가 아닌 프로젝트 폴더입니다.

docker build -f Dockerfile ..

프로젝트 준비

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

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

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

볼륨 매핑

컨테이너에서 디버깅이 작동하기 위해 Visual Studio에서는 볼륨 매핑을 사용하여 호스트 머신의 디버거 및 NuGet 폴더를 매핑합니다. 볼륨 매핑은 여기 Docker 설명서에 설명되어 있습니다. Visual Studio의 컨테이너 창을 사용하여 컨테이너에 대한 볼륨 매핑을 볼 수 있습니다.

컨테이너에 탑재된 볼륨은 다음과 같습니다.

볼륨	설명
앱 폴더	Dockerfile이 있는 프로젝트 폴더를 포함합니다.
NuGet 패키지 폴더	프로젝트의 obj{project}.csproj.nuget.g.props 파일에서 읽은 NuGet 패키지와 폴백 폴더를 포함합니다.
원격 디버거	프로젝트 형식에 따라 컨테이너에서 디버거를 실행하는 데 필요한 비트를 포함합니다. 디버깅 섹션을 참조하세요.
소스 폴더	Docker 명령에 전달되는 빌드 컨텍스트를 포함합니다.

컨테이너에 마운트된 볼륨은 다음과 같습니다. 컨테이너에 표시되는 내용은 사용 중인 Visual Studio 2022의 부 버전에 따라 다를 수 있습니다.

볼륨	설명
앱 폴더	Dockerfile이 있는 프로젝트 폴더를 포함합니다.
HotReloadAgent	핫 리로드 에이전트 파일을 포함합니다.
HotReloadProxy	호스트 리로드 에이전트가 호스트의 Visual Studio와 통신할 수 있도록 하는 서비스를 실행하는 데 필요한 파일이 들어 있습니다.
NuGet 패키지 폴더	프로젝트의 obj{project}.csproj.nuget.g.props 파일에서 읽은 NuGet 패키지와 폴백 폴더를 포함합니다.
원격 디버거	프로젝트 형식에 따라 컨테이너에서 디버거를 실행하는 데 필요한 비트를 포함합니다. 자세한 내용은 디버깅 섹션에서 설명합니다.
소스 폴더	Docker 명령에 전달되는 빌드 컨텍스트를 포함합니다.
TokenService.Proxy	서비스를 실행하는 데 필요한 파일을 포함하며, VisualStudioCredential이 호스트의 Visual Studio와 통신할 수 있도록 합니다.

.NET 8의 경우 루트 및 앱 사용자에 대한 추가 마운트 지점에 사용자 비밀 및 HTTPS 인증서가 포함될 수도 있습니다. Visual Studio 17.10 미리 보기에서는 다른 구성 요소인 Distroless Helper와 함께 핫 리로드 및 토큰 서비스 볼륨이 단일 탑재 지점(/VSTools)에서 결합됩니다.

참고 항목

Visual Studio 17.10 프리뷰 Docker Desktop 없이 WSL(Linux용 Windows 하위 시스템)에서 Docker 엔진을 사용하는 경우 볼륨 탑재를 만들 때 Visual Studio에서 WSL 경로를 사용하도록 환경 변수 VSCT_WslDaemon=1을 설정합니다. NuGet 패키지 Microsoft.VisualStudio.Azure.Containers.Tools.Targets 1.20.0-Preview 1도 필요합니다.

ASP.NET Core 웹앱의 경우, SSL 인증서 및 사용자 비밀에 대한 추가 폴더가 두 개 있을 수 있습니다. 이 내용은 다음 섹션에 자세히 설명되어 있습니다.

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

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

주의

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

컨테이너 진입점

Visual Studio는 프로젝트 형식 및 컨테이너 운영 체제에 따라 사용자 지정 컨테이너 진입점을 사용합니다. 다음과 같은 다양한 조합이 있습니다.

컨테이너 유형 진입점

Linux 컨테이너 진입점은 컨테이너를 계속 실행하기 위해 무한 대기하는 tail -f /dev/null입니다. 디버거를 통해 앱이 실행되는 경우 앱 실행을 담당하는 것은 디버거입니다(즉, dotnet webapp.dll). 디버그하지 않고 시작하는 경우 도구는 docker exec -i {containerId} dotnet webapp.dll을 실행하여 앱을 실행합니다.

Windows 컨테이너 진입점은 다음과 같습니다. C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus 디버거를 실행하여 연결을 대기하고 있습니다. 이 메서드는 디버거가 앱을 실행할 때 적용됩니다. 디버깅하지 않고 시작하면 docker exec 명령이 사용됩니다. .NET Framework 웹앱의 경우 진입점은 ServiceMonitor가 명령에 추가되는 위치와 약간 다릅니다.

컨테이너 유형	진입점
Linux 컨테이너	진입점은 컨테이너를 계속 실행하기 위해 무한 대기하는 `tail -f /dev/null`입니다. 디버거를 통해 앱이 실행되는 경우 앱 실행을 담당하는 것은 디버거입니다(즉, `dotnet webapp.dll`). 디버그하지 않고 시작하는 경우 도구는 `docker exec -i {containerId} dotnet webapp.dll`을 실행하여 앱을 실행합니다.
Windows 컨테이너	진입점은 다음과 같습니다. `C:\remote_debugger\x64\msvsmon.exe /noauth /anyuser /silent /nostatus` 디버거를 실행하여 연결을 대기하고 있습니다. 이 메서드는 디버거가 앱을 실행할 때 적용됩니다. 디버깅하지 않고 시작하면 `docker exec` 명령이 사용됩니다. .NET Framework 웹앱의 경우 진입점은 `ServiceMonitor`가 명령에 추가되는 위치와 약간 다릅니다.

컨테이너 진입점은 단일 컨테이너 프로젝트가 아닌 Docker Compose 프로젝트에서만 수정할 수 있습니다.

SSL 사용 ASP.NET Core 앱

Visual Studio의 컨테이너 도구는 컨테이너 없이 작동하는 것과 동일한 방식으로 개발 인증서를 사용하여 SSL 사용 ASP.NET Core 앱의 디버깅을 지원합니다. 이러한 작업을 수행하기 위해 Visual Studio는 인증서를 내보내고 컨테이너에서 사용할 수 있도록 하는 몇 가지 단계를 더 추가합니다. 컨테이너에서 디버깅할 때 Visual Studio에서 처리하는 흐름은 다음과 같습니다.

로컬 개발 인증서가 있고 dev-certs 도구를 통해 호스트 머신에서 신뢰할 수 있는지 확인합니다.
이 특정 앱에 대한 사용자 비밀 저장소에 저장되어 있는 보안 암호를 사용하여 %APPDATA%\ASP.NET\Https로 인증서를 내보냅니다.
다음 디렉터리에 볼륨을 탑재합니다.
- *%APPDATA%\Microsoft\UserSecrets
- *%APPDATA%\ASP.NET\Https

ASP.NET Core는 아래의 어셈블리 이름과 일치하는 인증서를 Https 폴더에 매핑되어 있으므로 해당 경로의 컨테이너에 매핑되어 있습니다. 인증서 경로 및 암호는 환경 변수(즉, ASPNETCORE_Kestrel__Certificates__Default__Path 및 ASPNETCORE_Kestrel__Certificates__Default__Password) 또는 사용자 비밀 json 파일을 사용하여 정의할 수도 있습니다. 예:

{
  "Kestrel": {
    "Certificates": {
      "Default": {
        "Path": "c:\\app\\mycert.pfx",
        "Password": "strongpassword"
      }
    }
  }
}

구성에서 컨테이너화된 빌드와 컨테이너화되지 않은 빌드를 모두 지원하는 경우에는 경로가 컨테이너 환경과 관련되므로 환경 변수를 사용해야 합니다.

컨테이너에서 ASP.NET Core 앱과 함께 SSL을 사용하는 방법에 대한 자세한 내용은 HTTPS를 통해 Docker를 사용하여 ASP.NET Core 이미지 호스팅을 참조하세요.

호스트 및 컨테이너에서 신뢰할 수 있는 멀티서비스 앱에 대한 사용자 지정 인증서를 만들어 HTTPS 서비스 간 통신에 사용하는 코드 샘플은 CertExample입니다.

Share via

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

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

다단계 빌드

MSBuild

디버깅

디버깅 및 프로덕션에 대한 컨테이너 이미지 수정

디버깅에 대해서만 컨테이너 이미지 수정

명령줄에서 빌드

Docker 빌드 사용

프로젝트 준비

볼륨 매핑

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

컨테이너 진입점

SSL 사용 ASP.NET Core 앱

피드백

피드백

추가 리소스

Share via

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

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

다단계 빌드

MSBuild

디버깅

디버깅 및 프로덕션에 대한 컨테이너 이미지 수정

디버깅에 대해서만 컨테이너 이미지 수정

명령줄에서 빌드

Docker 빌드 사용

프로젝트 준비

볼륨 매핑

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

컨테이너 진입점

SSL 사용 ASP.NET Core 앱

관련 콘텐츠

피드백

피드백

추가 리소스