@EricJizbaMSFT

SSH와 컨테이너 컨텍스트를 구별하는 것은 의미가 있습니다.

"Dev Containers"(UI) 대 "SSH"(Workspace)에 대해 다른 기본값을 가질 수 있습니까?

기본값은 정적으로 유지되며 중요한 것은 확장이 다른 컨텍스트에 적응한다는 것입니다. 이 작업을 수행하는 방법은 다음 질문을 참조하세요.

확장 프로그램이 원격에서 실행 중인지 어떻게 감지합니까? 그리고 어떤 종류의 원격입니까? (오류 메시지를 사용자 정의할 수 있도록)

vscode.env.remoteAuthority 를 사용하면 확장이 원격으로 실행 중인지 여부와 확장이 실행 중인 원격 권한을 모두 결정할 수 있습니다. API는 1.35에 있습니다. API 문서를 참조하십시오.

해석기 메커니즘은 https://github.com/microsoft/vscode/blob/afb08370356e0625b40d2ea42aa7dc0513aa2c39/src/vs/vscode.proposed.d.ts#L131에 문서화되어 있습니다.

예를 들어 VS Code 원격 컨테이너 확장은 'dev-container' 및 ' attached -container' 권한 확인자를 제공합니다.

UI 확장으로 로컬 컴퓨터에 터미널을 만드는 공식 API가 있습니까?

홍보 https://github.com/microsoft/vscode-docker/pull/907을 참조하십시오.

UI 확장으로 실행할 때 컨테이너 내부의 파일 시스템에 액세스하는 공식 API가 있습니까?

아직 아니지만 이것은 우리의 백로그에 있습니다. 이것이 제자리에 있을 때까지 PR https://github.com/microsoft/vscode-docker/pull/907/에서 수행된 대로 파일 시스템 액세스가 필요한 명령을 비활성화할 수 있습니다.

//fyi @Chuxel @RMacfarlane @kieferrm @jrieken

새 API에 대한 약간의 개선: https://github.com/microsoft/vscode/issues/74188#issuecomment -496579989. vscode.env.remoteAuthority 는 이제 undefined 또는 { prefix: string} 유형의 개체가 됩니다. 그것은 toString의 전체 값입니다. 그 이유는 원격 uri가 일반적으로 vscode-remote://ssh+something-machine-specific/path 처럼 보이고 권한의 ssh 부분만 중요하기 때문입니다.

참고: 1.35의 경우 vscode.env.remoteAuthority 와 함께 배송 되지 않습니다 . 전체 배경: https://github.com/microsoft/vscode/issues/74188#issuecomment -496839841. 제안된 API ExtensionContext#executionContext 를 사용할 수 있습니다.

기본값은 정적으로 유지되며 중요한 것은 확장이 다른 컨텍스트에 적응한다는 것입니다.

@egamma 그래서 package.json에서 "ui" 또는 "workspace" 중 하나의 기본값만 지정할 수 있다는 말씀이신가요? 그것은 이해할 수 있지만 기본값을 결정해야 합니다. https://github.com/microsoft/vscode-docker/issues/924 에서 사용자가 기본적으로 "작업 공간"으로 설정하기를 기대한다는 피드백을 받았습니다. 그것이 당신에게 의미가 있습니까? (개발 컨테이너 시나리오에서 먼저 오류 메시지를 개선한다고 가정). 특히, 나에게 눈에 띄는 몇 가지 의견은 다음과 같습니다.

... 가장 이상한 동작은 이 확장이 ssh에 설치하는 것이 비활성화된 몇 가지 테마가 없는 확장 중 하나이며 로컬로만 설치할 수 있다는 것입니다.

내 기대는 또한 리모컨의 도커 소켓을 사용하는 것이지만 그렇게 작동하지 않았습니다.

@EricJizbaMSFT 기본적으로 SSH를 통한 원격 도커 소켓과 WSL 및/또는 컨테이너용 로컬 소켓을 사용할 것으로 예상됩니다. 이는 현재 WSL/컨테이너 개발 시나리오에서 도커 바이너리를 Windows TCP 포트용 도커에 연결해야 하므로 기본적으로 로컬 도커를 사용하기 때문입니다.

약간의 사전 생각. WSL 2가 나오면 사용자는 WSL 자체 내의 원격 도커 소켓에 연결하기를 원할 수 있습니다. 이것이 기본 설정에 영향을 미치는지 확실하지 않지만 사용자가 기본 설정을 직접 구성해야 할 필요성을 강조합니다.

@egamma 그래서 package.json에서 "ui" 또는 "workspace" 중 하나의 기본값만 지정할 수 있다는 말씀이신가요? 그것은 이해할 수 있지만 기본값을 결정해야 합니다.

기본값은 현재 "ui"로 유지됩니다.

#924에서 사용자가 기본적으로 "작업 공간"으로 설정하기를 기대한다는 피드백을 받았습니다.

이것은 훌륭한 피드백이지만 과거에 이 기본값을 시도했지만 제대로 작동하지 않았습니다(피드백을 알아낼 수 있음). UI 확장은 또한 사용 가능하고 각 컨테이너에 설치할 필요가 없다는 이점이 있습니다. 이러한 이유로 우리의 제안은 도커 확장이 현재 UI 확장으로 남아 있다는 것입니다. 양쪽에서 실행할 수 있는 확장 프로그램의 개선 사항에 대해 논의하고 있습니다(예: Chrome 디버거 확장 프로그램도 이 버킷에 속함).

@pd93 도커 확장을 UI 확장으로 계속 실행하려고 시도했지만 SSH를 통해 원격 도커 소켓을 가리키도록 docker.host 설정을 정의했습니까?

나는 Docker를 WSL2에서 실행하고 있습니다(훌륭한 BTW를 실행하는 것 같습니다). 그래서 자연스럽게 설정하려고 했습니다.
"docker.host": "/var/run/docker.sock" 하지만 오류가 발생합니다.

@benc-uk @pd93 @egamma 예, WSL2는 원격 VM에서 실행하는 것처럼 느껴질 것입니다. 내 내기입니다. Windows에서 특정 코드를 배치하지 않는 한 Linux OS에 로컬인 소켓은 Windows에 표시되지 않습니다. -- 그리고 그것들은 명명된 파이프로도 번역되어야 합니다. (WSL1에서는 그렇게 하지 않았습니다. Docker TCP 포트를 노출해야 했습니다.)

더 많은 것을 보려면 WSL2 시스템을 가동해야 합니다. 하지만 내 생각은 WSL2에 대한 것이므로 작업 공간 확장으로 실행되는 옵션을 원할 것입니다.

관련 메모에서 Remote - Containers 확장에서 이것은 아마도 원격 도커 호스트처럼 보일 것입니다(최적화되지는 않았지만 지원). 활용에 따라 해당 시나리오의 우선 순위를 높일 수 있습니다.

넣어 고정했습니다

    "remote.extensionKind": {
        "peterjausovec.vscode-docker": "workspace"
    }

내 사용자 settings.json에서 WSL에서 원격으로 확장을 강제 실행하고 docker.host 또는 DOCKER_HOST 환경 변수에 대해 아무 것도 설정하지 않았습니다. 소켓을 자동으로 선택합니다.

@benc-uk 안녕하세요, 원격 호스트에 docker가 설치되어 있고 로컬 컴퓨터가 설치되어 있지 않은 경우 remote-ssh를 사용하여 원격 개발 서버에 연결한 다음 원격 컨테이너 모드로 원격 서버의 docker를 사용할 수 있습니까? 로컬 도커처럼 작동하도록 합니까? 원격 컨테이너 모드를 사용하려면 로컬 컴퓨터에 도커를 설치해야 합니까?

안녕하세요, 원격 호스트에 도커가 설치되어 있고 로컬 컴퓨터가 설치되어 있지 않은 경우 원격 ssh를 사용하여 원격 개발 서버에 연결한 다음 원격 컨테이너 모드로 원격 서버의 도커를 사용하여 작동하도록 할 수 있습니까? 로컬 도커처럼? 원격 컨테이너 모드를 사용하려면 로컬 컴퓨터에 도커를 설치해야 합니까?

원격 - 컨테이너 확장을 사용하려면 로컬에서 Docker CLI가 필요합니다. 그러나 위에서 설명한 "remote.extensionKind"를 사용하여 로컬 확장 없이 원격 - SSH와 함께 Docker 확장을 사용할 수 있습니다.

원격 도커 호스트에서 원격 - 컨테이너 사용에 대한 자세한 내용은 여기를 참조하세요.

안녕하세요, 원격 호스트에 도커가 설치되어 있고 로컬 컴퓨터가 설치되어 있지 않은 경우 원격 ssh를 사용하여 원격 개발 서버에 연결한 다음 원격 컨테이너 모드로 원격 서버의 도커를 사용하여 작동하도록 할 수 있습니까? 로컬 도커처럼? 원격 컨테이너 모드를 사용하려면 로컬 컴퓨터에 도커를 설치해야 합니까?

원격 - 컨테이너 확장을 사용하려면 로컬에서 Docker CLI가 필요합니다. 그러나 위에서 설명한 "remote.extensionKind"를 사용하여 로컬 확장 없이 원격 - SSH와 함께 Docker 확장을 사용할 수 있습니다.

원격 도커 호스트에서 원격 - 컨테이너 사용에 대한 자세한 내용은 여기를 참조하세요.

그러나 내가 원하는 기능은 로컬 컴퓨터 가 도커를 설치하지 않고 원격 컴퓨터 가 도커를 설치한다는 것입니다. 내 로컬 컴퓨터가 remote-ssh 를 통해 원격 컴퓨터에 연결된 후 원격 컴퓨터에서 원격 컨테이너 기능이 사용되며 동작은 로컬 컴퓨터 에서 원격 컨테이너 를 사용하는 것과 동일합니다.

"WSL 내에서 도커를 실행하는 기능은 최근에 나온 것이며 얼마나 잘 지원되는지 불분명합니다"라는 의견에 대한 관찰일 뿐입니다.

Docker는 최근 Windows 10에서 Docker의 미래에 대해 게시했으며 요약은 - WSL(예: WSL v2)에서 Docker를 실행하는 것이 앞으로 Docker를 실행하는 기본 방법이 될 것입니다.
https://engineering.docker.com/2019/06/docker-hearts-wsl-2/

WSL에서 실행되는 Docker를 지원하는 것이 매우 중요하다고 생각합니다.

참고로 현재 계획은 기본값을 "UI"에서 "Workspace"로 변경하는 것입니다.

"UI"의 기본값이 의미가 있는 유일한 시나리오는 Dev Container 시나리오입니다. 그러나 Docker는 Dev Container의 "UI" 확장으로 보는 Docker보다 훨씬 더 매력적인 SSH/WSL의 "Workspace" 확장으로 간주됩니다. 전자는 VS Code Remote가 출시되기 전에는 불가능했던 새로운 기능을 가능하게 합니다. 후자는 로컬 VS Code 인스턴스로 이미 달성할 수 있는 것과 동일한 기능을 제공합니다.

또한 사용자가 원격 컴퓨터에서 도커 확장을 실행하기를 기대하고 로컬에서 원격으로 전환하는 방법이 명확하지 않다는 피드백 을 계속 받고 있습니다.

@egamma 당신이 "UI"의 기본값을 옹호하는 이 스레드의 주요 인물인 것 같으니 부담 없이 참여해 주십시오. 귀하의 의견과 관련하여:

이것은 훌륭한 피드백이지만 과거에 이 기본값을 시도했지만 제대로 작동하지 않았습니다(피드백을 알아낼 수 있음).

피드백을 파헤칠 수 있다면 좋을 것입니다. 피드백이 Dev Container 시나리오와 관련이 있다고 생각합니다. 우리는 그것이 완벽할 것이라고 기대하지 않지만 기본적으로 "Workspace"(오류 메시지 지우기 등)로 설정되어 있을 때 가능한 한 고통 없이 만들기를 희망합니다.

UI 확장은 또한 사용 가능하고 각 컨테이너에 설치할 필요가 없다는 이점이 있습니다.

나는 당신의 요점을 알지만 이것이 오늘날 VS Code Remote와 함께 대다수의 확장이 작동하는 방식이므로 거래 차단기처럼 보이지 않습니다.

참고로 현재 계획은 기본값을 "UI"에서 "Workspace"로 변경하는 것입니다.

원격 SSH/WSL 환경에서 모든 작업을 수행했기 때문에 최근에 이 확장을 사용하지 않았습니다. 이것은 좋은 소식입니다!

@pd93 기본값에 관계없이 위에서 언급한 설정으로 SSH/WSL 환경에서 이 확장을 사용할 수 있어야 합니다.

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": "workspace"
}

@EricJizbaMSFT 이것은 원격 개발에서 작동하지만 로컬에서 작업하지만 도커용으로 wsl만 사용하는 시나리오는 어떻습니까? 현재 기술 미리 보기에서는 아무 것도 표시되지 않습니다. 도커 컨텍스트를 지원할 계획이 있습니까?

@ksawerykarwacki 위의 설정을 시도 했습니까? "workspace"를 수행하여 도커 확장을 WSL에서 실행하거나 "ui"를 수행하여 WSL 외부에서 실행할 수 있습니다. 참고로 VS Code를 변경한 후에는 다시 로드해야 합니다.

다음을 사용할 때 SSH 환경에서 내 모든 컨테이너와 이미지를 볼 수 있습니다.

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": "workspace"
}

이미지 실행, 컨테이너 로그 보기, 컨테이너 중지 및 셸 연결은 작동하지만 실행 중인 컨테이너를 마우스 오른쪽 버튼으로 클릭하고 'Visual Studio 코드 첨부'를 선택하는 것만으로는 작동하지 않습니다. 내 호스트 시스템에 docker cli가 없기 때문에 실패합니다.

내 원격(ssh)에서 '작업 공간' 모드로 확장을 실행하고 있기 때문에 이 목적으로도 원격 docker cli를 사용하는 방법이 있습니까?

@parence "Attach Visual Studio Code" 명령은 다른 확장의 일부이며 해당 저장소는 https://github.com/Microsoft/vscode-remote-release입니다. 거기에 해당 명령에 대한 피드백을 제출할 수 있습니까?