Repository navigation
[Announcement] Dev Container CLI Feedback #7
Description
Hi everyone 👋! We'd love to hear your feedback as you review and try out the dev container CLI. This can include:
- Commenting questions or feedback in this issue
- Opening a new Discussion in the spec repo: https://github.com/devcontainers/spec/discussions
- Opening a new issue with a bug or feature request
- Opening a PR to contribute
We'll also share issues or topics we'd like your feedback on. For instance, we'd greatly appreciate your thoughts on publishing the devcontainer.json schema.
There is an FAQ for the specification here.
We’re incredibly excited for the future of container-based development and can’t wait to hear your feedback. Thank you!
Activity
aih commentedon May 18, 2022
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.
chrmarti commentedon May 19, 2022
Ari Hershowitz (@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?chazragg commentedon Jun 10, 2022
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
shadycuz commentedon Jun 11, 2022
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.
I mean I guess people could spin up redis/mysql and what not in their devcontainer but they might prefer to have multiple containers.
nabeelsherazi commentedon Jun 11, 2022
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."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!
chrmarti commentedon Jun 13, 2022
Levi (@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.
Nabeel Sherazi (@nabeelsherazi) We are indeed using
docker buildto build the image, so a.dockerignorefile can be placed in the context folder. When thedevcontainer.jsondoes not specify a context folder, the Dockerfile's folder is used as the context.bamurtaugh commentedon Jun 13, 2022
Thanks Charles Ragg (@chazragg) Levi (@shadycuz) Nabeel Sherazi (@nabeelsherazi) for the great feedback and questions!
Levi (@shadycuz) - As Christof Marti (@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.
bamurtaugh commentedon Jun 27, 2022
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. 😄
shadycuz commentedon Jun 27, 2022
I'm actually working on a Jenkins integration, but will share more about it in the spec discussions. Thanks Brigit Murtaugh (@bamurtaugh)
maticmeznar commentedon Aug 5, 2022
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 installcommand 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 thatnpmhas 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.Clockwork-Muse commentedon Mar 6, 2023
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?
bamurtaugh commentedon Mar 7, 2023
Thanks for sharing this Stephen A. Imhoff (@Clockwork-Muse)!
joshspicer Samruddhi Khandale (@samruddhikhandale) Christof Marti (@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?
Clockwork-Muse commentedon Mar 7, 2023
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
--privilegedflag or without mapping the host docker daemon. Due to this, it would be nice if the CLI could support something like kaniko.shanduur commentedon Oct 29, 2023
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.
vietj commentedon Aug 14, 2024
where is the documentation of this tool that goes beyond the README ?
bamurtaugh commentedon Aug 14, 2024
Julien Viet (@vietj) thanks for the question! I'd recommend checking out our website for everything dev containers: https://containers.dev/.
paul-michalik commentedon Nov 25, 2024
This can't be stressed enough! Just out of interest, has anyone found a workaround for this?
j2udev commentedon Jan 9, 2025
Third this. I'm attempting to start building devcontainers/features/templates for my company and our pipelines can't use docker. Additionally, due to some internal red tape, I can't even easily set up an external runner that does have docker. Kind of stuck on the CI/CD here.
j2udev commentedon Jan 9, 2025
At the risk of additional noise... going to third this. I recognize it would be a larger endeavor, but this CLI inherently having a dependency on Node/NPM is not ideal. As a suggestion, Go is perfect for building CLIs and can easily package binaries with no additional dependencies.
remcokranenburg commentedon Oct 23, 2025
Note that it is not absolutely necessary to drop TypeScript just to achieve a self-contained binary:
Adding that as an additional target would be much easier than a full rewrite into Go or Rust.