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.

[afterthought]

I want to point out that the same conflict exists for Minikube.

{ "Type": "volume", "Source": "minikube-config", "Target": "/home/vscode/.minikube" }

[Chuxel]

To close the loop, this is also a problem for the dev container features preview for docker-in-docker in particular as described in microsoft/vscode-dev-containers#1249. We'd want to be able to use this to give the volume a unique name to avoid it.

[stuartleeks]

@Chuxel - I've just hit this issue using the docker-in-docker container feature to install docker. In an earlier comment on this issue you mentioned changing the config. Is that possible with the docker-in-docker container feature?

[Chuxel]

@stuartleeks No - tho IMHO, this is one of the things we have to have to "GA" features. //cc @edgonmsft @joshspicer @chrmarti @bamurtaugh

[stuartleeks]

Is there a decision on what identifier/name should be used for the volume name? I have a couple of features I'd like to create that also need this functionality 😄

[Chuxel]

This was raised as devcontainers/spec#62 in the dev container spec to zero in on a specific solution since it would apply to any tool implementing the specification.

[gdlol]

For those who can't wait, below is a workaround utilizing the fact that Docker Compose prepends directory name to named volumes:

Assuming an existing .devcontainer/Dockerfile, add the below 2 files:

• .devcontainer/daemon.json

  {
      "data-root": "/var/lib/dind"
  }

• .devcontainer/docker-compose.devcontainer.yml

  services:
    devcontainer:
      build:
        dockerfile: Dockerfile
      init: true
      volumes:
        - ./daemon.json:/etc/docker/daemon.json:ro
        - var-lib-dind:/var/lib/dind
        - ..:/workspace
  volumes:
    var-lib-dind:

Edit .devcontainer/devcontainer.json:

{
	// "name": ...,
	"dockerComposeFile": "docker-compose.devcontainer.yml",
	"service": "devcontainer",
	"workspaceFolder": "/workspace",
	"overrideCommand": true,
	"features": {
		"docker-in-docker": "latest",
		// ...
	},
	// ...
}

See

• https://github.com/microsoft/vscode-dev-containers/blob/main/script-library/docs/docker-in-docker.md
• https://code.visualstudio.com/docs/remote/create-dev-container#_use-docker-compose

[Chuxel]

This has been resolved in v2 of the docker-in-docker Feature for a bit now.

Update your existing references as follows:

"features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
}

However, note that this will generate a new volume name, so the existing volume will no longer be used. If you need to keep your container contents around in one container, then stick with version 1 until you are ready to switch.