7 ms·

Development Containers

131 points by shcheklein 4y ago

mikaeluman 4y ago
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.
teeray 4y ago
Is this basically Nix derivations, but with a more familiar syntax? (Dockerfiles)
- jljljl 4y ago
  I don't believe they use Nix at all. Dev Containers are basically Docker Containers (either pulled from a repo or built from a Dockerfile) with some additional metadata attached so they can work as a Development Environment. Metadata includes stuff to configure debuggers, IDEs, etc.
  - whateveracct 4y ago
    I think the comment meant it does the same thing as Nix derivations. Not that it uses Nix.
- x98asfd 4y ago
  yeah don't really like all this. I mean if ppl are use to Dockfiles or dock compose files, then just stick with that can change the underlying tech to Nix, firejail, fire cracker or whatever. It is quite annoying to have a mega corp popping up with these different container tech that pretty much does the same thing.
- pid-1 4y ago
  While you can use nix derivations to build development containers, you still would need a Makefile / bash script specifying how to run them. The devcontainer spec combines 3 things: - How to build containers for a development environment (using Docker or docker-compose) - How to run containers for a development environment (volumes to mount, environment variables, commands to execute after containers are running, where the project will be mounted...) - Which VS Code configuration to install and use (including extensions) within the development environment
- intelVISA 4y ago
  Nix derivations: Microsoft E.E.E. edition.
djha-skin 4y ago
My coworker uses this a lot at work to solve the problem of keeping different software versions consistent across developer machines on the team. Being by Microsoft, this dovetails really well with Visual Studio Code. I find the CLI to be okay I guess for something written in JavaScript. I prefer ASDF generally[1] for solving this problem, since there's always a lot of fiddling you have to do with containers, but this is more cross platform so there's that. 1: https://asdf-vm.com https://asdf-vm.com
- WirelessGigabit 4y ago
  I really dislike asdf. It is supposed to be the hail marry, but it doesn't support .nvmrc with content like lts/hydrogen. Also, they don't have a pyenv venv plugin. So I'm still stuck with rbenv, nvm, jenv, pyenv and pyenv venv...
  - llanowarelves 4y ago
    Have you tried nix's or guix's shells? They can be used as v env for anything.
  - res0nat0r 4y ago
    Have you tried this? https://github.com/asdf-vm/asdf-nodejs#nvmrc-and-node-version-support https://github.com/asdf-vm/asdf-nodejs#nvmrc-and-node-versio... Also lts, lts-hydrogen, etc are available to install I can see when running `asdf list all nodejs`
shcheklein 4y ago
The way I see it - it's a really nice way to make reusable modules out of your Docker files (e.g. we need to install a tool and we need to run apt-get + some config, etc). And a simpler, JSON syntax to apply those modules on top of a base image. I love the experience so far, we've done a few features (modules) - e.g. this one to install `nvtop` to see GPU utilization [0] The whole CUDA + nvtop + (some other tools) setup for a project to be run on a remote machine (e.g. via VS Code) becomes like this [1] And that's enough to run ML training on GH Codespaces with GPU support. Super cool experience. [0] https://github.com/iterative/features/blob/main/src/nvtop/install.sh https://github.com/iterative/features/blob/main/src/nvtop/in... [1] https://github.com/shcheklein/hackathon/blob/main/.devcontainer.json https://github.com/shcheklein/hackathon/blob/main/.devcontai...
mshekow 4y ago
containers.dev is a spec created and only implemented by Microsoft (in Visual Studio [Code] and GitHub Codespaces). Tool vendors (of IDEs) decided to go to war, instead of collaborating, it seems. XKCD's "standards" comic seems to apply [0] here. As I've blogged about here [1], there are other specs such as Devfile.io or GitPod's proprietary gitpod.yml file. [0] https://xkcd.com/927/ https://xkcd.com/927/ [1] https://www.augmentedmind.de/2022/10/30/container-based-development-envs/ https://www.augmentedmind.de/2022/10/30/container-based-deve...
- asciimike 4y ago
  To be fair, GitPod claims they will support devcontainer.json: https://github.com/gitpod-io/gitpod/issues/7721 https://github.com/gitpod-io/gitpod/issues/7721
  - tiraz 4y ago
    Do they? It reads more like a request from the community, but without any statement from Gitpod itself.
- iddan 4y ago
  Sometimes you need to name something and give it a spec for others to implement it.
- panzerboy 4y ago
  Yeah, I really hope JetBrains would adopt this spec as well. So far they seem to be going in another direction.
fatih-erikli 4y ago
I wouldn't recommend. If a dev environment needs such containers you probably work in crap
- mixedCase 4y ago
  I'm more of a Nix guy for solving this particular issue, but even assuming you were right (I don't believe so), sometimes you do have to work on crap. And it's better if you have a more reproducible dev environment when doing it.
  - fatih-erikli 4y ago
    Working on crap and working in crap are different things. Working in crap: doing someones elses work Working on crap: doing some work on legacy
- sph 4y ago
  No, I simply do not want my workstation to be littered with dev dependencies that are used on a single project, or have to install nvm, rvm, asdf, to manage conflicting language runtimes. Nor I want to use Nix, not my jam, sorry. All I need is Emacs, and podman.
  - deleted 4y ago
    [deleted]
- adriancr 4y ago
  And what would you recommend? Also, if you fail to see the value in this, then I'd ask what you would use: - When you need to work on multiple products with different environments. - When you want to temporarily spin up development environments on powerful machines for parts of your work and rest of the time develop locally? - When you want to pass an identical environment to someone else and have it just work.
  - fatih-erikli 4y ago
    - When you need to work on multiple products with different environments. You interact with APIs. You don't have to install a database or another daemon to your local computer. - When you want to temporarily spin up development environments on powerful machines for parts of your work and rest of the time develop locally? This has never happened. - When you want to pass an identical environment to someone else and have it just work. All the dev stacks has something like package.json
filmgirlcw 4y ago
I’m a huge fan of devcontainers. If you use VS Code or Codespaces, it makes it really easy to do a remote environment exactly the same for everyone. I use them in workshops and it’s great. It’s an open standard and we’re starting to see more members of the community adopt it or integrate support into their stuff too (including some larger Nix players like devenv and Jetpack.io) and I really hope others adopt it too. For me, for however many years I’ve been using these (it’s at least 2 but it could be longer, time is a circle), it has definitely improved my QoL. Disclosure: I work at GitHub which uses devcontainers in Codespaces and I used to work at Microsoft which developed this and used it with VS Code and the amazing VS Code remote extension.
- intelVISA 4y ago
  Not seeing the value prop over something open like Nix, is there one?
  - thinkmassive 4y ago
    What’s not open about this specification and the open source utilities built to support it?
    - zamalek 4y ago
      The tools are not open source. You cannot use dev containers with e.g. vscodium
      - filmgirlcw 4y ago
        Sure you can. You technically can’t use the VS Code remote extension in Codium because of licensing reasons (tho people have packaged it for that marketplace anyway - and I’m not suggesting anyone do that, I am saying it has been done), but there is nothing stopping anyone from building a remote extension that uses the dev container spec. I’m not debating that that isn’t a lot of extra work, but the spec itself is absolutely open for anyone else to integrate. I’d posit that the reason we haven’t seen alternatives (to my knowledge) to remote extension because of how much work is involved when most people (maybe not you, but most people), are comfortable just turning off the telemetry flag in VS Code rather than using Codium. But if you’d rather use something like Nix, using something like devbox or devenv will achieve something similar to dev containers and that’s fine foo.
zokier 4y ago
Tbh I feel that all this everything version pinned and containerized ultimately is inducing lot of fragility in the ecosystem, and makes it more and more difficult to work with wide range of tools. Reminds me of smalltalk images in one way, and in other way of one enterprise gig I did where using some ancient IBM IDE and runtime was required because the project setup was too crusty to trust it to work any other way. I long for the opportunity where the software I develop would work with plain vanilla Debian stable and would require nothing else.
- nlstitch 4y ago
  I agree. Dev containers solve the wrong problem. (Works on my machine dev environments). Its always fun and easy to sell someone that you need to develop a layer that will solve all problems, but the underlying problem is the one we actually need to solve.
- deleted 4y ago
  [deleted]
jeanpralo 4y ago
what is the difference with docker-compose here ?
- ianpurton 4y ago
  It's supported by your IDE in this case VSCode. So it's a docker-compose that runs up in your IDE. Then you have all your tools ready to go i.e. postgres. Most importantly you can share it with your team.
- pamelafox 4y ago
  There's an additional devcontainer.json file that specifies editor configuration, like extensions, startup commands, extension settings, etc.
epolanski 4y ago
Aside of comments about the containers spec, I'd like to share that codespaces-like environments are huge for me. Being able to able to open an open source project on the go just by launching a codespace is no small feat. I have also been recently programming in quite heavy environments which my computer could not handle (especially when screen sharing) properly so launching the environment in a remote cloud instance with 8 core and 16GB of ram was useful. All my personal projects are developed in codespaces too to minimize time I spend setting up or syncing those to lower the friction as much as possible. Going from desktop to tablet to my laptop all I need to do is to launch the codespace. I hope other vendors will contribute to the spec, there's nothing to benefit here from every cloud implementing their own spec, they will eventually lose to Microsoft rather than leverage the spec.
m463 4y ago
What I find interesting is: json... with comments
- iib 4y ago
  I think the most popular implementation of json with comments is now the VSCode `settings.json`, so maybe that gets developers to slowly adopt such an extension.
- ranting-moth 4y ago
  If only JSON would have supported comments right from the start, our lives would be a bit better. But JSON wasn't intended for configuration or meddling around with much. But it's incredibly useful to have a file format parsable with vanilla JS so it just became de facto configuration syntax - without comments!
  - ehutch79 4y ago
    It did, but people went straight to abusing them, so they were removed.
- zamalek 4y ago
  The bigger deal about JSONC isn't comments, it's trailing commas.
pamelafox 4y ago
Disclosure: I work at Microsoft / Azure. I am a dev container addict. I work on tons of different projects across languages, and it's so nice for the dev environment to just work (mostly- if it doesn't, it's because of M1 issues). I also love Github Codespaces (that uses dev containers), I've been using it for all my workshops lately and attendees tend to prefer Codespaces instead of local dev. If you're looking for example dev containers, I've got a bunch of repos linked from my read me that have support: https://github.com/pamelafox https://github.com/pamelafox The trickiest ones have involved databases, but I was happy to be able to get PostgreSQL running inside the container, along with an admin for it! We did a Youtube stream showing that here: https://t.co/0Kl57Ew46C https://t.co/0Kl57Ew46C Yesterday I got docker-in-docker working as I'm running a Docker workshop today and want Codespaces to be an option. So cool. That's at https://github.com/pamelafox/flask-surveys-container-app/tree/main/.devcontainer https://github.com/pamelafox/flask-surveys-container-app/tre...
- victor106 4y ago
  Thank you, your demo is very cool and comprehensive
- fatih-erikli 4y ago
  You only need a PostgreSQL server installed on different machine. Maintaining a container will cost more on long term.
- eberkund 4y ago
  Dev containers support Docker Compose, is running the database inside the dev container preferable to using that? Or is that what you meant?
  - pamelafox 4y ago
    Yep, sorry for being unclear, I used docker-compose: https://github.com/pamelafox/django-quiz-app/blob/main/.devcontainer/docker-compose.yml https://github.com/pamelafox/django-quiz-app/blob/main/.devc... There are a few config options there that took some tweaking.
pphysch 4y ago
Your choice of dev environment should be driven by product requirements, period. Dev environments should dogfood the production supply chain as much as possible, meaning use the same base container/OS/toolchain/etc that will be used in production. Otherwise you are going to miss bugs/vulnerabilities and spend a lot of time keeping dev/prod provisioning in sync. Deploying to containers/k8s? Develop in a container. Deploying to VM/bare metal? Develop in a VM (Vagrant). Developing a portable library? Nix may be a good fit.
ivan_burazin 4y ago
I love the standard, in fact we have implemented it in the new beta version of Codeanywhere

131 points by shcheklein 4y ago

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.

teeray 4y ago

Is this basically Nix derivations, but with a more familiar syntax? (Dockerfiles)

jljljl 4y ago
I don't believe they use Nix at all. Dev Containers are basically Docker Containers (either pulled from a repo or built from a Dockerfile) with some additional metadata attached so they can work as a Development Environment. Metadata includes stuff to configure debuggers, IDEs, etc.
- whateveracct 4y ago
  I think the comment meant it does the same thing as Nix derivations. Not that it uses Nix.
x98asfd 4y ago
yeah don't really like all this. I mean if ppl are use to Dockfiles or dock compose files, then just stick with that can change the underlying tech to Nix, firejail, fire cracker or whatever. It is quite annoying to have a mega corp popping up with these different container tech that pretty much does the same thing.
pid-1 4y ago
While you can use nix derivations to build development containers, you still would need a Makefile / bash script specifying how to run them. The devcontainer spec combines 3 things: - How to build containers for a development environment (using Docker or docker-compose) - How to run containers for a development environment (volumes to mount, environment variables, commands to execute after containers are running, where the project will be mounted...) - Which VS Code configuration to install and use (including extensions) within the development environment
intelVISA 4y ago
Nix derivations: Microsoft E.E.E. edition.

djha-skin 4y ago

My coworker uses this a lot at work to solve the problem of keeping different software versions consistent across developer machines on the team. Being by Microsoft, this dovetails really well with Visual Studio Code. I find the CLI to be okay I guess for something written in JavaScript. I prefer ASDF generally[1] for solving this problem, since there's always a lot of fiddling you have to do with containers, but this is more cross platform so there's that. 1: https://asdf-vm.com https://asdf-vm.com

WirelessGigabit 4y ago
I really dislike asdf. It is supposed to be the hail marry, but it doesn't support .nvmrc with content like lts/hydrogen. Also, they don't have a pyenv venv plugin. So I'm still stuck with rbenv, nvm, jenv, pyenv and pyenv venv...
- llanowarelves 4y ago
  Have you tried nix's or guix's shells? They can be used as v env for anything.
- res0nat0r 4y ago
  Have you tried this? https://github.com/asdf-vm/asdf-nodejs#nvmrc-and-node-version-support https://github.com/asdf-vm/asdf-nodejs#nvmrc-and-node-versio... Also lts, lts-hydrogen, etc are available to install I can see when running `asdf list all nodejs`

shcheklein 4y ago

The way I see it - it's a really nice way to make reusable modules out of your Docker files (e.g. we need to install a tool and we need to run apt-get + some config, etc). And a simpler, JSON syntax to apply those modules on top of a base image. I love the experience so far, we've done a few features (modules) - e.g. this one to install `nvtop` to see GPU utilization [0] The whole CUDA + nvtop + (some other tools) setup for a project to be run on a remote machine (e.g. via VS Code) becomes like this [1] And that's enough to run ML training on GH Codespaces with GPU support. Super cool experience. [0] https://github.com/iterative/features/blob/main/src/nvtop/install.sh https://github.com/iterative/features/blob/main/src/nvtop/in... [1] https://github.com/shcheklein/hackathon/blob/main/.devcontainer.json https://github.com/shcheklein/hackathon/blob/main/.devcontai...

mshekow 4y ago

containers.dev is a spec created and only implemented by Microsoft (in Visual Studio [Code] and GitHub Codespaces). Tool vendors (of IDEs) decided to go to war, instead of collaborating, it seems. XKCD's "standards" comic seems to apply [0] here. As I've blogged about here [1], there are other specs such as Devfile.io or GitPod's proprietary gitpod.yml file. [0] https://xkcd.com/927/ https://xkcd.com/927/ [1] https://www.augmentedmind.de/2022/10/30/container-based-development-envs/ https://www.augmentedmind.de/2022/10/30/container-based-deve...

asciimike 4y ago
To be fair, GitPod claims they will support devcontainer.json: https://github.com/gitpod-io/gitpod/issues/7721 https://github.com/gitpod-io/gitpod/issues/7721
- tiraz 4y ago
  Do they? It reads more like a request from the community, but without any statement from Gitpod itself.
iddan 4y ago
Sometimes you need to name something and give it a spec for others to implement it.
panzerboy 4y ago
Yeah, I really hope JetBrains would adopt this spec as well. So far they seem to be going in another direction.

fatih-erikli 4y ago

I wouldn't recommend. If a dev environment needs such containers you probably work in crap

mixedCase 4y ago
I'm more of a Nix guy for solving this particular issue, but even assuming you were right (I don't believe so), sometimes you do have to work on crap. And it's better if you have a more reproducible dev environment when doing it.
- fatih-erikli 4y ago
  Working on crap and working in crap are different things. Working in crap: doing someones elses work Working on crap: doing some work on legacy
sph 4y ago
No, I simply do not want my workstation to be littered with dev dependencies that are used on a single project, or have to install nvm, rvm, asdf, to manage conflicting language runtimes. Nor I want to use Nix, not my jam, sorry. All I need is Emacs, and podman.
- deleted 4y ago
  [deleted]
adriancr 4y ago
And what would you recommend? Also, if you fail to see the value in this, then I'd ask what you would use: - When you need to work on multiple products with different environments. - When you want to temporarily spin up development environments on powerful machines for parts of your work and rest of the time develop locally? - When you want to pass an identical environment to someone else and have it just work.
- fatih-erikli 4y ago
  - When you need to work on multiple products with different environments. You interact with APIs. You don't have to install a database or another daemon to your local computer. - When you want to temporarily spin up development environments on powerful machines for parts of your work and rest of the time develop locally? This has never happened. - When you want to pass an identical environment to someone else and have it just work. All the dev stacks has something like package.json

filmgirlcw 4y ago

I’m a huge fan of devcontainers. If you use VS Code or Codespaces, it makes it really easy to do a remote environment exactly the same for everyone. I use them in workshops and it’s great. It’s an open standard and we’re starting to see more members of the community adopt it or integrate support into their stuff too (including some larger Nix players like devenv and Jetpack.io) and I really hope others adopt it too. For me, for however many years I’ve been using these (it’s at least 2 but it could be longer, time is a circle), it has definitely improved my QoL. Disclosure: I work at GitHub which uses devcontainers in Codespaces and I used to work at Microsoft which developed this and used it with VS Code and the amazing VS Code remote extension.

intelVISA 4y ago
Not seeing the value prop over something open like Nix, is there one?
- thinkmassive 4y ago
  What’s not open about this specification and the open source utilities built to support it?
  - zamalek 4y ago
    The tools are not open source. You cannot use dev containers with e.g. vscodium
    - filmgirlcw 4y ago
      Sure you can. You technically can’t use the VS Code remote extension in Codium because of licensing reasons (tho people have packaged it for that marketplace anyway - and I’m not suggesting anyone do that, I am saying it has been done), but there is nothing stopping anyone from building a remote extension that uses the dev container spec. I’m not debating that that isn’t a lot of extra work, but the spec itself is absolutely open for anyone else to integrate. I’d posit that the reason we haven’t seen alternatives (to my knowledge) to remote extension because of how much work is involved when most people (maybe not you, but most people), are comfortable just turning off the telemetry flag in VS Code rather than using Codium. But if you’d rather use something like Nix, using something like devbox or devenv will achieve something similar to dev containers and that’s fine foo.

zokier 4y ago

Tbh I feel that all this everything version pinned and containerized ultimately is inducing lot of fragility in the ecosystem, and makes it more and more difficult to work with wide range of tools. Reminds me of smalltalk images in one way, and in other way of one enterprise gig I did where using some ancient IBM IDE and runtime was required because the project setup was too crusty to trust it to work any other way. I long for the opportunity where the software I develop would work with plain vanilla Debian stable and would require nothing else.

nlstitch 4y ago
I agree. Dev containers solve the wrong problem. (Works on my machine dev environments). Its always fun and easy to sell someone that you need to develop a layer that will solve all problems, but the underlying problem is the one we actually need to solve.
deleted 4y ago
[deleted]

jeanpralo 4y ago

what is the difference with docker-compose here ?

ianpurton 4y ago
It's supported by your IDE in this case VSCode. So it's a docker-compose that runs up in your IDE. Then you have all your tools ready to go i.e. postgres. Most importantly you can share it with your team.
pamelafox 4y ago
There's an additional devcontainer.json file that specifies editor configuration, like extensions, startup commands, extension settings, etc.

epolanski 4y ago

Aside of comments about the containers spec, I'd like to share that codespaces-like environments are huge for me. Being able to able to open an open source project on the go just by launching a codespace is no small feat. I have also been recently programming in quite heavy environments which my computer could not handle (especially when screen sharing) properly so launching the environment in a remote cloud instance with 8 core and 16GB of ram was useful. All my personal projects are developed in codespaces too to minimize time I spend setting up or syncing those to lower the friction as much as possible. Going from desktop to tablet to my laptop all I need to do is to launch the codespace. I hope other vendors will contribute to the spec, there's nothing to benefit here from every cloud implementing their own spec, they will eventually lose to Microsoft rather than leverage the spec.

m463 4y ago

What I find interesting is: json... with comments

iib 4y ago
I think the most popular implementation of json with comments is now the VSCode `settings.json`, so maybe that gets developers to slowly adopt such an extension.
ranting-moth 4y ago
If only JSON would have supported comments right from the start, our lives would be a bit better. But JSON wasn't intended for configuration or meddling around with much. But it's incredibly useful to have a file format parsable with vanilla JS so it just became de facto configuration syntax - without comments!
- ehutch79 4y ago
  It did, but people went straight to abusing them, so they were removed.
zamalek 4y ago
The bigger deal about JSONC isn't comments, it's trailing commas.

pamelafox 4y ago

Disclosure: I work at Microsoft / Azure. I am a dev container addict. I work on tons of different projects across languages, and it's so nice for the dev environment to just work (mostly- if it doesn't, it's because of M1 issues). I also love Github Codespaces (that uses dev containers), I've been using it for all my workshops lately and attendees tend to prefer Codespaces instead of local dev. If you're looking for example dev containers, I've got a bunch of repos linked from my read me that have support: https://github.com/pamelafox https://github.com/pamelafox The trickiest ones have involved databases, but I was happy to be able to get PostgreSQL running inside the container, along with an admin for it! We did a Youtube stream showing that here: https://t.co/0Kl57Ew46C https://t.co/0Kl57Ew46C Yesterday I got docker-in-docker working as I'm running a Docker workshop today and want Codespaces to be an option. So cool. That's at https://github.com/pamelafox/flask-surveys-container-app/tree/main/.devcontainer https://github.com/pamelafox/flask-surveys-container-app/tre...

victor106 4y ago
Thank you, your demo is very cool and comprehensive
fatih-erikli 4y ago
You only need a PostgreSQL server installed on different machine. Maintaining a container will cost more on long term.
eberkund 4y ago
Dev containers support Docker Compose, is running the database inside the dev container preferable to using that? Or is that what you meant?
- pamelafox 4y ago
  Yep, sorry for being unclear, I used docker-compose: https://github.com/pamelafox/django-quiz-app/blob/main/.devcontainer/docker-compose.yml https://github.com/pamelafox/django-quiz-app/blob/main/.devc... There are a few config options there that took some tweaking.

pphysch 4y ago

Your choice of dev environment should be driven by product requirements, period. Dev environments should dogfood the production supply chain as much as possible, meaning use the same base container/OS/toolchain/etc that will be used in production. Otherwise you are going to miss bugs/vulnerabilities and spend a lot of time keeping dev/prod provisioning in sync. Deploying to containers/k8s? Develop in a container. Deploying to VM/bare metal? Develop in a VM (Vagrant). Developing a portable library? Nix may be a good fit.

ivan_burazin 4y ago

I love the standard, in fact we have implemented it in the new beta version of Codeanywhere