Hello All, today we are going to talk about Chef, Yes Chef, and no I’m not talking about the Chef that cooks food, obviously. Chef is the automation platform for DevOps and it literally transforms your Infrastructure into code. It does not matter whether you are operating from on-premise or cloud or hybrid data center. Chef is a Configuration Management tool, written in Pure Ruby & Erlang. Chef was initially released in January 2009 and it is owned by Opscode. Using Chef you can deploy a new Server, install a software and configure it, transfer file, create directory and navigate through them, read/write a file and all the other task that is executed in your data center on daily basis, and the best part is you can automate all these task and simultaneously execute them all across the data center. Chef guarantees consistency, whether you run it first time or hundredth time, you will get same result.
Chef is an agent based tool, which means that every client has to have a chef client, which is registered to the Chef server. Chef configuration is similar to any Client-Server configuration. It has a centralized server known as Chef Server, and end user servers have a client which is registered to the server known as Chef Client. There is another component called Chef Workstation. Chef Workstation is basically where the task or commands or simply automation scripts is written, it is tested locally and submitted to the Chef server along with the list of clients which should execute the script. Chef server then executes the code on client’s Server using Chef client agent which is already present in clients. Chef Workstation also registers the Chef Client with the Chef Server. Once client is successfully registered with Chef Server, Chef Workstation and Chef Client never interact with each other again.
The automation code, I mentioned earlier is written in files known as recipe, similar recipes are clubbed together into package known as Cookbooks. Each recipe are designed to perform a certain task. Recipe can be reused any number of times in one or more cookbooks, just as functions in C Language.
The architecture in above image shows the in-depth configuration of each component in Chef Infrastructure. I’ve mentioned earlier the abstract of each component i.e. Chef Server, Chef Client & Chef Workstation. Let’s go over each component in detail.
Chef Server is heart & soul in Chef Infrastructure. Starting with the release of Chef server 11, the front-end for the Chef server is written using Erlang. It is a centralized component which handles all the nodes, stores all the Cookbooks and their respective recipes, synchronize each node with the latest version of cookbook available & accept new or updated recipe from Chef Workstation. The Chef server acts as a hub for configuration data. The Chef server can scale to the size of any enterprise and is sometimes referred to as Erchef. Following diagram shows the various components of a Chef server and their relation. Even though the Chef server is authored in Erlang, writing code in Erlang is NOT a requirement for using Chef.
Chef Manage — It is an Ruby on Rails 3.0 application that hosts the web interface for Chef Server.
Bookshelf — Bookshelf is used to store cookbooks that have been uploaded to Chef Server by one of the Chef Workstation. Cookbooks are version controlled. If two different cookbooks or different version of cookbook have same file or template, Chef server will only store that file only once, in order to avoid redundancy. All Cookbooks are stored in dedicated repository.
Node or Chef Clients
A node is any machine, it can be physical, virtual, cloud or even network device that can be managed by Chef Server. Node is end user component, which can either hosts an application or database or can be used to access some remote application or data. Every node has an agent known as chef-client which runs locally to achieve following goals —
— Registering and authenticating the node with the Chef server.
— Building the node object.
— Synchronizing cookbooks.
— Compiling the resource collection by loading each of the required cookbooks, including recipes, attributes, and all other dependencies.
— Taking the appropriate and required actions to configure the node.
— Looking for exceptions and notifications, handling each as required.
Ohai — It is a tool that collects system configuration data, which is then provided to chef-client to run the 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
— Host names
— Fully qualified domain names
— Cloud provider metadata
Attributes that are collected by Ohai are used by the chef-client to ensure that these attributes remain unchanged after the chef-client is done configuring the node.
A Workstation is a node outside your infrastructure, which runs ChefDK (Chef Development Kit) which used to create cookbooks, recipes and push cookbooks along with updated run-list. User performs many tasks at Workstation, the tasks are as follows —
— Developing and testing cookbooks and recipes
— Testing Chef code
— Keeping the chef-repo synchronized with version source control
— Configuring organizational policy, including defining roles and environments, and ensuring that critical data is stored in data bags
— Interacting with nodes, as (or when) required, such as performing a bootstrap operation
Workstation itself have many components, which helps us to achieve one or more tasks mentioned above. The components include knife, chef-repo, knife.rb.
Knife — knife is a command-line tool that provides an interface between a local chef-repo and the Chef server. Knife helps users to manage:
— Cookbooks and recipes
— Roles, Environments, and Data Bags
— Resources within various cloud environments
— The installation of the chef-client onto nodes
— Searching of indexed data on the Chef server
chef-repo — The chef-repo is the repository structure in which cookbooks are authored, tested, and maintained.
knife.rb — A knife.rb is a configuration file which is used to store details required by knife commands.
Well, that’s it for today folks. I know the terminology is very confusing and might be difficult to grasp but that is what Chef is, I’ve tried to simplify the jargon’s as much as I could, I hope that you folks learned something from the whole blog post if not everything. I’ll be doing a walk-through for deploying our own Chef based environment using Amazon EC2 servers (because it is fast and free 🙂). Until then go through the post again or for more details visit the Chef website and if you have any queries, do get in touch, I would love to hear from you guys. Take Care, I’ll be back again soon with some new technologies in simple words.