Containerizing your dev environment
With the VS Code Remote - Containers extension
Oct 27 2020
A couple of weeks ago I listened to another great episode of the BartJS podcast where containerization was discussed, specifically containerization of your development environment. When visiting their homepage now I couldn't find the episode in their overview, but here's a direct link: Remote - Containers i VSCode - Droplet 6. I definitely got curious about it, and so the last couple of days I've been trying it out for myself.
Containerizing your dev environment means you would create an isolated environment for your source code to run in. If you are a team working on the same repo, this would mean you'd all work in the exact same environment. No more "but it works on my machine". Another benefit is that you don’t have to “pollute” your own file system with all kinds of tools and extensions. They are only installed in this isolated environment.
I borrowed this description which explains it in an easy to understand way:
- Develop with a consistent, easily reproducible toolchain on the same operating system you deploy to.
- Quickly swap between different, isolated development environments and safely make updates without worrying about impacting your local machine.
- Make it easy for new team members / contributors to get up and running in a consistent development environment.
- Try out new technologies or clone a copy of a code base without impacting your local setup.
Getting up and running in VS Code
So I gave it a go, and I’m impressed at how easy it is to get up and running in VS Code. You install the Remote - Containers extension. Then you create a devcontainer/devcontainer.json file in your repo. This is the file VS Code looks for, which has the settings for which extensions to install etc. Also, you need a Dockerfile containing the “recipe” for the Container creation (which files to copy, what commands to run etc). If you are familiar with Docker you've definitely written a Dockerfile before. If not, Docker has a great tutorial here
Once you've done this you're basically all set and it's just a couple of clicks to get the container up and running.
Will I start containerizing my dev projects?
The short answer is no. I haven't felt too much on any of the pain points this workflow solves - yet. But this might change. I can totally see why this would appeal to some projects and teams. The idea of having a "cleaner" file system is also appealing. Let's say I would want to try Rust. I download a repo, spin up a container and install Rust in that container - keeping my local filesystem untouched. Mmm!