Developing in Devcontainers

A devcontainer is a Docker container that contains your code and development environment. Most modern IDEs support connecting to a devcontainer for development. This allows you to develop against a stable environment that is not dependent on the configuration of the rest of your host system.

Devcontainers are extremely flexible and can be configured in many ways via devcontainer.json, from running in GitHub Codespaces to bind-mounting your repo directory, to cloning a repo into a dedicated Docker volume.

Bind-Mounting Code

You can configure your devcontainer to simply bind-mount a directory from the Linux VM (usually mounted into the VM from your host filesystem). This is the simplest way to work on code in a devcontainer but it comes with some downsides.

Pros:

  • Dead simple. Just configure the devcontainer to bind-mount the directory.

Cons:

  • Requires you to first mount the directory into your Linux VM running Docker (see Advanced Docker Configuration for more details on why this is a bad idea).

  • Bind-mounts are slow because file system changes are propagated through layers of OS translation from container, to VM, to host.

Volume-Mounting Code

Alternatively, you can store your repo code (or really anything you want to work on) inside a Docker volume that lives entirely inside the Linux VM. Some IDEs (e.g. VSCode) actually provide a UI for this workflow, which clones a remote repository into a volume and then mounts that volume into a devcontainer. If the repo you clone contains a .devcontainer/devcontainer.json file, it uses that configuration. If the repo does not come with a devcontainer configuration, VSCode will prompt you to create one.

Pros:

  • Fast! Volumes do not require OS filesystem layer translation so everything will feel snappier

  • Better isolation from host. You can avoid mounting your host filesystem into your Linux VM.

Cons:

  • Ephemeral. If you delete your docker volume, your repo is gone. This may not be a problem if you push everything to a git remote but any .gitignored files will be gone.

  • Less flexible. You don’t get free access to your host filesystem. You only get your repo.

SSH and GPG Keys

In pretty much any dev environment, you need access to SSH keys and GPG keys for authenticating with repositories and signing commits. But usually, these keys live on your host machine and it’s bad practice to be copying keys around.

Luckily, in much the same way that Docker forwards docker.sock through to your host system, you can forward your SSH auth socket into your Linux VM as well as your GPG agent socket. In Colima this is as simple as setting forwardAgent: true in your colima.yaml configuration. VSCode will automatically pick these up and provide access to your SSH keys and GPG keys inside your devcontainer.