DEV Community

Pål Nødseth
Pål Nødseth

Posted on • Originally published at pnodseth.dev on

Containerizing your dev environment

A couple of weeks ago I listened to another great episode of the BartJS podcast where containerization was discussed, spesifically 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 definately 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 borred 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 definately 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 - no. I haven't felt too much on any of the pain points this workflow solves - yet. But this might change. I can definately see why this would appeal to some projects and teams. The idea of having a "cleaner" file system is also somewhat 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!

Top comments (0)