The days of DIY system administration are rapidly coming to a close. Why? Because the open source tools available are just too good not to use. Presenting Bcfg2, Cfengine, Chef and Puppet.
Aaron Peterson, seasoned systems engineer, Technical Evangelist of Opscode, Inc.,presented. Chef is primarily a configuration management library system, andsystem integration platform (help integrate new systems into existing platforms.)
Chef grew out of power user dissatisfaction with aspects of Puppet. Made available in 2009, Chef is in beta (version 0.9.x.x) and is settling down now.
Key Principles of Chef’s Design:
- The cloud is the future, be able to operate in the cloud. (For example,automated provisioning of new server instances.)
- Fully automated infrastructure is hard. Make it easier through configuration sharing and re-use. Chef is a library for CM (ora CM system built on that library).
- Facilitate integration of new servers into an existing platform.
- Describe the end state, and Chef will get you there and keep you there. However, Chef only takes actions when they differ from the description of the end product.
- Reasonability (easy to think about).
- Sane defaults (yet easily changed).
- Hackability (easy to extend).
- TMTOWTDI (There Is More Than One Way To Do It).
- Pragmatism. Chef’s language is Ruby with some DSL. The Ruby mix allows you to include programming.
- Enable infrastructure as code to benefit from software engineering practices such as agile methodologies, code sharing through github, release management, etc.
- Enable you to solve your problem.
- Data-driven. Configuration is just data.
- Cultivate a culture of quality and reusability through Chef cookbooks. Example freely available cookbooks: Postgresql, tomcat6, Apache2, Kickstart, OpenSSL, etc.
- Chef exposes data and behavior over HTTP to enable integration with external tools.
- Recipes are run in order. Nodes have a run list: what roles or recipes to apply, in order.
Example: Run List
Chef: Infrastructure is Code
Chef Recipe: Install the Postfix Package
package "postfix" do
Chef Recipe: Install Multiple Packages
package "apache2" do
package "apache2-mod_php5" do
package "php5" do
Chef Recipe: Upgrade sudo package and configure /etc/sudoers using a template
package "sudo" do
template "/etc/sudoers" do
:sudoers_groups => node[:authorization][:sudo][:groups],
:sudoers_users => node[:authorization][:sudo][:users]
- Manage configuration as resources.
- Put them together in recipes.
- Track it like source code.
- Configure your servers.
The above example is two part, a package resource recipe, and an accompanying file template recipe.
Under the hood, a Chef Provider will handle the required action to bring the resource into the described state. Example provider for the above:Chef::Provider::Package::Yum.
Recipes are lists of resources (files, packages, processes, filesystems, users, etc.)
Cookbooks are packages of recipes.
How Does Chef Work?
- Install Chef. Install all the Ruby gems/dependencies.
- Create your Chef repository
git clone git://github.com/opscode/chef-repo.git
git clone git://github.com/opscode/chef.git
Chef assumes you start from a base OS. (Which is particularly true in cloud environments, where it’s financially feasible for servers to have brief lifetimes.)
- Fire up Chef Server and Chef Client. Managed clients do most of the work.(Or else you can use Chef Solo which can run recipes without a server).
Chef prefers failure over non-deterministic “success” when something goes wrong.If it cannot complete the recipe, in full, and in sequence, that is failure.This is one of the primary things differentiating it from Puppet, where ordering is non-deterministic and a policy may be fulfilled partially but it can be hard to predict which parts get fulfilled.
Example of Node Attributes
default[:nginx][:gzip] = "on"
default[:nginx][:gzip_http_version] = "1.0"
default[:nginx][:gzip_comp_level] = "2"
default[:nginx][:gzip_proxied] = "any"
default[:nginx][:keepalive] = "on"
default[:nginx][:keepalive_timeout] = 65
default[:nginx][:worker_processes] = cpu[:total]
default[:nginx][:worker_connections] = 4096
Limitations (or Strengths, depending how you look at it)
Chef is written primarily for Ubuntu (handling Debian packages); there is also support for Red Hat but it lags.
There are three cloud providers supported by “knife”, the Chef command line tool: Rackspace, Amazon EC2, Terremark.
Example: instantiate a server; configure it as a Ruby-on-Rails Web app server:
knife rackspace server create 'role[rails]'
knife ec2 server create 'role[rails]'
knife terremark server create 'role[rails]'
Configuration Management Tip from Aaron Peterson
Never depend on a single sysadmin’s knowledge. Put all the knowledge into a Chef cookbook.
Because Chef exposes an HTTP API, there is a Web UI. It is entirely optional;anything that can be done through the Web UI (such as adding users or roles) can be done on the CLI with “knife”. The commercial platform has some additional Web UI features, but again, the primary use is expected to be via libraries, following the “infrastructure as code” paradigm.