“I love the long time it takes to manually provision a brand new server from scratch!” said no one ever. One of the things that sysadmins and devops have long regarded as a necessary evil is the overhead time wasted twiddling one’s thumbs while waiting for a new server’s creation. With the advent of virtualization and cloud computing and the resultant massive increase in need for computing, the frequency of new-server creation has only increased as well.
Enter tools like Docker and Chef. In a nutshell, they both make it much easier to define and roll out machine-level changes quickly in a multi-server environment. But the roads they take to arrive to the location of this holy grail are very different indeed, as we shall now see.
Table of contents
What They Are
Docker started life as an open-source side project called dotCloud. But when its creators realized its potential, it quickly became a top priority. It is a Linux-only tool developed in the Go language, and it builds on LinuX Containers (LxC) to create Virtual Environments (VE’s). Now pay attention kids, because a VE is radically different from a virtual machine (VM). A VM is created by a virtualizer tool or emulator (HyperV, VMWare, etc), and it is a full image of a source machine, including the OS, disk config, network and even virtual processors. The resulting bloated mass eats up quite a bit of disk space and is slow to deploy and start up.
Docker solves this problem by isolating the OS from the kernel. It then creates a ‘level-zero’ package from the kernel-machine baseline. Any subsequent changes are captured as snapshots called namespaces, and can be run in standalone containers as virtual systems. Snapshots capture only the changes from the ‘base template’, not the full machine setup (unlike VM’s). From this point, namespaces are stored and can be installed on their own to create full environments on any Docker-ready host.
Chef is a CM tool. Together with Puppet, they are the big boys of the CM marketspace. It was first released in 2009, and it helps admins and devops professionals manage their environments by making it easy to roll out changes and even provision new machines. Chef fully supports Windows as well as Linux and Unix, and it also boasts a proper GUI (though still not as slick as Puppet’s). However, there are complaints that Chef is a muddle to understand for newbies, and the documentation is not easy to wrap your head around, especially for newbies.
How They Work
Docker doesn’t create its own virtual computer with a distinct OS and processors and hardware emulation. A VE is a lite VM; it rides on the already existing kernel’s image of the underlying hardware, and only creates a ‘container’ in which to run your apps. It can even recreate the OS, since the OS is just another app running on the kernel. Think of Docker as a turbocharged version of LxC; it offers the following additional features that LxC doesn’t:
- Portable deployment across machines: you can use Docker to create a single object containing all your bundled applications. This object can then be transferred and quickly installed onto any other Docker-enabled Linux host.
- Versioning: Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc.
- Component reuse: Docker allows building or stacking of already created packages. For instance, if you need to create several machines that all require Apache and MySQL database, you can create a ‘base image’ containing these two items, then build and create new machines using these already installed.
- Shared libraries: There is already a public registry (https://hub.docker.com/) where thousands have already uploaded the useful containers they have created. Again, think of the AWS common pool of different configs and distros – this is very similar.
For an exhaustive list of Docker’s capabilities, follow this link.
Chef makes use of a master-agent setup, in which a central master server coordinates and sends out instructions to a number of agents installed on all other client nodes. The agents can even be installed from the client side using the ‘knife’ tool and SSH for easy deployment. All this is managed by either a GUI or a CLI using base Ruby as the DSL. The GUI is useful, but for most advanced tasks it will be inevitable that one will have to learn Ruby. Chef and other CM tools utilize an infrastructure-as-code model – to work effectively all infrastructure nodes being managed must be expressible purely in code, in this case Ruby. You define the changes you want and the subset of machines you want those changes to be applied to, then the Chef server does the rest. For instance, if you need to upgrade all Windows 2008 servers with the .Net 2.0 framework to .Net 3.0, you will define this on the Chef server and it will be rolled out. One caveat though – Chef’s implementation of ‘push’ from master to agents is still sub-par; the crowdsourced recommendation is that you instead configure your agents to periodically ‘phone home’ to check if the master has any changes for them to deploy on their machines. Needless to say, this is a major annoying drawback that Chef’s creators are working to resolve.
Chef configs are packaged into JSON files called ‘cookbooks’, and the software can run in either a client-server mode, called Chef-server, or standalone mode called ‘Chef-solo’. Part of Chef’s appeal is that a huge number of cookbooks have been created and shared freely on the net.
So which is best, Docker or Chef? As with so many complex choices, the answer is “It depends.” Depends on what you want to achieve, and the level of trust you have in the tool – Chef is tried and tested, while Docker is still very new and even its creators hesitate to recommend it for production environments. Actually, Docker and Chef can even complement each other; Docker is used for quickly provisioning new servers, and Chef is used for rolling out the small, detailed changes to existing machines, a task for which Docker may be ill-suited. Alternatively, Docker would be ideal in a setup mainly requiring creation of new read-only server instances, in which the change consists of an entirely brand-new server.