@galvesribeiro PR은 언제나 환영입니다! 저는 VS2017 경험에 익숙하지 않으므로 이 확장 기능을 개선하는 방법에 대한 피드백/생각은 굉장할 것입니다.

@lostintangent님 , 빠른 답변 감사합니다.

이 게시물을 살펴보십시오 https://blogs.msdn.microsoft.com/webdev/2016/11/16/new-docker-tools-for-visual-studio/

Visual Studio에서 어떻게 작동하는지 보여줍니다. 기본적으로 프로젝트 또는 솔루션을 마우스 오른쪽 버튼으로 클릭하고 Docker 지원을 추가합니다. 추가되면 F5 키를 누르기만 하면 모든 "마법"이 발생하고 대상 컨테이너에 디버거가 연결됩니다. VS2017에서는 docker-compose 시나리오에서 실행되는 여러 컨테이너도 지원하므로 동일한 작성 파일의 여러 컨테이너 부분을 동시에 디버그할 수 있습니다...

노드의 경우 확장은 사이트 및 디버거 포트를 모두 열고 디버그 스위치로 노드를 실행하는 docker-compose.debug.yml 파일을 생성합니다. 사전 실행 작업으로 yml 파일에서 docker-compose up을 실행하여 디버그 프로세스를 자동화할 수 있으며 그러면 VS Code가 이에 연결할 수 있습니다.

C#의 경우 동일한 패턴을 사용할 수 있습니다. 올바른 작업 파일인 docker-compose.debug.yml을 생성한 다음 launch.json에 연결합니다.

@lostintangent 여기에서 내 저장소를 보십시오: https://github.com/spboyer/dockerdebugapp
여기에는 기본 이미지와 적절한 디버그 작성 이미지가 있어 디버거를 VS Code에 연결합니다. .NET Core용으로 이러한 파일을 생성하려면 확장을 변경해야 합니다.

시원한!

여러분, 방금 docker-compose를 예로 설명했습니다. 귀하의 접근 방식은 솔루션이 없고 연결할 단일 컨테이너가 있는 단일 프로젝트에 적합합니다. 아이디어는 F5 키를 누르고 docker-compose 파일 내의 모든 서비스에 디버거를 연결하는 것입니다.

여러 번의 시도와 오류 끝에 VSCode의 기능 부족을 억제하기 위해 스크립트/해킹에 의존하지 않는 더 나은 방법을 찾았습니다.

다음은 솔루션 수준의 샘플 docker-compose.yml .

version: '3.1'

services:
  repository-api:
    image: repository-api:debug
    build:
      context: ./src/QUBIX.Repository.API/bin/PublishOutput/
      dockerfile: Dockerfile.debug
    ports: 
      - "10200:10200"
    environment: 
      - ASPNETCORE_ENVIRONMENT=Development
    volumes: 
      - ./src/QUBIX.Repository.API/bin/PublishOutput/:/app
      - ~/.nuget/packages:/root/.nuget/packages:ro
    depends_on: 
      - repository-silo
  repository-silo:
    image: repository-silo:debug
    build:
      context: ./src/QUBIX.Repository.Silo/bin/PublishOutput/
      dockerfile: Dockerfile.debug
    environment: 
      - QUBIX_REPOSITORY_MBR_CS
    volumes: 
      - ./src/QUBIX.Repository.Silo/bin/PublishOutput/:/app
      - ~/.nuget/packages:/root/.nuget/packages:ro
  repository-reader-silo:
    image: repository-reader-silo:debug
    build:
      context: ./src/QUBIX.Repository.Reader.Silo/bin/PublishOutput/
      dockerfile: Dockerfile.debug
    environment: 
      - QUBIX_REPOSITORY_READER_MBR_CS
      - QUBIX_REPOSITORY_READER_DOCDB_EP
      - QUBIX_REPOSITORY_READER_DOCDB_KEY
    volumes: 
      - ./src/QUBIX.Repository.Reader.Silo/bin/PublishOutput/:/app
      - ~/.nuget/packages:/root/.nuget/packages:ro

Dockerfile.debug .

FROM microsoft/dotnet:1.1-sdk-msbuild
ENV NUGET_XMLDOC_MODE=skip 
ARG CLRDBG_VERSION=VS2015U2
WORKDIR /clrdbg
RUN apt-get update \
    && apt-get install -y --no-install-recommends \
        unzip \
    && rm -rf /var/lib/apt/lists/* \
    && curl -SL https://raw.githubusercontent.com/Microsoft/MIEngine/getclrdbg-release/scripts/GetClrDbg.sh --output GetClrDbg.sh \
    && chmod 700 GetClrDbg.sh \
    && ./GetClrDbg.sh $CLRDBG_VERSION \
    && rm GetClrDbg.sh
WORKDIR /app
ENTRYPOINT ["tail", "-f", "/dev/null"]

여러 서비스가 있지만 그 중 어느 것도 디버거 포트가 열려 있지 않습니다. DockerFile.debug 기본적으로 컨테이너를 시작하고 진입점은 종료 없이 그대로 유지합니다. 또한 다운로드 getclrdbg.sh 합니다 (포함해야 그래, 내가 그물 핵심 SDK 모두 Windows 및 Linux 컨테이너를 생각 디버거를 설치하려면 clrdbg ). 볼륨은 /app 의 프로젝트 출력 폴더에 매핑되고 docker-compose에 전달됩니다.

하루에 한 번 프로젝트 작업을 시작할 때 솔루션 디렉토리와 docker-compose up -d 터미널을 엽니다. ENV vars, 이미지 등과 같이 컨테이너 자체에서 무언가를 변경해야 하는 경우가 아니면 컨테이너를 끌 필요가 없습니다. 그렇지 않으면 전체 작성 프로젝트가 항상 켜져 있어야 합니다. (처음이라면 docker-compose build 를 실행하여 이미지를 빌드합니다.)

모든 컨테이너가 실행 중이면 컨테이너를 디버그하도록 VSCode를 구성해야 합니다.

이것은 내 tasks.json .

{
    "version": "0.1.0",
    "isShellCommand": true,
    "command": "dotnet",
    "args":[],
    "tasks": [
        {
            "taskName": "publish",
            "args": [
                "${workspaceRoot}/QUBIX-Repository.sln", "-c", "Debug", "-o", "bin/PublishOutput"
            ],
            "isBuildCommand": true,
            "problemMatcher": "$msCompile"
        }
    ]
}

build 대신 publish 있습니다. 그 이유는 .Net Core 빌드가 모든 종속성을 출력 폴더에 넣지 않기 때문입니다. 따라서 clrdbg 컨테이너 내부에서는 요청 시 참조된 어셈블리를 찾을 수 없습니다.

이제 이것은 내 launch.json .

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Repository-Silo",
            "type": "coreclr",
            "request": "launch",
            "cwd": "/app",
            "program": "/app/QUBIX.Repository.Silo.dll",
            "sourceFileMap": {
                "/app": "${workspaceRoot}/src/QUBIX.Repository.Silo"
            },
            "pipeTransport": {
                "pipeProgram": "/bin/bash",
                "pipeCwd": "${workspaceRoot}",
                "pipeArgs": [
                    "-c",
                    "docker exec -i qubixrepository_repository-silo_1 /clrdbg/clrdbg --interpreter=mi"
                ]
            }
        },
        {
            "name": "Repository-API",
            "type": "coreclr",
            "request": "launch",
            "cwd": "/app",
            "program": "/app/QUBIX.Repository.API.dll",
            "sourceFileMap": {
                "/app": "${workspaceRoot}/src/QUBIX.Repository.API"
            },
            "pipeTransport": {
                "pipeProgram": "/bin/bash",
                "pipeCwd": "${workspaceRoot}",
                "pipeArgs": [
                    "-c",
                    "docker exec -i qubixrepository_repository-api_1 /clrdbg/clrdbg --interpreter=mi"
                ]
            }
        },
        {
            "name": "Repository-Reader-Silo",
            "type": "coreclr",
            "request": "launch",
            "cwd": "/app",
            "program": "/app/QUBIX.Repository.Reader.Silo.dll",
            "sourceFileMap": {
                "/app": "${workspaceRoot}/src/QUBIX.Repository.Reader.Silo"
            },
            "pipeTransport": {
                "pipeProgram": "/bin/bash",
                "pipeCwd": "${workspaceRoot}",
                "pipeArgs": [
                    "-c",
                    "docker exec -i qubixrepository_repository-reader-silo_1 /clrdbg/clrdbg --interpreter=mi"
                ]
            }
        },
        {
            "name": "Repository-Reader-API",
            "type": "coreclr",
            "request": "launch",
            "cwd": "/app",
            "program": "/app/QUBIX.Repository.Reader.API.dll",
            "sourceFileMap": {
                "/app": "${workspaceRoot}/src/QUBIX.Repository.Reader.API"
            },
            "pipeTransport": {
                "pipeProgram": "/bin/bash",
                "pipeCwd": "${workspaceRoot}",
                "pipeArgs": [
                    "-c",
                    "docker exec -i qubixrepository_repository-reader-api_1 /clrdbg/clrdbg --interpreter=mi"
                ]
            }
        }
    ]
}

지금 여기에서 무슨 일이 일어나고 있습니까? publishOutput이 컨테이너의 /app 에 매핑된다는 것을 기억하십니까? 따라서 docker-compose.yml 에 있는 각 서비스/프로젝트에 대해 시작 구성이 있습니다. 이 시작 구성이 하는 일은 docker exec 를 해당 서비스의 컨테이너로 호출하고 clrdbg 호출하는 것입니다. 이를 사용하여 컨테이너 내부의 원격 디버거와 디버거가 될 애플리케이션( /app 매핑됨)을 시작하고 컴퓨터에서 .Net Core 디버거를 만들어 여기에 연결할 수 있습니다. dll은 디버거 내부에 원격으로 배포되기 때문에 소스 맵 매개변수는 소스가 어디에 있는지 디버거에 알려줍니다.

이런 식으로 디버거 세션에서 중지를 누르면 종료되는 명령은 전체 컨테이너 자체가 아니라 원격 디버거와 애플리케이션을 시작한 docker exec 입니다. F5 키를 누를 때마다 컨테이너를 계속 다시 빌드하는 것보다 훨씬 빠르게 반복할 수 있습니다.

_외부 스크립트나 확장 기능이 전혀 없다는 점에 유의하세요. VSCode, C# 확장 및 Docker 설치만 있으면 됩니다._

완벽하게 작동합니다! 💃:배송:

이제 단점 😞

1. 시작 구성에서 docker exec 를 사용하여 서비스 내의 특정 컨테이너를 직접 대상으로 지정합니다(예 qubixrepository_repository-reader-api_1 마지막 항목의
2. 구성을 두 개 이상의 인스턴스로 확장하고 동일한 서비스의 여러 인스턴스를 디버그할 수 없습니다.
3. F5 키를 누르고 모든 서비스에 디버거를 연결할 수는 없습니다. VSCode 디버거 섹션에서 하나씩 시작해야 합니다. ( compound 시작 구성은 작동하지 않으며 작동하더라도 docker-compose 종속성 체인을 선언하는 depends_on 를 존중하지 않으므로 하나의 서비스가 시작되기 전에 시작할 수 있습니다. 종속성).
4. docker-compose를 사전 실행 작업으로 사용하고 빌드 프로세스와 디버거 경험을 많이 느리게 하여 제거했습니다.

원하는 경험:

1. docker-compose.yml 파일을 만들고 평소와 같이 이미지와 서비스를 설명합니다.
2. F5 키를 눌러 프로젝트 실행
3. dotnet build 는 솔루션 수준에서 발생
4. docker-compose 업데이트가 있는지 확인하고 업데이트가 없고 서비스가 실행 중이면 무시하고 실행하지 마십시오. 그렇지 않으면 docker-compose build 및 docker-compose up 가 호출됩니다.
5. docker-compose ps 는 구성된 모든 프로젝트의 모든 컨테이너를 가져오고 각 프로젝트에 디버거를 연결합니다.
6. VSCode에서 디버거를 중지하면 원격 디버거 프로세스가 종료되지만 컨테이너는 계속 실행됩니다.
7. 디버그 세션이 실행되는 동안 다른 컨테이너(예: qubixrepository_repository-reader-api_1, qubixrepository_repository-reader-api_2, qubixrepository_repository-reader-api_N)에서 동일한 프로젝트에 대한 디버거를 여러 번 연결할 수 있으므로 분산 응용 프로그램을 디버그할 수 있습니다.

말이 되나요 여러분? 우리는 어떻게 그 경험을 달성할 수 있습니까?

감사 해요!

@galvesribeiro
다중 서비스 디버깅에 매우 유용합니다. 예제 코드가 있습니까?

@Shawn-Fan 다중 서비스는 불행히도 기본적으로 디버거에서 지원하지 않는 것입니다. 동일한 서비스의 다중 인스턴스도 마찬가지입니다(진정으로 분산된 응용 프로그램에서 매우 유용함).

이 문제의 내 단계를 따르면 docker-compose up -d 에서 모든 디버그 컨테이너를 시작한 다음 각 서비스에 대해 VS의 디버그 섹션에서 각 디버거를 실행할 수 있습니다.

나는 여전히 MSFT를 사용하여 즉시 사용 가능한 여러 서비스와 여러 인스턴스에 디버거를 연결할 수 있어야 한다고 생각합니다. 내가 한 것은 디버거 제한을 해결하기 위한 해킹이었습니다.

@galvesribeiro
많은 도움을 주셔서 감사합니다. 늦게라도 가볼게......
Windows용 VS 2017은 꽤 잘 작동하지만 Mac에서 Visual Studio 코드를 사용하여 Docker에서 작업하려고 합니다(Mac용 Visual Studio는 VS 2017에서 잘 작동하기를 바랍니다).

VS2017과 Mac용 VS 모두 Docker 디버깅 경험과 관련하여 VSCode와 동일한 제한이 있습니다...

먼저 여기에서 공유한 자세한 정보에 대해 @galvesribeiro 에게 감사드립니다. 정말 도움이 되었습니다.

vscode에서 aspnetcore 2.0을 디버그하려는 사람들을 위해 Dockerfile + launch.json을 약간만 수정해야 했습니다.

1. FROM을 microsoft/aspnetcore- build:1.0-2.0으로 변경합니다(내 앱 때문에 2를 사용할 수 있음).
2. clrdbg 대신 vsdbg를 사용하십시오. 최신 C# 확장에서는 crl이 더 이상 지원되지 않는 것 같습니다. 이에 대한 자세한 정보는 이 Dockerfile.debug 를 참조하십시오.
3. point#2 때문에 launch.json이 약간 변경되었고 게시를 위한 preLaunchTask도 포함되었습니다.

중요: <> 사이의 모든 항목은 앱의 데이터로 채워야 합니다.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "<Just_Another_Name_For_Your_Launch_Conf>",
            "type": "coreclr",
            "request": "launch",
            "preLaunchTask": "publish",
            "cwd": "/app",
            "program": "/app/<Your_AppName_Here>.dll",
            "sourceFileMap": {
                "/app": "${workspaceRoot}/<your_project_folder_here>"
            },
            "pipeTransport": {
                "pipeProgram": "docker",
                "pipeCwd": "${workspaceRoot}",
                "pipeArgs": [
                    "exec -i <your_containername_here>"
                ],
                "quoteArgs": false,
                "debuggerPath": "/vsdbg/vsdbg"
            }
        }
    ]
}

즐거운 디버깅!

@galvesribeiro - 훌륭한 작업, 공유해 주셔서 감사합니다. 우연히 서비스 프로젝트 중 하나의 예제 Dockerfile이 있습니까? 저장소 API

감사 해요
표시

@mmacneil 감사합니다. 디버그 이미지는 여기에 게시한 이미지입니다. 런타임 이미지는 본질적으로 microsoft/dotnet 런타임 전용 이미지에서 상속된 빈 이미지이며 진입점은 멋진 항목 없이 dotnet myProject.dll 입니다.

감사합니다 @galvesribeiro , 그것은 의미가 있습니다. 나는 다른 곳에서 언급한 것처럼 Dockerfile.debug와 런타임 이미지를 병합하고 있다고 생각했지만 이 경우 디버그 및 런타임을 위한 2개의 별도 컨테이너가 있음을 알 수 있습니다.

500(단일 프로젝트) ASP.NET .NET Core 디버깅에 대한 미리 보기 지원이 추가되었습니다(a la VS). 이것이 당신이 원하는 것에 더 가까워지고, 더 중요하게는, 그렇지 않다면 다른 무엇이 필요한지 알고 싶습니다.

@philiphoff 가

@galvesribeiro 죄송합니다. 제가 조금 앞서간 것 같습니다. PR이 master 병합되었지만 아직 릴리스되지 않았습니다.

아 멋지다. 적어도 Insiders 빌드에서는 곧 적용되기를 바랍니다. 내 발견을 다시 보고할 것입니다. 감사 해요!

iOS용 Outlook 다운로드 https://aka.ms/o0ukef

보낸 사람: 필립 호프 알림 @github.com
보낸 날짜: 2018년 10월 19일 금요일 오후 6:07:29
받는 사람: Microsoft/vscode-docker
참조: Gutemberg Ribeiro; 언급하다
제목: Re: [Microsoft/vscode-docker] 디버그 컨테이너(#56)

@galvesribeiro https://github.com/galvesribeiro 죄송합니다. 제가 조금 앞서간 것 같습니다. PR이 마스터에 병합되었지만 아직 릴리스되지 않았습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 회신하거나 GitHub https://github.com/Microsoft/vscode-docker/issues/56#issuecomment-431499291 에서 확인하거나 스레드 https://github.com/notifications/unsubscribe-auth/를 음소거합니다.

@galvesribeiro , PR #500에 따라 이 버그를 종료합니다. 문제가 발생하면 새 버그를 신고하세요. :-)

멋진 @PrashanthCorp 약속한 대로 테스트할 시간이 없었습니다. VSCode의 릴리스 빌드로 가는 길을 찾았습니까? 그것을 적절하게 사용하는 방법에 대한 문서/가이드가 있으며 무엇을 기대해야 합니까?

감사 해요!

@galvesribeiro https://github.com/Microsoft/vscode-docker#debugging -net-core-preview를 살펴보세요. 감사합니다!

cc @필호프

@StephenWeatherford 감사

방금 보았지만 ... 그러나 여전히 단일 컨테이너 디버그에서 어려움을 겪고 있습니다. ( 작성 또는 kubernetes 지원 없음 ...