|
|
|
|
|
by owyn
822 days ago
|
|
Well, developers seem to love writing "configuration" rather than "code" these days. But basically a container + the necessary tools IS a devcontainer. It's just a way of automating the "putting in the necessary tools" part especially if you need things that might need to be added to a base container, or services that need to be configured differently based on the external environment that you don't want to bake in for some reason. If you've ever had to cut and paste a 50 line docker run command snippet but you forgot that one volume mount or port or ENV var that someone added a dependency on last week then you pretty quickly realize just doing complex docker things by hand is a pain. Another example, if you have a script that you want to run to fetch the latest authentication token from a vault after the container launches because you don't want to store it inside the container. Sure, you could write a bash script to run all these steps inside the container after you launch it but it's nice to have a config file to share with another dev and just say: use this. And the secondary benefit is that having a config file for the editor (like VSCode) so that plugins can manage all of that stuff better. Generally a dev container runs the VSCode Server, and they know how to talk to each other which can make remote development easier. For example, now I can launch the same dev environment locally or on the 56 core xeon 1TB ram server at the office and it's exactly the same as far as the editor is concerned. It looks like this project is an alternative to the VSCode Server. My team generally uses docker-compose for this since not everyone uses VSCode. |
|
For the second point, ok this makes a little bit more sense, I've heard of Codespaces or OpenShift Dev Spaces but I guess I still question the value of additional complexity on top of the container (a simple dockerfile in my mind) your vscode instance's terminal is running in.
Thanks for the info.