Open pwinston opened 4 years ago
Just thinking out loud. That problem should be solved by a docker-machine plugin or similar.
+1 for this request.
The list of docker hosts is governed by the docker context. You can create multiple docker contexts using docker context create and choose one of them as a default using docker context set-default. Each context may define the certain host or delegate host resolution to the DOCKER_HOST environment variable. Docker context use is used for switching between hosts. Deployment of dependent containers to different hosts requires the creation of overlay network because default regular bridge network or network defined in the compose file doesn't allow cross host communication. This is a part of the core docker specification. Every application which uses docker must conform with this specification !!! Indeed, the Docker desktop implementation of the docker context is buggy but it doesn't justify further docker spec violations.
I think the spirit of this request can be resolved by making what @PavelSosin-320 said more directly supported / documented.
Step 1: Create a docker context (see docker docs)
Step 2 (optional): If you want to be able to view your contexts in vscode that is part of the docker extension ms-azuretools.vscode-docker
Step 3: Note sure how to achieve this yet, but somehow configure the Remote Development extension to make use of your docker contexts
To ease "step 3" this feature request could then be renamed 'Add level of hierarchy to "Containers" menu of Remote Explorer to populate all containers on all configured contexts"
@chrmarti Shall I make a new issue to request that?
The docker context is one of the core concepts of Docker. It solves the long list of requirements starting from deployment consistency - communicating containers are deployed to the same node and cluster to the low maintenance cost - created upon Docker installation with default values and once created it serves all client types consistently. Then, it can be easily shared. Unfortunately, in my VSCode version, I found only the Read-only context view.
@chrmarti I think that the Docker VS Code plugin will be always the companion plugin for Remote-docker dev containers plugin which can solve many PRs related to Docker images, containers, contexts, networks, volumes management without single line of additional coding. The only gap which I see is the fast switch to the corresponding Docker plugin view. Since Docker plugin already provides references to the Docker documentation it will save the documentation development time wasted on repeating explanations of the docker concepts and architecture.
My understanding is that Docker contexts are purely frontend stuff. The containers deployed have no idea about contexts. To integrate docker contexts would require just to access the docker configuration directory in the user home directory.
@hholst80 You are 100% correct. Actually VSCode July release already contains everything that you need. See documentation VSCode Docker plugin "Connect to Remote Docker over SSH" documentation topic and blogpost Context - blog.mikedir87.io The direct access to the docker context file is not so good idea due to security reasons. It is better to use what Docker offers.
Does anyone make any progress on this problem?
I am also interested in this request.
This could be designed by giving the Remote Explorer one more level in its hierarchy tree at the top. The top-most level would be a list of hosts, It would be possible to to add and remove hosts there. Then beneath a particular host the existing Containers tree would be displayed. If a DOCKER_HOST environment variable exists, a default host would appear in that list of hosts.
any update on this request?
Two years ago I didn't think I'd need this feature. This feature would make my workflow much more easier now!
any update on this request?
Rather than one global
docker.host
setting, the Remote Explorer in the "Container" view should have a way to add multiple docker hosts. So that you can navigate to running containers on any of those remote hosts. So that you can choose among remote hosts that you care about.Today one global docker.host setting means you have to reconfigure to just attach to a container on a different remote host.