Docker introduces developer environments in containers

But you can pull down your dev environment from Docker. Is it solving a problem that doesn't exist, though?


DockerCon Virtual DockerCon kicked off today, at which the company introduced Docker Development Environments, calling them "the foundation of Docker's new collaborative team development experience."

In the past Docker containers have been mainly for deployment of applications, but the Docker Development Environment extends that to... (you guessed it) development as well.

Editing code in a Docker Development Environment.

Editing code in a Docker Development Environment

A container image will have the tools and compilers needed to build the application, with advantages like the ability to define and reproduce that environment without the complications of installing everything directly onto a developer's PC, which can get complex particularly for those working on multiple project types.

The main thinking behind the Development Environment is to make it easier to work on multiple branches of a project and to share work in progress with others, however. An example might be a Git project where there is production branch which needs maintaining, a development branch for the next version, and an experimental branch for trying out some new ideas.

Switching between these on one machine could be complex, particularly if the dependencies are different. The isolation of using a different container for each branch may help.

The user interface for the new feature is Docker Desktop, or as principal product manager Ben de St Paer-Gotch, put it, Docker Dashboard. A Development Environment may be formed of multiple containers, and is pulled down from the Docker container repository.

A Development Environment in Docker Desktop, with controls for starting containers and editing them with VS Code

A Development Environment in Docker Desktop, with controls for starting containers and editing them with VS Code

The developer then has controls to start the container and then to open Visual Studio code in order to edit it. Microsoft's VS Code runs its user interface outside the container, but with remoting into the container for interacting with the code, compiler and other utilities. Work in progress can be shared by pushing the container back up to the repository for others to pull.

Although some of the ideas here, along with the use of VS Code, sound similar to services such as GitPod and GitHub Codespaces, the big difference is that GitPod and Codespaces run in the cloud, and collaboration is based on working on the same code repository, whereas Docker Development Environments run locally, and enable sharing of work in progress as a complete working piece.

According to De St Paer-Gotch, "we're interested in being local first, using the compute that existing developers have paid for rather than having them pay for another development environment."

Is Docker on the right track?

Responding to a preview video, one developer questioned the approach, saying: "You are solving for a problem that does not exist… if it's only about code sharing then we don't need to even pull it, as the code can easily be reviewed inside a browser.

"Furthermore, we are usually interested in changes in the code, which the demonstrated feature has no solution for (we still have to pull the branch and get the diff).

"Finally, moving between git branches is far more easier (sic) than pulling entire docker images. Don't know who in their right mind would think otherwise."

That said, the developer added: "I 'specially liked the fact that VS code connects to a remote container with a click of a button, but you need to repurpose the feature and pitch it differently."

There are some limitations in the first release, which is expected to be fully available next month. VS Code is the only supported IDE, though Docker told us that other IDE vendors may well add support.

Another complication is with large applications that are formed from many services, leading to potentially unwieldy Development Environments. "It is part of the challenge we see… we know that developers want to work locally on the services they care about and offload other services elsewhere," De St Paer-Gotch told The Register.

The best place to follow the development and release of Docker Developer Environments is the roadmap here.

What will the service cost? "The sharing aspect is going to be for team users," De St Paer-Gotch said. "The overall experience for just running them locally will be free for everyone."

At DockerCon, the company also introduced updates to other products. Docker Compose, a tool for running multiple container applications, is now at version 2 and has support for GPU-heavy workloads such as deep learning, and service profiles allowing easy switching between configurations such as for production or for development.

Linux users are at a disadvantage though: "Docker Compose v2 is currently available in Docker Desktop and will be included in the Docker Linux packages later in the year," the company said.

Docker also said it has expanded what it calls the Docker Verified Publisher program, where vendors submit verified images to Docker registries, with more than 100 companies now signed up. ®

Similar topics


Other stories you might like

Biting the hand that feeds IT © 1998–2021