A lot of folks think Docker is the “next revolution” in the realm of virtualization. But in actuality, Docker is just a set of scripts built around a technology that has existed for some time: containers. So how is a Docker container different from a conventional virtual machine?
I’m sure you’re familiar with virtual machines. There’s an underlying operating system, a layer on top of that for abstraction, and then multiple “virtual machines” on top of that. Docker attempts to address some of the shortcomings of virtual machines:
- They’re full installs of the operating system. For instance, you could have a Linux Ubuntu host, a hypervisor on top of that, and then a full installation of Windows atop that. Because of this, there’s a reduction in performance as there’s a lot of “translation” going on. This is because the guest OS doesn’t have direct access to the hardware; instead, it’s all virtual.
- Spinning up a new VM takes time, because you have to launch a full operating system on top of the hypervisor. In most public clouds it takes minutes.
Docker basically made containers extra-simple for people. In the past, you could create a “protected environment” within most Unix operating systems almost instantaneously. But the tools for doing so were very complicated. FreeBSD has had jail forever and Linux has had chroots forever. Linux containers (LXCs) are the latest and greatest “chrooting” technology for Linux. Docker is essentially a wrapper around the container technology to make it easier to use.
But Docker is going to change the world, and here’s why: Because spinning up a virtual machine takes a long time, many folks still treat them as indispensable. Cloud computing with virtual machines (EC2, Rackspace Cloud) revolutionized the market from an “I need a server, give me a server” perspective. But it didn’t really change everyone’s mindset-many people still treat VMs like normal servers, for the most part.
This relates to a recent post in the Bitlancer blog post about some DevOps environments being “too mature” for our Bitlancer Strings software. If your shop treats VMs like disposable instances of commodity hardware, chances are your process is more highly evolved than most. Chances also are that you’re already familiar with Docker and/or looking to move to it.
The reason Docker containers are called “containers” illustrates another way this technology will drive big changes: they’re built locally on a developer’s machine, and then become incredibly portable! Ordinary VMs require a bit of vendor-specific tuning. (How many interfaces does an OS have? How many different ways are there to install Windows?!)
But (to oversimplify a complex topic) a container is usually a stripped-down version of an OS that lives within the existing OS instance instead of on top of it, with less abstraction between it and the underlying hardware. You can build and ship containers to any server running Linux that has support for the technology. This hugely increases the portability of applications-you can actually deploy the same snapshot to Rackspace or Amazon, or even another cloud provider, without issue.
But that’s not all… Containers are quick. I can spin up a VM on my laptop in about a minute. I can spin up a Docker container in less than two seconds provided there’s a Linux VM up and running (since I run Mac OS X).
Think about how that helps with testing! Before I’d have to run a “test” after making a code change, and it would spin up numerous virtual machines over a period of minutes. Now I can run a test and the target for the test (a container running a stripped-down version of Linux within an existing Linux instance, versus on top of a hypervisor) spins up in seconds.
Yet another important feature of Docker is its “advanced multi layered unification filesystem” (AuFS), which offers innovations like the ability to swap out the base image (to solve challenges like the Heartbleed bug) and image composability.
Is there a downside to Docker? One issue is that Docker is still immature. I tried implementing Docker on a recent project, without success. In particular, AuFS still has some limitations, and there are still security questions within the community around containers in general. For example, I’ve encountered this challenge.
This reflects that Docker is still maturing and doesn’t yet include everything that’s required to properly protect the host OS and other containers.
So here at Bitlancer we’re “proceeding with caution” with Docker until the environment is more stable and predictable across the board. But clearly this is great stuff. Stay tuned!
UPDATE: Bitlancer Strings is now open source. For more information, visit Strings Documentation on Github.