When you’re utilizing dev containers as a part of your commonplace toolchain, you may create a library of options that may be shortly added to your container definitions. You possibly can customise off-the-shelf containers or shortly construct a brand new definition for a brand new mission, treating options as constructing blocks that sit on prime of an ordinary base container that’s been outlined for a selected stack.

The essential means of constructing a dev container makes lots of sense. It’s a top-down strategy, which wants to begin with architects and dev leads agreeing on a mission stack. You possibly can then discover a base platform picture, say .Web, within the VS Code container gallery. Upon getting that, you customise it on your mission, including new instruments by modifying the devcontainer.json in VS Code and by including predefined options. As soon as the container is able to use, deploy it and the mandatory VS Code instruments to your improvement crew.

Your native container host must be working Docker or not less than have a Docker-compliant CLI on prime of its engine. The CLI is essential right here, because the dev container works by way of it quite than needing direct entry to your container host. That’s each a profit and a downside: There’s no dependency on APIs and even on Docker itself. So long as a container atmosphere helps the Docker CLI, you should utilize it along with your dev containers. Nonetheless, if it doesn’t, you may’t. Which means there are points with different container engines, equivalent to Podman, which solely assist a subset of the Docker CLI. In fact, as dev containers is an open supply mission, there’s ongoing work to assist different container engines, and you can also make requests or submit code through GitHub.