I don't get why I need this rather than just a plain container/dockerfile. That is how I work today and that is my "devcontainer", no separate markup needed.
- Mount volumes in your dev container
- Run commands after the container is built
- Pass environment variables from the host to containers
- Specify which containers will be ran in a docker-compose definition and which one will host the vs code server
- Use arbitrary flags in docker run / docker build / docker-compose
You will end up with a Makefile or bash script that roughly looks like a .devcontainer.json file.
Devcontainer files are also neat from an UX pov because new devs can just click on "open remote" and wait. I've been using this feature since 2019 and it did wonders for project onboarding.
> - Pass environment variables from the host to containers
> - Specify which containers will be ran in a docker-compose definition and which one will host the vs code server
Docker compose yaml files are pretty cool to define these.
Whereas these are just asking for trouble/non-reproducible docker environment and could be part of container definitions:
> - Run commands after the container is built
> - Use arbitrary flags in docker run / docker build / docker-compose
The UX that you mention on the other hand is pretty cool:
Devcontainer files are also neat from an UX pov because new devs can just click on "open remote" and wait. I've been using this feature since 2019 and it did wonders for project onboarding.
It supports named volumes, configmaps and that is enough for local dev environments, and editor agnostic.
What you end up cobbling together to really create a fully fledged environment ends up being what the yaml does for you in a consistent manner.
Also, getting off of "DOCKER", and specifically "docker desktop" and its magic, is beneficial.