Comments (14)
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.
from cli.
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.
from cli.
I'm actually working on a Jenkins integration, but will share more about it in the spec discussions. Thanks @bamurtaugh
from cli.
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.
from cli.
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
from cli.
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. π
from cli.
@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?
from cli.
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.
from cli.
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!
from cli.
@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.
from cli.
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.
from cli.
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?
from cli.
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?
from cli.
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.
from cli.
Related Issues (20)
- [![Test Build Processes](https://github.com/wexkalebur/wordpress-develop/actions/workflows/test-build-processes.yml/badge.svg?branch=trunk)](https://github.com/wexkalebur/wordpress-develop/actions/workflows/test-build-processes.yml)
- Support updating lifecycle scripts on existing containers HOT 2
- Unable to build multi-platform images HOT 5
- Incorrect field used as mapping key for deserialization of 'mounts' in devcontainer.json HOT 1
- Image and feature digest pinning syntax inconsistency HOT 2
- Should `devcontainers/cli` uses `docker compose` always instead `docker-compose`? HOT 3
- Feature request: `@devcontainers/cli` as a docker CLI plugin
- Ability to provide version to publish HOT 6
- Speed up installing dotfiles by loading only latest commit
- project-name changed after updating 0.56 -> 0.60 HOT 10
- obtuse and confusing error with local feature under WSL HOT 4
- Feature Request: Allow devcontainer up to Start Only the Specified Service and Its Dependencies HOT 4
- Adding labels to containers build by devcontainer cli HOT 5
- `compose.yaml` `name` breaks when using vars `${VAR}` HOT 3
- Forward docker credentials from docker cred helper HOT 1
- Add option to get the info on running containers HOT 2
- Apply --remove-existing-containerβ before initializeCommand
- missing root cause of error HOT 2
- Error when devcontainer up HOT 2
- Push in quay.io/buildah/stable HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cli.