A reproducible development environment built on top of docker containers.
In a file named .devcontainer/devcontainer.json:
Of course there are more options. Lifecycle hooks. Building
an image. Using a compose project. Adding features.
A customizations field to configure tools.
This is honestly mostly for Microsoft and Github tools. Is that really a bad thing?
Features are the meta configuration of devcontainers. Allowing you to mix / merge / share
configuration across many projects. A feature can do everything a devcontainer can and has
a well defined hook into the build system: install.sh.
Please read the rest of the files in this gist. This example explores some of the more advanced features of devcontainers.
- Creating a custom user, this one is named "dave".
- Install the Github CLI as a feature.
- Creates a one-off feature for the bats-core project. This is NOT necessary. There's many ways to accomplish this.
- Builds a custom image starting at
debian:bookworm-slim. - If using vscode, installs extensions useful for bash editing.
- If using vscode, sets the default profile of the terminal to
bash.
.devcontainer/
├── devcontainer.json
├── Dockerfile
└── ysap
└── features
└── bats-core
├── devcontainer-feature.json
└── install.sh
Note, because gists do not support directories, files are using double underscore as separators. That is .devcontainer__devcontainer.json means .devcontainer/devcontainer.json.
{ // Give a name to the "workspace" "name": "Debian", // Reference any docker image, this is a pre-configured image from microsoft specifically for devcontainers "image": "mcr.microsoft.com/devcontainers/base:1-bookworm", // The default user for the workspace, most microsoft images include a user named "vscode" "remoteUser": "vscode" }