4 ms·

Absolutely you can see the dev containers for many popular languages here: https://github.com/microsoft/vscode-dev-containers https://github.com/microsoft/vsco

by aszen 6y ago

Absolutely you can see the dev containers for many popular languages here: https://github.com/microsoft/vscode-dev-containers https://github.com/microsoft/vscode-dev-containers To get started all you need is docker, vscode + remote containers extension I have been using it to play around with multiple languages locally and also adding devcontainers for new projects to easily hop into isolated project development envs.

donmcronald 6y ago
Thanks for the link. I played around with it for about 10 minutes (just enough to run the Go example) and it's really neat. The general premise is great and I've wanted something like that for years. One thing I don't like is the Dockerfile that lives alongside the .devcontainer file. Using that to install a portion of the dev environment is a mistake IMO because things like 'apt-get install something' are non-deterministic. I think it would be amazing if that Dockerfile were hooked into CI and used to build an official dev container for a project every day or every week and if that were the container that's used for development. I already try to do something similar for an official project build container (ie: this container can build the project and is used for all CI builds) and the dev container would perfectly double up on responsibility for that. The big win with having an immutable container for dev / building is that it could be kept around if it's used to do a production build. Ex: When building v1.0.1, pull the current dev / build container, tag it or label it, push it into a special registry, and use that container for the production build. That way anyone could check out the 1.0.1 dev container and have the exact, old environment that was used to build the production artifact(s) for that version. I honestly think using this type of setup will become an expectation at some point. It's just too awesome to not use which is part of what scares me about it. While it's not tied to Azure and I can run it locally it's amazing. If it ever becomes exclusive to some type of "run on Azure" play by MS it'll be terrible because it's so compelling you won't be able to ignore it.
- aszen 6y ago
  Yeah its good, one point that my little experience has shown is that production containers cannot be used for development since they lack all the tooling and are designed pretty bare bones hence the focus is on allowing customising development environments. Note that there are alternatives to this containerized approach in the nix world with nix packages which I think maybe a better approach for deterministic dev environments but so far containers are all the rage.

by aszen 6y ago

donmcronald 6y ago

Thanks for the link. I played around with it for about 10 minutes (just enough to run the Go example) and it's really neat. The general premise is great and I've wanted something like that for years. One thing I don't like is the Dockerfile that lives alongside the .devcontainer file. Using that to install a portion of the dev environment is a mistake IMO because things like 'apt-get install something' are non-deterministic. I think it would be amazing if that Dockerfile were hooked into CI and used to build an official dev container for a project every day or every week and if that were the container that's used for development. I already try to do something similar for an official project build container (ie: this container can build the project and is used for all CI builds) and the dev container would perfectly double up on responsibility for that. The big win with having an immutable container for dev / building is that it could be kept around if it's used to do a production build. Ex: When building v1.0.1, pull the current dev / build container, tag it or label it, push it into a special registry, and use that container for the production build. That way anyone could check out the 1.0.1 dev container and have the exact, old environment that was used to build the production artifact(s) for that version. I honestly think using this type of setup will become an expectation at some point. It's just too awesome to not use which is part of what scares me about it. While it's not tied to Azure and I can run it locally it's amazing. If it ever becomes exclusive to some type of "run on Azure" play by MS it'll be terrible because it's so compelling you won't be able to ignore it.

aszen 6y ago
Yeah its good, one point that my little experience has shown is that production containers cannot be used for development since they lack all the tooling and are designed pretty bare bones hence the focus is on allowing customising development environments. Note that there are alternatives to this containerized approach in the nix world with nix packages which I think maybe a better approach for deterministic dev environments but so far containers are all the rage.