Before learning about “What is Chef”, we should know what is a configuration management tool. A configuration management tool is a software which configure systems programatically using some predefined set of configurations. Suppose if we want to update /etc/hosts file on all our machines. This can be done either login to all the machines through SSH and change the hosts file with your new hostname and IP address. The other way is to write some kind of script which updates your file with required data. When the tasks are simple and less number of hosts we can depend on some scripting languages like Python, Ruby or even Shell scripting. Both these have limitations and human errors can occur. That is where configuration management tools will come into picture which helps us configuring systems with ease. The Opscode Chef is one such configuration management tool similar to Puppet, Ansible and Saltstack which works for you.

History/background of Opscode Chef

Chef is written in Ruby and Erlang

  1. Ruby for core configuration for writing your recipes and cookbooks
  2. Erlang for API to interact with cloud providers like AWS, GCP, Azure.

A number of Puppet developers felt that Puppet didn’t meet their needs. They started their own configuration management tool called Chef, heavily inspired by Puppet.

What is the difference between Puppet and Chef?

The biggest outward difference between Puppet and Chef is that Chef uses pure ruby as its “recipes” whereas Puppet uses its own configuration language called as Domain-specific language(DSL) based on ruby. So we no need to learn one more DSL to accomplish our tasks using Chef. One more difference is Puppet follows Server-client model but Chef adds one more layer called Chef workstation which is used as a playground for writing and testing your chef code.

Chef architecture in nutshell

As mention Chef architecture is bit different when compared to Puppet and Ansible. Chef has three major components which shown below.

  • Chef workstation
  • Chef server
  • Chef nodes

chef-opscode-architecture

Chef Workstation explained

Chef admins do most of their work here, like writing cookbooks, updating changes to a centralised git repo, running knife and pushing cookbooks into chef server. This workstation is one stop for all your chef administration from building cookbooks to troubleshooting, writing code to orchestration, you name a chef task you can do that from chef workstation. Tools like knife, kitchen, chef client works from this. Don’t worry, I will explain each of these terms and many more in our next Chef terminology post in coming days.

Chef server explained

This is a central part of chef where cookbooks are converted to respective data to be sent to chef clients. Major component on chef server are Bookshelves, messaging queues, PostgreSQL DB, Chef server web UI, Chef Solr.

The chef is infrastructure as a code.

Three components can build infrastructure

A code repo which contains all our configurations

Backup data which we can pull and store in new machines to replicate present production-ready machines

A bare metal or VM for hosting or incorporating the code and backup data.

Chef nodes explained

Is where your chef-client is installed to pull configurations from chef server. Every 30mins chef-client pull data from chef server and try to apply those changes on the server node.

In our next post, we will see chef terminology in a more meaningful way instead of alphabetical order. We will learn terminology in a layered architecture as shown below sequence.

Layers of Chef

First layer: Organisations

Second layer: Environments

Third layer: Roles

Fourth layer: Nodes

Fifth layer: Chef-client

Sixth layer: Resources

Seventh layer: Attribute and action

Stay tuned to our next post.

Post Views: 11,026
The following two tabs change content below.
My Twitter profileMy Facebook profileMy Google+ profileMy YouTube channel

Surendra Anne

Mr Surendra Anne is from Vijayawada, Andhra Pradesh, India. He is a Linux/Open source supporter who believes in Hard work, A down to earth person, Likes to share knowledge with others, Loves dogs, Likes photography. He works as Devops Engineer with Taggle systems, an IOT automatic water metering company, Sydney . You can contact him at surendra (@) linuxnix dot com.