Add a docker.context setting for setting DOCKER_CONTEXT similar to docker.host

[segevfiner]

Add a docker.context setting for setting DOCKER_CONTEXT similar to docker.host for setting DOCKER_HOST. This will allow using docker contexts per window or project rather than globally.

This should probably also be supported by the Remote - Containers extension.

[PavelSosin-320]

It doesn't allow setting context per project because the current context is set by the docker context use ... . command The value is stored in the docker.config file in the User's profile folder. Indeed, it is possible to create as many contexts as needed, but the current context is used by all kinds and instances of docker tools used by the user. It ensures consistency rather than flexibility when development, deployment, and management of complex applications. Docker context also helps to store sensitive user-level information in a secure manner and transfer it from development to testing and deployment environment. It is very useful when the user works in a multitenant environment like the cloud-based development pipelines - nothing is shared among tenants.
The real-life example is Development on laptop -> testing on a shared server -> delivery to enterprise or global cluster.

[segevfiner]

There is definitely a matter of taste and preference here.

The global current context mechanism is convenient in some scenarios but can be inconvenient in others, such as wanting to have different windows/terminals that use different contexts at the same time.

Docker provides an environment variable and CLI flag to use a non-default/current context. kubectl only has a CLI flag which has often been annoying.

[bwateratmsft]

I think such a setting has equal value to DOCKER_HOST / docker.host. The scenarios @segevfiner lists (e.g. different context for different projects) make sense to me.

[bwateratmsft]

@segevfiner I thought of one existing capability of VSCode that might help in your scenario. VSCode has some settings (terminal.integrated.env.linux, terminal.integrated.env.osx, terminal.integrated.env.windows) that let you set environment variables used in terminal windows it creates. Setting DOCKER_CONTEXT here should make it so all of the Docker commands run in the terminal use the context you specify in that environment variable, and you can also have these VSCode settings in the workspace instead of the user settings, so that each workspace can use a different context automatically. Unfortunately this will not work for the Docker explorer view, which is still global, but at least the terminal commands should.

[bwateratmsft]

Running into some difficulties with implementation. Dockerode is completely unaware of contexts so it will use whatever value we give it as the host. Since each extension host has its own Dockerode object, multiple windows of VSCode can talk to different hosts--no problem there.

With the new Docker SDK though, there's no equivalent I'm aware of to the --context flag on the CLI, so you have to set the global context to whatever you want--which means, for multiple VSCode windows using the new SDK, either you cannot support multiple contexts, or you have to set the context before every single call (very not ideal).

I opened docker/node-sdk#42 to get something like a --context flag for new SDK requests, which should solve this issue.

[bwateratmsft]

This is now fixed in Docker extension version 1.7.0.

[PavelSosin-320]

Docker context is a fully client-side feature and requires only one docker context use command per workspace switch
and it provides info containing docker-host as JSON for parsing convinience. There is no reason to correct SDK if it is not used directly.
C:\WINDOWS\system32>docker context inspect docker-wsl
[_
{
"Name": "docker-wsl",
"Metadata": {
"StackOrchestrator": "swarm"
},
"Endpoints": {
"docker": {
"Host": "tcp://localhost:2375",
"SkipTLSVerify": false
}
},
"TLSMaterial": {},
"Storage": {
"MetadataPath": "C:\Users\Pavel\.docker\contexts\meta\35eb697f1e12ae0856ed94eeba5d8b2f6fe336242ac93c350842ad818fb2a73d",
"TLSPath": "C:\Users\Pavel\.docker\contexts\tls\35eb697f1e12ae0856ed94eeba5d8b2f6fe336242ac93c350842ad818fb2a73d"
}
}
]
It has a full bag of pleasant features like TLS materials provision, ability to use Docker without Docker if somebody has Minikube from Ubuntu or RedHat.
It can say how to deploy a development container, which docker command to use without any configuration.