Docker Workspaces vs. Vagrant VMs
Docker Workspaces vs. Vagrant VMs
See how Eclipse Che, an IDE built on Docker, and Vagrant stack up against each other and how Che's versatility can be an asset.
Join the DZone community and get the full member experience.Join For Free
Development teams need easy-to-configure, reproducible and portable developer workspaces controlled by a single consistent workflow to maximize their productivity. Over the years, developers have flocked to VMs and Vagrant as a tool to help provision development environments on different computers. While the workflow is consistent, VMs are large and slow while running only locally, with no ability to be shared as a server for collaboration.
Eclipse Che was created to solve the same goal — to let anyone, anywhere contribute to a software project without having to install software. This requires developers to have access to a portable workspace provisioned as part of a consistent workflow with an embedded web IDE.
So, what’s the difference between Vagrant — a system that lets developers use VMs to create environments — and Eclipse Che, built on Docker and operating as a workspace server? It lies in the workspace abstraction.
Vagrant’s Primary Abstraction Is With a VM
Vagrant files let you define certain networking and OS-related meta information for a VM followed by executing a series of scripts, “provisioners,” inside of the VM after it is established. This is a blunt instrument.
Che’s Abstraction Is a Workspace
The workspace treats its environments (runtimes), projects (source code), agents (external software injected into environments), and IDE (editor) as first-class constructs.
The consequences of such an approach include:
The workspace is defined with metadata that is a composite of environments, IDEs, projects, and agents. Managing metadata enables workspace replicas and portability independent of the state of its internal environments.
2. Project Mounting
Projects are mounted as a volume into Che, providing a standard approach to injecting code trees from repositories or ZIP/TAR files into (and out of) a workspace. Within Che, projects are rsync’d in and out of a workspace to long-term storage to allow management while the workspace is stopped.
3. Project Types
Projects have types, which alter workspace behavior by adding or removing agents and extensions associated with the type. These alterations are server-side and can be client-side with the Che IDE.
Developer services, such as SSH or the Web terminal (will be soon) injected as agents, which are self-contained software packages that are managed through a workspace lifecycle. This will allow development-specific functionality to be layered into a workspace, allowing off-the-shelf and production-ready environments to be reused without modification in development and production.
A single workspace can have many environments, with one running at any point in time. This is valuable for when a developer is testing different runtimes against a common code base. Environments are how Samsung’s ARTIK IDE switches between different SDK versions within a single workspace.
Environments use machines to provide their runtime instances. While Che uses Docker as the default, this machine interface is pluggable. We could implement a Vagrant, or perhaps, an Android implementation.
Workspaces are independently controllable not only with a CLI, but also through RESTful interfaces, standardizing the way that third-party tools can integrate, control, and customize workspaces programmatically. Spin up Eclipse Che and browse to `/swagger` to see the APIs available.
Within Codenvy, an enterprise version of Eclipse Che, there is permission enforcement within each workspace. Access restrictions defined centrally by an admin are enforced at our edge, within the workspace, and within each agent.
Vagrant is not centrally managed across a distributed set of physical nodes. Codenvy is DevOps infrastructure for managing teams, workspaces and stacks across an organization. There are many capabilities designed for admins and tailored for the workspace abstraction.
As GitHub user loganto commented, Che’s workspace model is ideal. “We went from FTP’ing code to dev server, to Vagrant to Docker on each developer’s machine. But every one of them seems to have some issues, from Vagrant Symlinks working on Linux hosts but not Windows hosts, to files not always syncing, to command incompatibility. Docker seemed to be the best, but doesn’t port cleanly between Windows and OSx hosts with remote work challenging as we have tons of data that hard to mockup.”
Ultimately, Eclipse Che is a surgical scalpel compared to Vagrant’s blunt hammer. If you haven’t tried Che recently, try the launcher with single click capabilities, and also the experimental Che dir, for provisioning workspaces without any configuration.
Published at DZone with permission of Tyler Jewell , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.