What is Chef, and what is the big deal #

In Marketing words:

Chef is an open-source systems integration framework built specifically for automating the cloud. No matter how complex the realities of your business, Chef makes it easy to deploy servers and scale applications throughout your entire infrastructure. Because it combines the fundamental elements of configuration management and service oriented architectures with the full power of Ruby, Chef makes it easy to create an elegant, fully automated infrastructure.

Infrastructure automation is not a new thing. CFEngine for example is a system that has existed for years, though it has never impacted like Chef or Puppet have.

For me the big deal these days is primarily the ability to create a reproducible environment. Yes, i am lazy, and yes i like to automate everything i can. But the fact that i can rely on my systems to behave equally after every installation for me personally is the biggest deal.

I’ll try to cover some more Chef related topics here in the furute.

Why Chef #

I guess this boils down largely to personal preference. The features that got me into chef, over puppet are as follows

The DSL of Chef just looks nice to me #

A statement in Chef to deploy a template looks like

template "#{node[:phpfpm][:pooldir]}/claus.conf" do
    source "fpm-claus.conf.erb"
    mode 00644
    owner "root"
    group "root"
    notifies :restart, "service[#{node[:phpfpm][:service]}]"
end

While in Puppet it looks like:

file {"/usr/local/bin/jvm_options.sh":
    mode    => "664",
    owner   => "root",
    group   => "root",
    content => template("jvm/options.erb"),
    notify  => Service[apache2]
}

As i said, personal preference.

The ability to seamlessly switch between Chef DSL and Ruby #

Chef’s DSL is an extension to ruby, so while writing recipes you can rather seamlessly incorporate ruby code.

For example a loop to install a bunch of packages:

%w{spamassassin procmail razor fetchmail python-spf}.each do |pkg|
    package pkg do
        action :install
    end
end

Interaction between Nodes #

This is among the primary reasons i prefer Chef. A good example to illustrate this, is the Nagios Cookbook. The Nagios Server Recipe can search for all nodes, and will create a configuration for those, while the Client Cookbook will find all Servers and allow Access from those.

Another example could be a Loadbalancer Cookbook that would use a ‘role’ search on all nodes to identify it’s web servers, and create the configuration accordingly:

search(:node, "role:web-fe-group-a") do |r|
    # Configure LB
end

Data Bags #

A Data Bag is a collection of json objects stored in the Chef Server that can be searched and used in recipes.

These can be used to create users for example. A databag for a user could look like:

{
    "comment": "Example User",
        "groups": "users",
        "gid": 1041,
        "id": "example",
        "shell": "/bin/false",
        "uid": 4131
}

To use this in a recipe, you would do something like:

search(:users, 'groups:users') do |u|
    user u['id'] do
        uid u['uid']
        gid u['gid']
        shell u['shell']
        comment u['comment']
        supports :manage_home => true
        home "/home/#{u['id']}"
    end
end

My History with Chef #

The first commit to my personal Chef Repository is from 2011. I got started on Chef by using the free Trial on opscode.com. It allows the management of up to 5 nodes for free. This is probably the best way to get acquainted with Chef development, as setting up the full stack can be a hassle.

I then moved to using littlechef to handle my systems. Littlechef is Chef Solo with some extensions to manage a bunch of nodes. To learn Chef, this system is also a nice alternative to setting up the full stack.

Today i run a mix of `chef-solo' in a Cobbler environment, and Chef with the Community Server to handle the entire life cycle of an installation.