@galvesribeiro PR का हमेशा स्वागत है! मैं वीएस2017 अनुभव से बहुत परिचित नहीं हूं, इसलिए इस एक्सटेंशन को बेहतर बनाने के बारे में आपके पास कोई प्रतिक्रिया/विचार बहुत बढ़िया होगा।

हैलो @lostintangent , तत्काल उत्तर के लिए धन्यवाद।

इस पोस्ट पर एक नज़र डालें https://blogs.msdn.microsoft.com/webdev/2016/11/16/new-docker-tools-for-visual-studio/

यह दिखाता है कि यह विजुअल स्टूडियो पर कैसे काम करता है। मूल रूप से आप किसी प्रोजेक्ट या समाधान पर राइट क्लिक करते हैं और उसमें डॉकर सपोर्ट जोड़ते हैं। एक बार इसे जोड़ने के बाद, बस F5 दबाएं और सभी "जादू" होता है और आपके पास अपने लक्षित कंटेनर से जुड़ा डीबगर होता है। वीएस2017 पर यह कई कंटेनरों का भी समर्थन करता है जो docker-compose परिदृश्यों पर चल रहे हैं ताकि आप एक ही समय में एक ही कंपोज़ फ़ाइल के कंटेनर भाग का एक गुच्छा डीबग कर सकें ...

नोड के लिए, एक्सटेंशन एक docker-compose.debug.yml फ़ाइल बनाता है जो साइट और डीबगर पोर्ट दोनों को खोलेगा और डिबग स्विच के साथ नोड चलाएगा। आप पूर्व लॉन्च कार्य के रूप में yml फ़ाइल पर docker-compose up चलाकर डीबग प्रक्रिया को स्वचालित कर सकते हैं और फिर वीएस कोड इसे संलग्न करने में सक्षम होना चाहिए।

सी # के लिए, एक ही पैटर्न का उपयोग किया जा सकता है ... सही कार्य फ़ाइल उत्पन्न करें, docker-compose.debug.yml, और फिर उन्हें launch.json में कनेक्ट करें।

@lostintangent मेरे रेपो को यहां देखें: https://github.com/spboyer/dockerdebugapp
इसमें मूल छवियां हैं और डीबगर को वीएस कोड में संलग्न करने के लिए छवियों को उचित डीबग लिखें। .NET कोर के लिए इन फ़ाइलों को जनरेट करने के लिए एक्सटेंशन में आवश्यक परिवर्तन हैं।

ठंडा!

दोस्तों मैंने अभी एक उदाहरण के रूप में 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 भी डाउनलोड करता है (हां, मुझे लगता है कि .net कोर एसडीके के लिए विंडोज़ और लिनक्स कंटेनर दोनों में 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 में मैप किया गया है) शुरू करने के लिए इसका उपयोग करेगा और इसे संलग्न करने के लिए आपको मशीन पर नेट कोर डीबगर बनाता है। चूंकि डीएलएस दूरस्थ रूप से तैनात हैं (डीबगर के अंदर), स्रोत मानचित्र पैरामीटर डीबगर को बताते हैं कि स्रोत कहां है।

इस तरह, जब आप डीबगर सत्र में स्टॉप दबाते हैं, तो बाहर निकलने वाला आदेश docker exec जिसने रिमोट डीबगर और एप्लिकेशन को शुरू किया, न कि पूरे कंटेनर को। हर बार जब आप F5 दबाते हैं तो कंटेनर को फिर से बनाने की तुलना में पुनरावृत्ति बहुत तेज हो जाती है।

_ध्यान दें कि कोई बाहरी स्क्रिप्ट या एक्सटेंशन बिल्कुल नहीं है। आपको बस VSCode, C# एक्सटेंशन और Docker इंस्टॉल करना है।

यह पूरी तरह से काम करता है! :शिपिट:

अब नकारात्मक पक्ष

1. ध्यान दें कि लॉन्च कॉन्फ़िगरेशन में मैं सेवा के भीतर एक विशिष्ट कंटेनर में सीधे लक्षित करने के लिए docker exec का उपयोग कर रहा हूं (उदाहरण के लिए अंतिम प्रविष्टि में qubixrepository_repository-reader-api_1 )।
2. आप अपनी रचना को एक से अधिक इंस्टेंस में स्केल करने और एक ही सेवा के कई इंस्टेंस डीबग करने में सक्षम नहीं हैं।
3. आप F5 को हिट करने और डीबगर को सभी सेवाओं से जोड़ने में सक्षम नहीं हैं। आपको VSCode डिबगर सेक्शन से एक-एक करके शुरुआत करनी होगी। ( compound लॉन्च कॉन्फ़िगरेशन बस काम नहीं करता है और अगर ऐसा होता भी है, तो यह depends_on सम्मान नहीं करता है जो docker-compose निर्भरता श्रृंखला घोषित करता है ताकि एक सेवा इसके पहले शुरू हो सके निर्भरता)।
4. प्री-लॉन्च कार्य के रूप में डॉकर-कंपोज़ का उपयोग करें, निर्माण प्रक्रिया और डीबगर अनुभव को धीमा कर दें, इसलिए मैंने इसे हटा दिया।

वांछित अनुभव:

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
यह बहु-सेवाओं को डीबग करने में बहुत मददगार है, क्या आपके पास उदाहरण कोड है?

@ शॉन-फैन बहु-सेवाएं कुछ ऐसा है जो दुर्भाग्य से डिबगर आउट-ऑफ-द-बॉक्स द्वारा समर्थित नहीं है। न तो एक ही सेवा का बहु-उदाहरण है (वास्तव में वितरित अनुप्रयोगों में बहुत उपयोगी)।

यदि आप इस मुद्दे में मेरे चरणों का पालन करते हैं, तो आप docker-compose up -d से सभी डिबग कंटेनरों को शुरू कर सकते हैं और फिर प्रत्येक डिबगर को प्रत्येक सेवा के लिए वीएस पर डिबग अनुभाग से चला सकते हैं।

मुझे अब भी लगता है कि MSFT को हमें डिबगर को कई सेवाओं और कई उदाहरणों को आउट-ऑफ-द-बॉक्स में संलग्न करने की अनुमति देनी चाहिए। मैंने जो किया वह डीबगर सीमा को हल करने के लिए एक हैक था।

@galvesribeiro
आपकी मदद के लिए बहुत बहुत धन्यवाद। मैं देर से आपके रास्ते की कोशिश करूँगा......
हालांकि विंडोज़ के लिए वीएस 2017 बहुत अच्छा काम करता है, मैं मैक में विजुअल स्टूडियो कोड का उपयोग डॉकर में काम करने के लिए करने की कोशिश कर रहा हूं (उम्मीद है कि मैक के लिए विजुअल स्टूडियो वीएस 2017 के रूप में अच्छी तरह से काम करता है)।

मैक के लिए वीएस2017 और वीएस दोनों में वीएसकोड के रूप में डॉकर डिबगिंग अनुभव के संबंध में एक ही सीमा है ...

सबसे पहले उन्होंने यहां साझा की गई विस्तृत जानकारी के लिए @galvesribeiro को धन्यवाद दिया। यह वास्तव में मददगार था।

जो लोग vscode से aspnetcore 2.0 को डिबग करना चाहते हैं, उनके लिए मुझे Dockerfile + launch.json में कुछ न्यूनतम बदलाव करने थे:

1. FROM को Microsoft/aspnetcore- बिल्ड में बदलें
2. clrdbg के बजाय vsdbg का उपयोग करें, क्योंकि ऐसा लगता है कि नवीनतम C# एक्सटेंशन crl अब समर्थित नहीं है। इस बारे में विस्तृत जानकारी के लिए कृपया इस Dockerfile.debug को देखें
3. लॉन्च.जेसन को थोड़ा बदल दिया क्योंकि बिंदु # 2 और इसमें प्रकाशित करने के लिए प्रीलांच टास्क भी शामिल है:

महत्वपूर्ण: <> के बीच की हर चीज़ को आपके ऐप के डेटा से भरना होगा

{
    "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 का उदाहरण है - अर्थात। भंडार-एपीआई

धन्यवाद
निशान

@mmacneil धन्यवाद। डीबग छवि वह है जिसे मैंने यहां पोस्ट किया है। रनटाइम छवि अनिवार्य रूप से एक खाली छवि है जो माइक्रोसॉफ्ट/डॉटनेट रनटाइम-ओनली इमेज से विरासत में मिली है और प्रवेश बिंदु dotnet myProject.dll बिना किसी फैंसी सामान के है।

धन्यवाद @galvesribeiro , यह समझ में आता है। मैं सोच रहा था कि आप किसी तरह Dockerfile.debug और रनटाइम इमेज को मर्ज कर रहे हैं जैसा कि मैंने देखा है कि कहीं और उल्लेख किया गया है, लेकिन मैं इस मामले में डिबग और रनटाइम के लिए 2 अलग कंटेनर देखता हूं।

(एकल प्रोजेक्ट) ASP.NET .NET कोर डिबगिंग (एक ला वीएस) के लिए 500 अतिरिक्त पूर्वावलोकन समर्थन। मुझे यह जानना अच्छा लगेगा कि क्या यह आपको आपकी इच्छित चीज़ों के करीब ले जाता है और इससे भी महत्वपूर्ण बात यह है कि यदि नहीं, तो और क्या चाहिए।

@philliphoff इसे

@galvesribeiro क्षमा करें, शायद मैं अपने आप से थोड़ा आगे निकल गया। पीआर को master में मिला दिया गया है, लेकिन इसे अभी तक जारी नहीं किया गया है।

आह मस्त। मुझे उम्मीद है कि यह कम से कम इनसाइडर्स बिल्ड पर जल्द ही आ जाएगा। मेरे निष्कर्षों की रिपोर्ट करेंगे। धन्यवाद!

आईओएस के लिए आउटलुक प्राप्त करें https://aka.ms/o0ukef

से: फिलिप हॉफ नोटिफिकेशन @github.com
भेजा गया: शुक्रवार, अक्टूबर 19, 2018 6:07:29 अपराह्न
प्रति: Microsoft/vscode-docker
सीसी: गुटेमबर्ग रिबेरो; उल्लेख
विषय: पुन: [Microsoft/vscode-docker] डिबग कंटेनर (#56)

@galvesribeiro https://github.com/galvesribeiro क्षमा करें, शायद मैं अपने आप से थोड़ा आगे निकल गया। पीआर को मास्टर में मिला दिया गया है, लेकिन इसे अभी तक जारी नहीं किया गया है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub https://github.com/Microsoft/vscode-docker/issues/56#issuecomment-431499291 पर https://github.com/notifications/unsubscribe-auth/ AEfuOIZ_mCzxwQXaP4-G0-CxwNrEhzD0ks5umj8RgaJpZM4LwWjB ।

@galvesribeiro , हम PR #500 के आधार पर इस बग को बंद कर रहे हैं। यदि आपको कोई समस्या आती है तो एक नया बग दर्ज करें। :-)

कूल @PrashanthCorp जैसा कि मैंने वादा किया था, मेरे पास इसका परीक्षण करने के लिए खुद का समय नहीं था। क्या इसे VSCode के रिलीज़ बिल्ड के लिए अपना रास्ता मिल गया? क्या इसका उचित उपयोग करने के बारे में कोई डॉक्टर/मार्गदर्शिका है और हमें इससे क्या उम्मीद करनी चाहिए?

धन्यवाद!

@galvesribeiro https://github.com/Microsoft/vscode-docker#debugging -net -core-preview पर एक नज़र डालें, धन्यवाद!

सीसी @ फिलहॉफ

धन्यवाद @StephenWeatherford

बस इसे देखा ... हालांकि, यह अभी भी सिंगल-कंटेनर डीबग में संघर्ष करता है :( कोई लिखें या कुबेरनेट्स समर्थन नहीं करता ...