Author: Kyle Carberry, Co-founder & CTO at Coder
Bio: Kyle is Co-founder & CTO at Coder. He’s directly responsible for Coder’s open-source projects, including envbuilder.

Intro

Dev Containers signal that Microsoft recognizes the value of cloud-based software development. Besides making it easy for VS Code users to develop seamlessly in a container, a Dev Container’s biggest benefit is that it standardizes a team’s environment. Imagine no longer having to hear (or say) “but it works on my machine”.

How a Dev Container works

A developer can run a Dev Container that not only clones a team’s repository but also installs the right tools, libraries, and dependencies. Just a few clicks is all a developer needs to start coding in an identical environment to their teammates.

From the point of view of an IDE, a Dev Container specifies how to configure, start, and stop a Docker container that hosts a development environment. VS Code also runs VS Code Server in the container, letting your local computer interact with it.

A Dev Container has these files:

• Dockerfile: clones repositories, installs tools and libraries, and so on.
• json: metadata to interact with the container.
• Related files, like other configuration, a README, license, and so on.

Four ways to benefit from Dev Containers (and a couple of obstacles)

1. Simple, low-risk adoption

Dev Containers are easy to set up and use. A developer user just needs to install an IDE and Docker, then clone a Dev Container. There are no complications from proprietary formats: Microsoft even publishes an open specification.

2. Solve the “works on my machine” problem

It’s less likely for a developer to write code that works perfectly only on their machine and nobody else’s. With Dev Containers, everyone on the team has the same code, versions, and configuration.

There’s also the problem of hunting down and resolving dependencies. A standardized, repeatable development environment makes sure that once a developer solves a dependency problem, sharing the fix with the rest of the team is easy.

3. Source-control your development environment

Once you’ve put your Dev Container in a repo, your team can apply updates, improvements, and fixes with just a commit or PR. A team doesn’t have to start from scratch, either. Microsoft has sample Dev Containers for popular development setups.

4. A clear path to cloud-based development

Development teams don’t have to be tied to a geographical location. Cloud-based development makes remote collaboration simpler.

For situations where on-premise computing and storage aren’t cost-effective, moving to the cloud can reduce costs by letting teams pay for resources only as needed.

Obstacle: Doesn’t run on Kubernetes

Development teams who use Kubernetes, or Kubernetes-based platforms like OpenShift, are missing out. Their projects are too complex, large, or otherwise don’t use Docker.

Obstacle: Developers need more from containers

Large or complex Dockerfiles take a long time to build. Tasks like updating a Docker image means stopping it, rebuilding, and starting again. Developers end up with a bad experience.

Envbuilder makes Dev Containers even better

Dev Containers solve a lot of problems. But Coder customers use a wider variety of platforms besides Visual Code and Docker. And some of our customers have big development environments. We felt that they don’t have to feel left out. That’s why we started envbuilder, to add support for Dev Containers in Coder.

Today envbuilder is a separate, open source, vendor-neutral project. Our intention is to contribute to the Dev Container ecosystem, whether or not you’re also a Coder user.

Kubernetes users don’t have to miss out

With envbuilder, a developer can run a Dev Container not just in Docker but in Kubernetes (or OpenShift) too. Envbuilder does this by leveraging Kaniko, which builds a Docker container in a Kubernetes cluster. In most cases, there’s not much to change in the Dev Container’s files.

Faster image updates

Envbuilder is faster at creating and updating images in-place. It does this by caching image layers with registries. The result is that your developers don’t have to wait as long for security patches and version updates.

Seamless integration with Coder

Even though envbuilder is an independent project, it’s still a Coder feature. Coder adds more control and flexibility to Dev Containers, like automatic scheduling and logging.

Dev Containers aren’t tied to VS Code either. Coder lets you take advantage of that with easy support for other IDEs.

Dev Containers for everybody

It takes time to on-board a developer. It takes time to reproduce a bug. It wastes budget to pay for full-time hardware that a development team uses part-time. That’s why we created envbuilder, so that development teams who use Kubernetes-based environments don’t have to miss out. And all Dev Container users can speed up updates no matter what platform they run on.

Dev Containers are an exciting, emerging technology. But as with all new technologies, they’re a change. It’s best to jump in and try them out. Learn more at containers.dev or consider contributing to the envbuilder project. If we collectively contribute to the Dev Container community, then we collectively improve the developer experience.

Are you interested in Dev Containers? After you’ve tried envbuilder by itself, take a look at Coder for even more control and flexibility over your Dev Containers.

Join us at KubeCon + CloudNativeCon North America this November 6 – 9 in Chicago for more on Kubernetes and the cloud-native ecosystem.