Running multiple devcontainers with docker-in-docker in parallel fails, need unique volume name

[berndku]

A single devcontainer with docker-in-docker is running fine. If opening a second devcontainer with docker-in-docker on the same host in parallel, docker execution fails in the 2nd container.

• VSCode Version: 1.60.2
• Local OS Version: Windows 10 Pro 10.0.19042
• Reproduces in: Remote - Containers
• Name of Dev Container Definition with Issue: Docker-in-Docker

Steps to Reproduce:

1. Open devcontainer with docker-in-docker definition in first instance of VS Code
2. Run "docker ps" --> CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES --> works
3. Open a second VS Code instance and let the first VS Code Window continue to run in parallel.
4. Open a second devcontainer with a Docker-in-docker definition in the second instance of VS Code
5. Run "docker ps" --> Error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
6. If closing the first VS Code instance and rebuilding the second, then docker-in-docker works on the second instance.

[Chuxel]

@berndku You'll need to set a unique name for the volume name in the configuration if you are using two dev containers with docker-in-docker. @chrmarti, @joshspicer and I have discussed being able to generate a unique ID that can be referenced. If you use the same volume name with two in parallel they'll step on each other's data.

[chrmarti]

Looked into adding ${devcontainerName} for volume names, the problem there is that volume names cannot use all characters that are allowed in a dev container name and that name can easily change, so a different volume name would result. Maybe we could support using the value from an option for the volume name.

Originally posted by @chrmarti in #5442 (comment)

[Chuxel]

@chrmarti Wouldn't replacing those characters with a - do the trick? That's what I've been doing for things like publishing branch specific dev container images. For example. branch clantz/feature-1234 becomes clantz-feature-1234

For that matter, we could convert the string to base64 if we had to. Automation here is really useful since it works by default in that case.

[chrmarti]

I would ${devcontainerName} expect to be the name without replacements, we could introduce a different variable that indicates it's derived.

The problem remains that the user might change the name without being aware that this will result in a different volume being used. We are computing an image name from the local folder path and could look into using that and/or add an option to the feature to allow for a custom volume name.

[Chuxel]

@chrmarti True - it could be a general identifier. Largely a unique ID is needed and that's it.