5 ms·

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.

sph 4y ago
Same, but I use podman, and a simple k8s compatible manifest that I start with "podman play kube manifest.yml" It supports named volumes, configmaps and that is enough for local dev environments, and editor agnostic.
pid-1 4y ago
If you need to... - 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.
- adriancr 4y ago
  > - Mount volumes in your dev container > - 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.
buttersbrian 4y ago
Not used Codespaces, but gitpod.io. 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.

sph 4y ago

Same, but I use podman, and a simple k8s compatible manifest that I start with "podman play kube manifest.yml" It supports named volumes, configmaps and that is enough for local dev environments, and editor agnostic.

pid-1 4y ago

If you need to... - 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.

adriancr 4y ago
> - Mount volumes in your dev container > - 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.

buttersbrian 4y ago

Not used Codespaces, but gitpod.io. 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.