Repository navigation
[Announcement] Dev Container CLI Feedback #7
Description
Activity
- pinned this issue
on May 11, 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.Reacted by Brigit Murtaugh, Suraj and Rok RoškarAri 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?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
Reacted by Christof Marti, Will Slattum and Brigit MurtaughI 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.- If devcontainer.json simply points to a Dockerfile in the same directory, is a .dockerignore file necessary?
- 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!
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.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.
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. 😄
Reacted by Ari Hershowitz and LeviI'm actually working on a Jenkins integration, but will share more about it in the spec discussions. Thanks Brigit Murtaugh (@bamurtaugh)
Reacted by Brigit Murtaugh, Christof Marti, franzzintgraf and Julio GonzalezTwo 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.Reacted by Levi, Suraj, Nate Scherer, eitsupi, Bobby Reynolds, Lennart Jern, Les Matheson, Lou Bichard, Piotr Łuczak, Luis Ibargüen and 16 moreReacted by Ben IofelReacted by Martin Milan and Spiritus2424Reacted by Cervac Petru, Spiritus2424 and ryanpodonnell1The 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 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?
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.Reacted by Rio Kierkels, Raphael, Morgante Pell, l.feng, Patrick Stöckle, Kris De Volder, Derek Ellis, Will Slattum, Nejc Habjan, Roger Meier and 6 moreI 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.
Reacted by Paul Michalik, Joshua Ward, Spiritus2424, Remco Kranenburg and Austin Praywhere is the documentation of this tool that goes beyond the README ?
Julien Viet (@vietj) thanks for the question! I'd recommend checking out our website for everything dev containers: https://containers.dev/.
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.This can't be stressed enough! Just out of interest, has anyone found a workaround for this?
Reacted by Joshua Ward and celestialorbThought 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.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.
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.
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.
Reacted by Spiritus2424, celestialorb, it-a-me, Roman, Beorn Facchini, Remco Kranenburg and Austin PrayReacted by Spiritus2424, Paul O'Fallon and Maxim KosovNote 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.
Reacted by David Stenglein
Hi everyone 👋! We'd love to hear your feedback as you review and try out the dev container CLI. This can include:
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!