Using dev containers
Once you’re using dev containers as part of your standard toolchain, you can create a library of features that can be quickly added to your container definitions. You can customize off-the-shelf containers or quickly build a new definition for a new project, treating features as building blocks that sit on top of a standard base container that’s been defined for a specific stack.
The basic process of building a dev container makes a lot of sense. It’s a top-down approach, which needs to start with architects and dev leads agreeing on a project stack. You can then find a base platform image, say .Net, in the VS Code container gallery. Once you have that, you customize it for your project, adding new tools by editing the devcontainer.json in VS Code and by adding predefined features. Once the container is ready to use, deploy it and the necessary VS Code tools to your development team.
Your local container host needs to be running Docker or at least have a Docker-compliant CLI on top of its engine. The CLI is key here, as the dev container works through it rather than needing direct access to your container host. That’s both a benefit and a drawback: There’s no dependency on APIs or even on Docker itself. As long as a container environment supports the Docker CLI, you can use it with your dev containers. However, if it doesn’t, you can’t. That means there are issues with alternative container engines, such as Podman, which only support a subset of the Docker CLI. Of course, as dev containers is an open source project, there’s ongoing work to support other container engines, and you can make requests or submit code via GitHub.
