Terminology used in the world of Chef

Before jumping into a new territory, it's always wise to learn about the terminology used by the people already living in the environment. In this section, we'll try to make sense of what all those terms mean. After you are familiar with the terms, everything will start making more sense:

• Node: Any machine or cloud instance that you are configuring using Chef is known as a node. On a Chef server it's an object comprising of attributes and a run list specific to the instance.
• Chef server: A Chef server is a machine running chef-core-api, chef-solr, chef-web-ui, chef-expander, and chef-validator along with a backend data store such as PostGre/CouchDB and a messaging system such as RabbitMQ.
• Workstation: This is the machine where we'll be writing our Chef code.
• Repository: This could be a svn/Git repository where we'll be committing our code. This is useful to maintain revisions of code.
• Knife: This is a tool that you can use to manage different aspects of Chef.
• Cookbook: This is where you define anything and everything related to your infrastructure code. Cookbooks contain recipes, attributes, files/directories to be set up, templates, and so on.
• Recipes: Theses are part of a cookbook and most of the code meat goes into recipes.
• Attributes: Every code requires variables, and attributes are like variables holding values, which can be overridden.
• Roles: These are a way of arranging cookbooks together. For example, a web server is a role and it can comprise of cookbooks to set up the Nginx web server along with OpenSSL and a few other things.
• Run-list: This is an ordered list comprising of roles and/or recipes. The chef-client looks at items in run_list and executes them in an order specified in run_list.
• Resources: The chef-client does multiple tasks such as setting up packages, creating users, setting up cron jobs, executing scripts, and so on. Since Chef is meant to be platform-agnostic, we don't use service providers explicit to the system to do these jobs. For example, we don't say yum installs this package, instead we use a resource provider called package, which internally decides which underlying system to choose for the job eventually. This is pretty useful as it helps keep Chef code agnostic to platform changes.
• LWRP: Lightweight resources and providers (LWRP) are custom resources and providers that provide a way to perform a certain action. For example, you may write your own LWRP to manage Git repositories or install packages using Makefiles and so on.
• Metadata: A metadata file describes properties of a cookbook such as version, dependencies, and so on, and it's used to verify that a cookbook is deployed correctly on a node.
• Templates: Often, all we want to do is to specify a configuration that changes due to certain parameters, such as environment and so on. Templates allow for the creation of such configurations.
• chef-client: This is an agent that will run on instances that we want to bootstrap using Chef.
• Ohai: This is a piece of code that allows us to fetch useful information about a system along with other desired information. Ohai is used extensively to generate attributes that help in defining a node during a chef-client run.
• DSL: Chef cookbooks are primarily written in Ruby. Chef provides a Domain Specific Language (DSL) that helps to write a code easily and quickly.
• chef-solo: It's a tool similar to chef-client that will help us to execute a chef code.
• chef-zero: It's a lightweight, in-memory implementation of the Chef server, which can be invoked on a node using chef-client –z. This is going to be a standard going forward and will be replacing chef-solo in the future.

Now that we know the language, let's jump into the world of Chef and see what happens when a chef-client run happens.