How to use Docker in VSCode DevContainer

Creating a DevContainer

First, execute > Remote-Containers: Add Development Container Configuration Files ... in the command palette to create the DevContainer configuration file. At this time, you can select a template, so select Docker from Docker (Docker from Docker Compose if you want to run DevContainer with docker-compose).

Now you can use Docker inside the container by running > Remote-Containers: Reopen in Container.

If you want to install some additional language etc., it is easy to edit .devcontainer / Dockerfile to change the base image. You can use any Debian or Ubuntu-based image. The following is an example based on the official DevContainer image for the Go language.

.devcontainer/Dockerfile

# Note: You can use any Debian/Ubuntu based image you want. 
FROM mcr.microsoft.com/vscode/devcontainers/go:1.15

#The following is omitted

Use Docker's bind mount within DevContainer

Be careful when using bind mount within DevContainer. If you mount it without thinking as below, you will not find the file you should have mounted in the container.

$ docker run --rm -it -v $(pwd):/app golang:1.15 /bin/bash

This is because Docker in DevContainer shares the Docker running on the host. Therefore, when performing bind mount, it is necessary to specify the path of the host instead of the path in DevContainer.

To solve this problem, the following environment variables are defined by default in .devcontainer/devcontainer.json.

json:.devcontainer/devcontainer.json

{
	// ...

	// Use this environment variable if you need to bind mount your local source code into a new container.
	"remoteEnv": {
		"LOCAL_WORKSPACE_FOLDER": "${localWorkspaceFolder}"
	},

	// ...
}

$ {localWorkspaceFolder} is a variable available in devcontainer.json that means the host-side path of the open folder. This setting allows you to reference the host path from the environment variable LOCAL_WORKSPACE_FOLDER within DevContainer.

In other words, in order for the previous example to work correctly, do the following.

$ docker run --rm -it -v $LOCAL_WORKSPACE_FOLDER:/app golang:1.15 /bin/bash

Use docker-compose bind mount within DevContainer

Similarly for docker-compose, when using bind mount, it is necessary to specify the path on the host side.

The following settings do not work within DevContainer.

docker-compose.yml

version: "3"

services:
  app:
    image: ruby:2.7
    volumes:
      - .:/app
    working_dir: /app
    command: bundle exec rackup

It works by writing as follows.

docker-compose.yml

version: "3"

services:
  app:
    image: ruby:2.7
    volumes:
      - ${LOCAL_WORKSPACE_FOLDER}:/app
    working_dir: /app
    command: bundle exec rackup

However, if you write it like the above, you can not move it outside DevContainer. That is inconvenient, so it seems good to write the settings for DevContainer in docker-compose.override.yml [^ 1] etc. as follows.

[^ 1]: This is an optional configuration file that docker-compose loads by default. docker-compose.yml Overrides the settings in. See here for more information.

yaml:docker-compose.override.yml

services:
  app:
    volumes:
      - ${LOCAL_WORKSPACE_FOLDER}:/app

When the host OS is Windows

If the host OS is Windows, an error will occur even if you set using $ {LOCAL_WORKSPACE_FOLDER} as described above.

$ docker-compose up
ERROR: Named volume "c:\Users\frozenbonito\dev\docker-from-docker:/app" is used in service "app" but no declaration was found in the volumes section.

This is because if the host OS is Windows, the value of $ {localWorkspaceFolder} will be a Windows-style path and docker-compose will mistakenly recognize it as the Volume name.

There are two solutions.

Use the long syntax of volumes

Set the Windows path to docker-compose by using the long syntax in the volumes setting as shown below. It can be interpreted correctly.

yaml:docker-compose.override.yml

services:
  app:
    volumes:
      - type: bind
        source: ${LOCAL_WORKSPACE_FOLDER}
        target: /app

Set the environment variable COMPOSE_FORCE_WINDOWS_HOST

If the environment variable COMPOSE_FORCE_WINDOWS_HOST is set to true or 1, docker-compose looks like DevContainer. The HOST path in short syntax is now interpreted as a Windows path even if it is running in a Linux environment. Become.

It is a good idea to set it in devcontainer.json as follows.

json:.devcontainer/devcontainer.json

{
	// ...

	"remoteEnv": {
		"LOCAL_WORKSPACE_FOLDER": "${localWorkspaceFolder}",
		"COMPOSE_FORCE_WINDOWS_HOST": "true"
	},

	// ...
}