0x015 - Dev Containers 🍱

Hi, y’all! Welcome to unzip.dev, a newsletter dedicated to unpacking trending developer concepts. I’ll be posting every few weeks, so if you haven’t subscribed yet, go for it!

Dev Containers

Synonyms: devcontainer, (Cloud) Dev environments, Devbox, Environment-as-a-Service, Containerized-development.

TL;DR:

• Problem: Having consistent development environments shared across developers is difficult. “It works on my machine”.
• Solution: A reproducible development environment that can be versioned, shared and integrated seamlessly with your IDE.
• In Sum: Dev Containers are a great way to standardize your developers’ environments - helping you reduce onboarding and environment-related bugs.

How does it work? 💡

I will focus on the VS Code Dev Containers concept, although your favorite IDE might also have a similar solution today. It is an open specification that others also adopted.

The basic concept is to “dockerize” your development environment and integrate it with your IDE. The container can be local or remote.

First, you need VS Code and docker (or a compatible alternative) installed.

Then you need an IDE extension installed like Dev Containers or Remote Development (includes SSH and WSL support for Windows).

When you create a Dev Container, you create a .devcontainer folder with:

• A Dockerfile that will be the base “OS” for your development environment, (e.g. Debian with python).
• A .devcontainer file that connects VS Code (and its settings) to the Dockerfile. You can define extensions that will be installed, mounts, and more.

How does it work? 💡

I will focus on the VS Code Dev Containers concept, although your favorite IDE might also have a similar solution today. It is an open specification that others also adopted.

The basic concept is to “dockerize” your development environment and integrate it with your IDE. The container can be local or remote.

First, you need VS Code and docker (or a compatible alternative) installed.

Then you need an IDE extension installed like Dev Containers or Remote Development (includes SSH and WSL support for Windows).

When you create a Dev Container, you create a .devcontainer folder with:

• A Dockerfile that will be the base “OS” for your development environment, (e.g. Debian with python).
• A .devcontainer file that connects VS Code (and its settings) to the Dockerfile. You can define extensions that will be installed, mounts, and more.

Questions ❔

• Single projects only? Dev Containers mainly help to set up the developer environment for a single project (build system, language-level tools, and any OS needed libraries). But, it could also set up a full docker-compose setup (Note: I haven’t seen it work myself).
• Docker vs Dev Containers? Docker is a great way to run an application, but it doesn’t solve developing that application consistently across team members.
• Can I develop docker-related projects in a Dev Container? Yes, there is a docker-in-docker template and host solution.
• Can I use a docker-compose.yml file too? Yes, you can.
• What about credentials and env vars? Environment variables are supported, and you can even work with git credentials pretty easily.
• Using X display / GUI? Check this StackOverflow and desktop-lite, and Reddit post for mac.

How does it work? 💡

I will focus on the VS Code Dev Containers concept, although your favorite IDE might also have a similar solution today. It is an open specification that others also adopted.

The basic concept is to “dockerize” your development environment and integrate it with your IDE. The container can be local or remote.

First, you need VS Code and docker (or a compatible alternative) installed.

Then you need an IDE extension installed like Dev Containers or Remote Development (includes SSH and WSL support for Windows).

When you create a Dev Container, you create a .devcontainer folder with:

• A Dockerfile that will be the base “OS” for your development environment, (e.g. Debian with python).
• A .devcontainer file that connects VS Code (and its settings) to the Dockerfile. You can define extensions that will be installed, mounts, and more.

Questions ❔

• Single projects only? Dev Containers mainly help to set up the developer environment for a single project (build system, language-level tools, and any OS needed libraries). But, it could also set up a full docker-compose setup (Note: I haven’t seen it work myself).
• Docker vs Dev Containers? Docker is a great way to run an application, but it doesn’t solve developing that application consistently across team members.
• Can I develop docker-related projects in a Dev Container? Yes, there is a docker-in-docker template and host solution.
• Can I use a docker-compose.yml file too? Yes, you can.
• What about credentials and env vars? Environment variables are supported, and you can even work with git credentials pretty easily.
• Using X display / GUI? Check this StackOverflow and desktop-lite, and Reddit post for mac.

Why? 🤔

• Onboarding: One of the main selling points is to reduce onboarding friction. Just install VS Code a docker-like runtime and clone the relevant Dev Container and voilà, you have a ready to work project ✨.
• Consistency: Keep the dev environments consistent including extensions, dependencies, IDE configurations, linting rules...
• Integrates with Codespaces: A cloud-based VS Code IDE can be deployed with your Dev Container settings. This is great for pair programming or coding on a light-spec machine.
• Easy CI environments: Bootstrap the same environment in your CI - a huge time sink of bugs.
• Upgrading is easier: Just change a version and don’t dabble in bare metal IT configuration. This also means that you are saving countless team hours by upgrading once and sharing it with one push to the entire team.
• Pre-defined containers and tools: Microsoft has already provided the majority of use cases as packaged containers (the associated repo) - it even works with Kubernetes (& minikube)! There is also a list of features (they mean tools).
• Isolation: For each use case (e.g. data science/web development) you can very easily separate versions and dependencies and eliminate local conflicts entirely.
• Make PRs a breeze: If you are using GitHub you can just type , which will load a GitHub Codespace - assuming it is a .devcontainer-enabled project, you will be able to theoretically run the new code online and edit it super easily.

How does it work? 💡

I will focus on the VS Code Dev Containers concept, although your favorite IDE might also have a similar solution today. It is an open specification that others also adopted.

The basic concept is to “dockerize” your development environment and integrate it with your IDE. The container can be local or remote.

First, you need VS Code and docker (or a compatible alternative) installed.

Then you need an IDE extension installed like Dev Containers or Remote Development (includes SSH and WSL support for Windows).

When you create a Dev Container, you create a .devcontainer folder with:

• A Dockerfile that will be the base “OS” for your development environment, (e.g. Debian with python).
• A .devcontainer file that connects VS Code (and its settings) to the Dockerfile. You can define extensions that will be installed, mounts, and more.

Questions ❔

• Single projects only? Dev Containers mainly help to set up the developer environment for a single project (build system, language-level tools, and any OS needed libraries). But, it could also set up a full docker-compose setup (Note: I haven’t seen it work myself).
• Docker vs Dev Containers? Docker is a great way to run an application, but it doesn’t solve developing that application consistently across team members.
• Can I develop docker-related projects in a Dev Container? Yes, there is a docker-in-docker template and host solution.
• Can I use a docker-compose.yml file too? Yes, you can.
• What about credentials and env vars? Environment variables are supported, and you can even work with git credentials pretty easily.
• Using X display / GUI? Check this StackOverflow and desktop-lite, and Reddit post for mac.

Why? 🤔

• Onboarding: One of the main selling points is to reduce onboarding friction. Just install VS Code a docker-like runtime and clone the relevant Dev Container and voilà, you have a ready to work project ✨.
• Consistency: Keep the dev environments consistent including extensions, dependencies, IDE configurations, linting rules...
• Integrates with Codespaces: A cloud-based VS Code IDE can be deployed with your Dev Container settings. This is great for pair programming or coding on a light-spec machine.
• Easy CI environments: Bootstrap the same environment in your CI - a huge time sink of bugs.
• Upgrading is easier: Just change a version and don’t dabble in bare metal IT configuration. This also means that you are saving countless team hours by upgrading once and sharing it with one push to the entire team.
• Pre-defined containers and tools: Microsoft has already provided the majority of use cases as packaged containers (the associated repo) - it even works with Kubernetes (& minikube)! There is also a list of features (they mean tools).
• Isolation: For each use case (e.g. data science/web development) you can very easily separate versions and dependencies and eliminate local conflicts entirely.
• Make PRs a breeze: If you are using GitHub you can just type , which will load a GitHub Codespace - assuming it is a .devcontainer-enabled project, you will be able to theoretically run the new code online and edit it super easily.

Why not? 🙅

• Mobile and Windows-native development: Emulators needed for that type of development don’t work as well as they do on a host machine.
• Single developer: Many of the benefits of Dev Containers are most evident when there are multiple contributors to the same project. I still think there is a strong case for using it for yourself, but it’s not as juicy.
• VS Code/GitHub buy-in: To reap most of the benefits from Dev Containers, you need a lot of buy-in into the VS Code/GitHub ecosystem - or others (like Jetbrains).
• Production deployments: Dev Containers contain necessary tools and configurations for development, not production - which needs to be lean, fast and secure - usually the opposite of a development environment.
• Performance: There might be some performance hiccups, but there are solutions.

Tools & players 🛠️

• Containers.dev - The open specification for Dev Containers.
• VS Code - With the relevant extensions, Dev Containers or Remote Development.
• JetBrain’s Dev Environments - If you’re already bought into the JetBrains ecosystem you might want to check it out. But, the Dev Container’s spec doesn’t seem to be supported yet.
• Devbox - Isolated, reproducible development environments without Docker or Nix.
• DevPod - An open-source alternative to GitHub Codespaces and works with the Dev Containers specifications.

Forecast 🧞

• Market adoption: The “Dev Containers” VS Code extension already has 19M+ installs (!). I don’t see it slowing down any time soon.
• OS vs IDE dev environments: A lot of people are talking about Nix. I believe that the simple ideas of Dev Containers make it easier to use (no need to learn new DSLs and concepts) because it just works™. I might write about Nix soon, so I'll give my final opinion then.
• Market share: The VS Code team is really crushing it, this type of advancement should’ve come a lot sooner by other IDE incumbents (yes I’m looking at you JetBrains). I suspect VS Code will grab more IDE market share, especially with the ingenious move from Microsoft buying up GitHub (and its associated deep integrations to Codepsaces and Dev Containers). Microsoft is killing it.

Extra ✨

Additional information that is related:

• A great 8-minute video introduction to Dev Containers.
• If you are thinking about deploying this in your company, see this more in depth video.
• Intro and demo video at Devoxx Greece.
• Microsoft’s YouTube tutorials on Dev Containers.
• A textual intro for those that don’t like videos ;)

Thanks 🙏

I wanted to thank @TomGranot (the best growth person I know - you might want to check out his Koolkits project as it is somewhat related here too), @AndyKatz (Helps organizations gain competitive advantage through intelligent technology - DM him for more, you won’t regret it 😉), and Zirak (one of my nicest friends, who is coincidentally a developer, and a good one too!).

EOF

(Where I tend to share unrelated things).

If you are into 3D printing, a good friend of mine started an exciting weekly newsletter about 3D printing (with some help from me) - check it out here.

P.S. This issue took me 10+ hours to compile, I hope you liked it.