This is a very exciting project!

One of our greatest challenges in setting up a dev environment is providing the initial data sources, usually Sql database and files in a file system. Providing these easily has been the main hurdle to adopting a containerized dev setup
Our sources are on the order of 10Gb of data.
It would be great if the specification includes a clear path to linking data volumes and database containers and providing seed data, e.g. from S3, Azure cloud, GCP etc.

@aih Thanks for the feedback! Can you use the "initializeCommand" in the devcontainer.json for seeding or when the DB container starts up, check if seeding is needed?

Really looking forward to seeing the development of this project. dev containers have recently peaked my interest and I've been researching heavily into it but could not find many alternatives to VS code dev containers which 1) used docker (most used k8s), 2) did not rely on VS code. not all of our developers use VS code to have something independent is amazing.

most of my question are already github issues but just wanted to show some support. Keep up the good work

I really enjoy devcontainers, I use them in all my opensource projects and I tell all my friends about the feature.

I don't really understand the CLI aspect though, whats it for? I love that vscode runs inside my devcontainer, but if it wasn't for that, then a devcontainer.json and this CLI tool feels like a less featureful docker compose.

Which is kinda what the specification needs to become, docker compose but native in my code editor. Which doesn't seem to be on the road map according to the readme.

un-orchestrated single container option – so that they can be used as coding environments or for continuous integration and testing.

I mean I guess people could spin up redis/mysql and what not in their devcontainer but they might prefer to have multiple containers.

Great project! I'm slowly converting my team over to devcontainers. I had a question and I'm not sure if this is the right place to ask it, but it seems like this is the home of folks working on the devcontainer spec, and this is the most general Q&A place I can find -- so here goes!
I was wondering what the effect of a .dockerignore file inside of .devcontainers/ is. I've seen it included in some projects with entries for build artifacts etc., but it seems like when the devcontainer.json just points to a single Dockerfile in the same directory, the build context is already only just the .devcontainer/ folder? I wasn't able to find any documentation about how this works, so these are the cases I was wondering about.

1. If devcontainer.json simply points to a Dockerfile in the same directory, is a .dockerignore file necessary?
2. If devcontainer.json points to a Dockerfile in the parent directory and has "context": "..", will a .dockerignore inside .devcontainer/ be used? Or would it just be the one inside .. as according to a regular Docker build?

Thank you!

@shadycuz If you are already using Remote-Containers, that might indeed be the most convenient way to start dev containers for you. Today, the CLI is powering the Remote-Containers extension for VS Code, GitHub Codespaces and the GitHub Action and Azure DevOps Task for running part of your Continuous Integration build in a dev container. We expect this list of usages of the Dev Container CLI to grow over time and are prepared to make additional changes to enable that.

@nabeelsherazi We are indeed using docker build to build the image, so a .dockerignore file can be placed in the context folder. When the devcontainer.json does not specify a context folder, the Dockerfile's folder is used as the context.

Thanks @chazragg @shadycuz @nabeelsherazi for the great feedback and questions!

@shadycuz - As @chrmarti mentions, it's perfectly acceptable (and expected) that Remote-Containers may be the right solution for sets of folks, especially those who want to use VS Code. With the open spec and CLI, we're seeking to open up this experience so that other tools/editors can support dev containers too, and folks can use dev containers in an expanding set of scenarios even beyond development, like CI and test automation.

A non-goal for devcontainer.json is to become another multi-container orchestrator format. Instead, it aims to enable development in containers regardless of how they are orchestrated. There's more information here: devcontainers/spec#10.

If it seems this topic (or others) could be better explained in our reference material, or if there was anything mentioned in reference materials that was unclear, please let us know, and we're happy to iterate.

I wanted to share that we recently enabled GitHub Discussions in the spec repo: https://github.com/devcontainers/spec/discussions.

If you'd like to provide feedback, ask questions, or connect with our team or others in the community on the spec, please feel free to open a Discussion there - we'd love to hear what you all have to say and how you're using or may use dev containers. 😄

I'm actually working on a Jenkins integration, but will share more about it in the spec discussions. Thanks @bamurtaugh

Two of the reasons I'm interested in the concept of devcontainers is that they provide a consistent development environment to developers and provides a security isolation between software development environment, the rest of the operating system and other development environments on the same system.

Unfortunately, to "install" this tool requires installing Node.js and then running npm install command which in the worst case scenario results in unauthorized entities having complete control over your system via a malicious library in the devcontainer's dependency graph. Design flaws in NPM like this one are one of the things devcontainers can help mitigate to an extend with security isolation. The problem is that npm has to be run outside of an isolated environment to install your tool.

I propose you compile and package devcontainer CLI into a single executable binary and then distribute that to users. This way users don't have to install Node.js nor run the npm install, effectively reducing the attack surface.

The main feature repository in this organization includes a custom ci script to generate feature documentation. Would moving documentation generation into the cli be something to be considered?

Thanks for sharing this @Clockwork-Muse!

@joshspicer @samruddhikhandale @chrmarti would be interested to hear what you think. My first thought is although Feature documentation is important, it might still make sense to keep as a separate script. Though I wonder if the CLI could have a command that acts as a wrapper and calls the CI script?

Thought of something else:

With the rise of rootless containers and kubernetes, it would be attractive to be able to run the CLI in scenarios where there may not be sufficient permissions to access a privileged docker context - for example, if the CLI is being run as part of a CI process inside a container, without the use of the --privileged flag or without mapping the host docker daemon. Due to this, it would be nice if the CLI could support something like kaniko.

I would love to be able to use devcontainers cli without need to install NPM/Node.js, e.g. as a single binary, that can be easily distributed in semi-air-gapped environment.

where is the documentation of this tool that goes beyond the README ?

@vietj thanks for the question! I'd recommend checking out our website for everything dev containers: https://containers.dev/.