Working in production today often means continuous deployments and an environment distributed all over the world. When your infrastructure is decentralized and cloud-based and you’re dealing with frequent deployments of largely identical services across largely identical servers, having a way to automate the configuration and maintenance of everything is a large boon.

Deployment management tools and configuration management tools are designed for this purpose. They enable you to use recipes, playbooks, templates, or whatever terminology to simplify automation and orchestration across your environment to provide a standard, consistent deployment.

In short, configuration management deals with maintaining the hardware and software of a business. It involves making a detailed recording of the information about the computer system and updating it as needed. This includes listing all of the installed software, the network addresses of the computers, and the configuration of different pieces of hardware. It also means creating updates or ideal models that can be used to quickly update computers or restore them to a predefined baseline.

Configuration management software makes it easy for a system administrator to see what programs are installed and when upgrades might be necessary.


You might be thinking that this is common sense and you don’t need to spend your company’s budget on such a tool. You’re an expert scripter, right? You can just write a bunch of scripts to maintain your systems. Technically yes, you can. However, IT pros wear many hats, have fires to quench, and juggle projects every day. Unless you’re one of the lucky few, you don’t have the luxury of spending countless hours on a bunch of scripts. A script can easily make a change, but enforcing that change is a different story. You’re not really going to create thousands of scheduled tasks to continually execute your scripts, and then make those same changes repeatedly, are you? Because that’s not feasible

Provisioning environments, deploying applications, maintaining infrastructures–these are all critical yet delicate tasks traditionally done by hand. What if we could get a machine to do all that stuff for us, not just saving hours of work but also removing the element of human error?

There are several considerations to keep in mind when choosing a tool in this space. One is the model for the tool. Some require a master-client model, which uses a centralized control point to communicate to distributed machines, while others can or do operate on a more local level. Another consideration is the makeup of your environment. Some tools are written in different languages and support for particular OSs or setups can vary. Making sure your tool of choice will mesh well with your environment and the particular skills of your team can save you a lot of headaches here.

Chef is a powerful automation platform that transforms infrastructure into code. Whether you’re operating in the cloud, on-premises, or in a hybrid environment, Chef automates how infrastructure is configured, deployed, and managed across your network, no matter its size.

Chef is an open source tool for configuration management, focused on the developer side for its user base. Chef operates as a master-client model, with a separate workstation needed to control the master. It’s based in Ruby, with pure Ruby used for most elements you write. The Chef design is transparent and based on following the instructions it’s given, which means that you’ll have to make sure your instructions are clear.

Before considering Chef, make sure you’re familiar with Git, as it’s required for configuration, and Ruby, as you’ll have to be writing in it.

Chef is good for development-focused teams and environments. It’s good for enterprises looking for a more mature solution for a heterogeneous environment.

Free open source version, standard and premium plans priced on a per node annual basis. The prices start at $137/node/annual for Chef Automate, or $72/node/annual for Hosted Chef.


  • Rich collection of modules and configuration recipes.
  • Code-driven approach gives you more control and flexibility over your configurations.
  • Being centered around Git gives it strong version control capabilities.
  • “Knife” tool (which uses SSH for deploying agents from workstation) eases installation burdens.


  • The learning curve is steep if you’re not already familiar with Ruby and procedural coding.
  • It’s not a simple tool, which can lead to large code bases and complicated environments.
  • Doesn’t support push functionality.



You can download it from here. Install it as you would any other windows application.

Let’s create a cookbook and update the recipe

cd c:/
chef generate repo workstation-repo
cd workstation-repo

chef generate cookbook cookbooks/workstation

The above commands create a template of a cookbook. Now, to write the first recipe, open the default.rb file in the Recipes folder.

file ‘C:\Chef-Output\test.txt’ do
content ‘This is a test file’
action :create


You can execute the recipe by using the following command

chef-client -z cookbooks/workstation/recipes/default.rb



Cookbook can have multiple recipes and you can add one easily

chef generate recipe cookbooks/workstation webServer
chef generate recipe –help

you can also verify the syntax as shown below

chef exec ruby -c cookbooks/workstation/recipes/default.rb

lets update the webServer.rb to do some useful stuff


and it can be executed as mentioned below

chef-client -z “workstation\recipes\webServer.rb”

You could also execute the default recipe as

chef-client -z –runlist “workstation”

and a specific recipe as 

chef-client -z –runlist “workstation::webServer”

and multiple recipes as

chef-client -z –runlist “recipe[workstation::default],recipe[workstation::webServer]”

and multiple cookbooks as below

chef-client -z –runlist “recipe[example],recipe[workstation]”


Usually, functionalities will be broken into pieces and default.rb would include all of those, update the default.rb as below to include a recipe

include_recipe ‘workstation::webServer’


Ohai is a tool that is used to collect system configuration data, which is provided to the chef-client for use within cookbooks. Ohai is run by the chef-client at the beginning of every Chef run to determine system state. Ohai includes many built-in plugins to detect common configuration details as well as a plugin model for writing custom plugins.

The types of attributes Ohai collects include but are not limited to:

  • Operating System
  • Network
  • Memory
  • Disk
  • CPU
  • Kernel
  • Host names
  • Fully qualified domain names
  • Virtualization
  • Cloud provider metadata

and it be used as mentioned below

ohai hostname
ohai hostname,time
ohai memory/total

and all these information can be accessed on the recipe as shown below

chef generate recipe cookbooks/workstation nodeAttributes


update the nodeAtrributes.rb as below


and run the following command

chef-client -z “workstation\recipes\nodeAttributes.rb”


A cookbook template is an Embedded Ruby (ERB) template that is used to dynamically generate static text files. 

chef generate template cookbooks\workstation index

chef-client -z –runlist “workstation::webServer”


update the index.erb with the below


Use the cookbook_file resource to transfer files from a sub-directory of COOKBOOK_NAME/files/ to a specified path located on a host that is running the chef-client.


you could also create a file with Chef

chef generate file cookbooks\workstation index.html


Use the file resource to manage files directly on a node.


Unit Testing
The intent of unit testing is to confirm that given specific input, the recipe yields the expected output.


update the default_spec.rb with below


Integration testing
The intent of integration testing is to verify that the end state of the system is in fact what we wanted after Chef converges the node so we can have a higher degree of confidence that our code is doing what we need.

Integration testing Chef cookbooks is often performed in Test Kitchen.


Chef Supermarket is the site for community cookbooks. It provides an easily searchable cookbook repository and a friendly web UI. Cookbooks that are part of the Chef Supermarket are accessible by any Chef user.

There are two ways to use Chef Supermarket:

  • The public Chef Supermarket is hosted by Chef and is located at
  • A private Chef Supermarket may be installed on-premise behind the firewall on the internal network. Cookbook retrieval from a private Chef Supermarket is often faster than from the public Chef Supermarket because of closer proximity and fewer cookbooks to resolve. 


update the metadata as shown below


update the berksfile as shown below


following commands would download and install, upload the dependency cookbooks


Now, update the windowsFeatures.rb as 


The Chef server acts as a hub for configuration data. The Chef server stores cookbooks, the policies that are applied to nodes, and metadata that describes each registered node that is being managed by the chef-client. Nodes use the chef-client to ask the Chef server for configuration details, such as recipes, templates, and file distributions. The chef-client then does as much of the configuration work as possible on the nodes themselves (and not on the Chef server). This scalable approach distributes the configuration effort throughout the organization.



  1. Signup on and create a organization.
  2. Download starter kit
  3. Extract repo
  4. Replace cookbooks with yours


and you can add the nodes as shown below, use the workstation to perform the following actions


and run the following command on the client