Getting started with Chef

Chef is a complete framework to automate infrastructure operations to build servers or applications from scratch or add new configurations to existing systems. Servers are managed by code, written in Ruby and it provides the facility to test and reproduce machines.

Chef basic infrastructure contains at least one server and one node. Each node is maintained and set up by chef-client and is responsible for executing recipes and configuring environments to run applications. It contains the abstract-level configuration of a server or an application.

Tiny code blocks in recipes contain a set of commands that execute on a system sequentially, and gradually configure the whole environment. The complete process is fully automated and without human administration; Chef can set up several nodes.

For instance, if you want 100 servers with Python/Django running Nginx with uWSGI and you want to have the same installations on each node, Chef can make this happen in minutes; it also provides you with the switch to turn your nodes on and off. It can check for revision control system and is responsible for pulling recent updates from the repository. You can easily revert the system to the previous state if something does not happen according to your needs. With Chef, system administrators can spend less time on maintenance and more time on innovation.

Traditional infrastructure is slow and tedious; it involves many steps to build servers and running applications. All your configurations are in one place and you will not worry about the several configurations of different servers. While scaling your application, it is highly recommended to use Chef, as you can easily split your app on to different servers by using roles and nodes. You do not have to install the same application 10 times on one machine or any other, just create a new node in Chef server and in a few minutes, the server will be ready to handle the application. Also, there is no need to maintain the documentation of servers, as the recipes' code is self-explanatory and easy to grasp for a new user.

Chef is developed by Chef Software, Inc. and recently they released Version 11.0. Chef code is completely rewritten in Version 11.0, swapping out Apache CouchDB for PostgreSQL and Ruby for Erlang. The result is massive and now a single Chef server can handle more than 1000 nodes (clients).

Chef is provided in the following three versions:

• Private Chef: This is an enterprise version that supports multi-tenancy to provide a highly scalable server to handle several nodes. It should be located in the client's premises and managed behind a firewall.
• Hosted Chef: This is an SAAS service managed by Chef Software, Inc. It is a cloud-based service and highly available (24/7 x 365), with roles and resource-based access controls. It does not require a firewall.
• Open source Chef: This is a community-driven version with almost identical features, and it should be managed locally and behind the firewall. The latest features initially were released for the commercial version and then gradually released in the open source version. The system administrator will be responsible for applying updates, defining roles, data migrations, and ensuring that the infrastructure scales appropriately.

Chef has been primarily divided into the following three parts:

• Chef server: Chef server is responsible for handling nodes and providing cookbooks to clients.
• chef-client: The chef-client actually executes the recipes and configures the system. It also resolves each application dependency. The Chef architecture is based on the Thin server, Thick client model. There is no need for continuous communication with the server, as the client retrieves the cookbooks from the server and processes recipes on the client end. The server distributes data to each node including cookbooks, templates, files, and other items. The server contains the copy of all items. This approach ensures that each node has persistent data and files.
• Knife: Knife is a tool that provides an interface between local-repo and the server. It is used to retrieve cookbooks, policies, roles, environments, and other items.