docker.host ignored in docker-build task.

[MicahZoltu]

It appears that the docker-build task type is completely ignoring docker.host setting, as well as DOCKER_HOST environment variable added to the task.

What I Have Done

• I have docker desktop installed on the local host but it is not running.
• I have docker installed on the remote host.
• I have an SSH tunnel from my localhost to the remote host like ssh -NL localhost:2376:/var/run/docker.sock -F C:\path\to\ssh\config user@host.
• In VS Code I have set the docker.host setting to tcp://localhost:2376.

What Works

• From a terminal on the local host I can successfully run docker -H tcp://localhost:2376 version and get back server and client version information.
• From a terminal on the local host I can successfully run DOCKER_HOST=tcp://localhost:2376 docker version and get back server and client information.
• In VS Code I can see docker containers and images in the Docker extension side bar.

What Does Not Work

{
	"version": "2.0.0",
	"tasks": [
		{
			"type": "docker-build",
			"label": "docker-build",
			"platform": "node",
			"dockerBuild": {
				"dockerfile": "${workspaceFolder}/Dockerfile",
				"context": "${workspaceFolder}",
				"pull": true
			}
		},
	],
}

Trying to run this task results in an error like:

error during connect: This error may indicate that the docker daemon is not running.: <redacted for brevity>: open //./pipe/docker_engine: The system cannot find the file specified.
The terminal process terminated with exit code: 1.

Failed Workarounds

• I tried adding "options": { "env": { "DOCKER_HOST": "tcp://localhost:2376" } }, to the task, but this did not resolve the issue.
• I tried adding "customOptions": "-H tcp://localhost:2376" to the dockerBuild object in the task, but this did not resolve the issue (it puts it in the wrong place, option must go after docker and before build).
• I tried starting Docker Desktop locally, but this just results in the build happening on my localhost rather than the remote host.

What I Expected

I expected that setting docker.host would result in the docker-build task attempting to connect to the configured docker.host rather than trying to connect to a local docker daemon. I further expected that setting DOCKER_HOST environment variable in the task configuration would cause docker to run using that environment and thus run against the remote host.

Why I Am Doing it The Hard Way

ssh:// links in VSCode tools (like VSCode Remote and VSCode Docker) do not support custom SSH config paths and I do not have a working Config at %USERPROFILE%/.ssh/config. In some cases I can specify a custom SSH config file via configuration (like VSCode Remote - SSH) but in other tools like VSCode Docker I cannot, so I have to resort to creating an SSH tunnel and then using docker "locally".

[MicahZoltu]

This comment seems very relevant:

vscode-docker/src/tasks/DockerPseudoterminal.ts

Line 66 in b4ed4ce

// TODO: Maybe support remote Docker hosts and do addDockerSettingsToEnvironment?

At the least it feels like task environment variables should actually be applied.

[MicahZoltu]

I believe the environment variables could be integrated pretty easily by passing them in here:

vscode-docker/src/tasks/DockerPseudoterminal.ts

Line 69 in b4ed4ce

{ cwd: folder.uri.fsPath },

{ cwd: folder.uri.fsPath, env: environmentVariables },

Of course this would require passing environment variables from the task definition into the executeCommandInTerminal. That function appears to be called from three places, and all three places SHOULD be passing task environment variables in so I think this would be a clean and correct fix that provides a workaround to the failure of docker-build to recognize docker.host setting

Even ignoring the inability to set docker.host, I think it is worthwhile to fix the problem of

docker-build, docker-compose, and docker-run tasks should respect task environment variables

[bwateratmsft]

Thank you for the detailed investigation! Indeed you are correct in pointing out that comment--at the time we intentionally did not pass in DOCKER_HOST / docker.host. The reason was that the docker-build and docker-run tasks were primarily intended for debugging. Since debugging .NET and Python requires numerous volume mappings, which don't work in remote contexts, we did not implement this at the time.

That said, these tasks aren't meant exclusively for debugging--we tried to design them to be as general-purpose as possible. So, I think it's definitely a valid scenario to apply the environment variables and/or Docker context information. We should have some useful error messaging if volumes are used, since that will not work.

In the meantime, as a workaround you may be able to use command customization as an alternative to the docker-build task. You can also set up the command in the workspace's .vscode/settings.json file, so that it is automatically used when the "Docker Images: Build Image..." palette command is run within that workspace. You could also use a generic shell task.

Regarding the task environment variables, that was for templating in environment variables in the task--e.g. you could use ${env:foo} anywhere in a task definition and it would get resolved as the local system's value for foo. That was initially not working since we could not use VSCode's built-in variable resolution, but is now fixed. The env parameter in the docker-run task is for applying that environment variable into the running container, not using it to run the docker run command. It is equivalent to the -e foo=bar argument given to a docker run command.

[MicahZoltu]

tasks were primarily intended for debugging. Since debugging .NET and Python requires numerous volume mappings, which don't work in remote contexts, we did not implement this at the time.

Hmm, I was able to work around this problem with Docker contexts and was able to debug remotely just fine, though admittedly it was TS and not Python or C#. Is there a reason that this shouldn't work or I should avoid it? I will admit that it was a bit of a pain to get setup because the system doesn't seem designed for debugging production docker images (like it doesn't specify entrypoint and instead specifies command which doesn't do the right thing when working with a production Dockerfile).

It does look like command customization will be a much better fit for my needs than docker contexts, so thanks for that insight!

Regarding the task environment variables, that was for templating in environment variables in the task--e.g. you could use ${env:foo} anywhere in a task definition and it would get resolved as the local system's value for foo. That was initially not working since we could not use VSCode's built-in variable resolution, but is now fixed. The env parameter in the docker-run task is for applying that environment variable into the running container, not using it to run the docker run command. It is equivalent to the -e foo=bar argument given to a docker run command.

Ah, so there currently isn't any way to specify environment variables for the docker build/compose/run environment? That explains why none of those worked. Thanks for clearing that up.

[bwateratmsft]

TypeScript (well, Node projects in particular) should work fine for debugging remotely as it does not use any volume mappings. We're currently looking into ways to reduce or eliminate the use of volume mapping in debugging, because it also is relevant for making debugging work in GitHub Codespaces--Python seems attainable but .NET is probably still far off.

[bwateratmsft]

This is now released in Docker extension version 1.10.0.