DevOps for developers w/Chef [Part V] (Guest Blog Series)

We’re continuing Michael Hüttermann’s guest blog series on DevOps and its ability to streamline software development and delivery. Part Five details setting up infrastructure with Chef.

Setting up infrastructures, with Chef and friends

Setup and maintenance of infrastructure were automated even before the rise of Agile software development and the DevOps movement. But there have often been handcrafted, scripted solutions, barely readable by someone other than the original author. In recent years, a few tools in the field of configuration management started to gain popularity to address these challenges.

These tools, above all Chef, help developers and operations to work together and enable more transparency on the infrastructure level. After all, in today’s world of ever more complex and distributed IT systems, there’s an increasing need for developers to know about operational things and vice-versa. The infrastructure as code paradigm and its related tools can help to achieve this goal. Besides that, the ramp-up time for new machines and developers are dramatically reduced by also providing executable documentation of systems. Last but not least, service level requirements (SLRs) can be defined, managed and implemented even better. SLR relate to the warranty aspects of a service, defining the capacity, security, availability, and the service continuity requirements. The customer may have detailed and documented functionality requirements (the “what”) but has not defined the level of service required (the “how”), or those specs are put into Word documents.

Within the past few years, a number of tools have emerged that address exactly these problems. Some tools existed before terms such as DevOps and infrastructure as code were coined, but these movements helped to further spread the use of these tools and grow the whole community around it.  An example topology for infrastructure as code is shown in the diagram below. Let’s go through the main ideas next.

The example topology

Vagrant is used to set up test and development environments (as virtual machines). Vagrant gives you a command line interface to your Oracle Virtual Box. With Vagrant, you can leverage Chef cookbooks in development and test. With that approach, you can even easier develop new recipes or cookbooks on your local workspace.

Chef is used to provision infrastructure inside the VM. Chef is a great vehicle to underpin your DevOps initiative. The Chef server is the hub that provisions all nodes. The defined cookbooks (including any recipes) are applied to the nodes. Chef clients are running on the nodes to communicate with the server. The Chef workstation is the location where cookbooks are authored and data are uploaded to the Chef server.

Configuration files for both Vagrant and Chef are versionized in a version control system, with all its benefits, including change control and sharing changes in the whole team. A continuous integration (CI) server, such as Jenkins, listens to changes in version control and could propagate new versions to target environments for test purposes, automatically.


After we have a basic Vagrant project set up, we can add Chef provisioning to it, so we can install new software packages to the VM in an automatic fashion. As an example, let’s ask Chef to provision Apache2 httpd for us by adding some lines to our Vagrantfile.

Vagrant.configure(“2”) do |config| = “precise32”

config.vm.box_url = “” :forwarded_port, guest: 80, host: 7777

config.vm.provision :chef_solo do |chef|

chef.add_recipe “apache2”

chef.json = { :apache => { :default_site_enabled => true } }



Some further notes on that snippet. Please note the line that maps a port on the host machine to a port on the virtual machine, forwarding all the traffic. In our example we map port 7777 on localhost to port 80 on the virtual machine. Please also note that the Chef cookbook must be available to be found, and that we use a standard template for an Ubuntu box. Many more templates and boxes are just waiting for you and are offered as part of the Vagrant feature set or provided by the community, see Finally, this snippet shows Chef solo in action, that is a good choice for getting started. For more information on Chef, please consult the comprehensive documentation

A complementary approach is to use Docker, see Docker does not include an operating system, nor it does provide or modifies any VMs. Instead, Docker manages and deploys layered images. With Docker you can package your application and its dependencies in a virtual container that can run on any Linux server and runs in isolation.  Docker is a user-friendly, comfortable extension to common Linux container technologies including LXC.

In the future, orchestration of services and best-of-breed, lightweight tools will be even more important. The best process and tool chain also depends on the specific requirements. The long-lived host, VMs as well as physical machines, will be provisioned by configuration management tools like Chef. Fast feedback cycles in development and working with virtual images are good use cases to check out Vagrant and/or Docker respectively.


This closes my small essay about DevOps. We discovered that processes and tools are important, and culture and people are even more important, and should be the basis of your approach to deliver software. DevOps is a modern way of collaboration of development and operations. There are different strategies to catalog and rollout DevOps, and even more ways to implement it with tools. Chef is for sure an excellent choice to be considered as a backbone of your tool chain. So many reasons exist to get in touch or continue with DevOps. Why wait, let’s go!

Michael Hüttermann is freelance delivery engineer and expert for Continuous Delivery, DevOps and SCM/ALM. He has written the first dedicated books on Agile application lifecycle management (“Agile ALM”, Manning, 2011) and DevOps (“DevOps for Developers”, Apress, 2012). @huettermann.

Lucas Welch

Former Chef Employee