Editor's Note: This article on DevOps is one of a set that can be found, along with videos and other resources, within the SDxCentral DevOps Topic. Check this Topic regularly to see the latest updates.

Configuration management — the process for identifying artifacts and tracking changes on them, and establishing and maintaining baselines — should lie at the heart of all professional software projects. While there are many ways to execute configuration management, implementing the infrastructure and application delivery automation as code is a key first step. In this post, we’ll look at the benefits of an Agile approach for configuration management called “infrastructure as code" and a sample topology for it.

In today’s world of ever more complex and distributed IT systems, developers increasingly need to know about operations and vice versa. The infrastructure as code paradigm, and its related tools, can help achieve this goal and dramatically reduce ramp-up time for new machines and developers. By providing executable systems documentation, configuration management tools help developers and operations work together, with more transparency on the infrastructure underpinnings.

People have been automating infrastructure set-up and maintenance since before the rise of Agile software development and the DevOps movement, but early scripted solutions often were handcrafted and barely readable by anyone, other than the original author. In recent years, tools, such as Chef, have emerged as effective platforms to transform infrastructure into code. As the DevOps and infrastructure as code movements grow, the use of these kinds of tools is spreading and  a community is sprouting up to support them.

Infrastructure as code helps better define, manage, and implement service-level requirements (SLRs). SLRs relate to the warranty aspects of a service, defining the capacity, security, availability, and service continuity requirements. Sometimes the customer may have detailed and documented functionality requirements (the "what"), but not the specs (the “how”) for the delivery of that specified level of service. To address this gap, tools such as Chef and Puppet have emerged in the configuration management space. The following is an example topology for infrastructure as code that knits together such tools. Let's go through the main ideas first.

Sample Topology for Infrastructure as Code

In our example (Figure 1), Vagrant is used to set up test and development environments as virtual machines (VMs). Vagrant provides a command line interface (CLI) to an Oracle Virtual Box; it is designed to make it easier to develop new “recipes” or “cookbooks” with Chef on a local workspace.

Used to provision infrastructure inside the VM, the Chef server is the hub that provisions all nodes — applying the cookbooks (including any recipes) to the nodes via a client that runs on each node and communicates with the server. The Chef workstation is where cookbooks are authored and data is uploaded to the Chef server.

Configuration files for both Vagrant and Chef are version-ized in a version control system, which makes it easier to control and share changes with the whole team. A continuous integration (CI) server, such as Jenkins, listens to changes in version control and can automatically propagate new versions to target environments for test purposes.

After the basic Vagrant project set up, we can add Chef provisioning to it to install new software packages to the VM in an automatic fashion. As an example, we can ask Chef to provision Apache2 HTTP for us, by adding some lines to our Vagrant file.

Vagrant.configure("2") do |config| config.vm.box = "precise32" config.vm.box_url = "http://files.vagrantup.com/precise32.box" config.vm.network :forwarded_port, guest: 80, host: 7777 config.vm.provision :chef_solo do |chef| chef.add_recipe "apache2" chef.json = { :apache => { :default_site_enabled => true } } end end

Note, in this snippet:

• There is a line that maps a port on the host machine to a port on the virtual machine to forward all the traffic — specifically, we map port 7777 on the local host to port 80 on the virtual machine.
• The Chef cookbook must be available to be found.
• We used a standard template for an Ubuntu box. (Many more templates and boxes are offered as part of the Vagrant feature set or provided by the community.)
• We used Chef solo in action, which is a good choice for getting started. (Comprehensive documentation on Chef can be found here 

A complementary approach is to use Docker; however, Docker does not include an operating system, nor does it provide or modify any VMs. Instead, Docker manages and deploys layered images. With Docker, an application can be packaged along with its dependencies in a virtual container that can run on any Linux server and run in isolation.  Docker is a user-friendly, comfortable extension to common Linux container technologies, including LXC.

As best-of-breed, lightweight tools are developed and adopted, such as Chef, Vagrant, and Docker, it will become easier to take advantage of automated infrastructures. Because of the benefits that infrastructure as code can provide — accelerating time-to-market, helping manage scale and complexity, and safeguarding systems — I believe it will become even more important for the automated orchestration of services in the future.