It’s kitchen time again. Put that Chef hat on and let’s check out some more cool stuff.
In our last post “Part 1: Understanding Chef Basics with 3 ‘Wh’ Q’s,” I bundled a whole lot of Chef ingredients. (That features for you lay Chefs.)
To quickly refresh the list, and your memory, we discussed Chef components and elements using three Wh Q’s:
What are the elements of Chef and their functionalities?
What are the types of Chef elements, if any?
What are the components of Chef elements and their functionalities?
Again, you can read about Chef components and elements in more detail here: “Part 1: Understanding Chef Basics with 3 ‘Wh’ Q’s.”
In this post, I’ll discuss a few more major concepts and dive right into setting up Chef for your use.
As mentioned above, Chef-nodes are nothing more than machines that are managed by Chef-client. Each node has node objects that constitute the important aspects of Chef-client. There are two primary node objects:
Attributes are just profiles for each node. They hold any and all details about the node.
What do they say about a node?
Attributes say three things about a node: its current state, its state at the end of a previous Chef-client run, and its expected state at the end of the current Chef-client run.
How do they define a node?
Using the current state of the node, it defines cookbooks, roles and environments.
How is an attribute list built?
The following are some of the ways an attribute list is built:
Using data from Ohai (detects attributes on nodes)
Using node object from the previous Chef-client run
Using the updated node object from the current Chef-client run
A run-list ensures that the node is running in the desired state by defining necessary configuration settings, which includes an ordered list of roles and recipes. Specific to a node, run-lists are maintained using Knife.
Policies map business requirements to settings stored in Chef server. Policies are defined by the following:
Roles: Defines processes and patterns that are applicable across the organization.
Data Bags: Global indexable variables kept in encrypted storage.
Environments: Real-life workflow mappings to configurable and manage settings.
Cookbooks are fundamental units of configuration and define a scenario. Chef-client uses Ruby on Rails to create cookbooks. It has three important components:
Attributes: Attributes set here override the attributes set in nodes. During each Chef-client run, attributes are checked for differences and updates set in the node and updated appropriately.
Recipes: A collection of resources and defined using patterns, recipes represent the core element and are stored in a cookbook. The order of execution is dependent on the run-list order.
Versions: This represents a set of functionalities not used in the cookbook it is based on.
In addition to the above components, file distributions, templates, configuration files and libraries are also part of cookbooks.
Well, we’ve come to the end of part 2. Look for more posts about Chef in the coming days!
In the meantime, get excited with us about our FREE upcoming webinar, “A Crash Course on AWS for Web Developers.” If you’re an app developer looking for ways to improve performance and streamline workflows in your environment, then jump here and register for this great event led by Flux7 CEO Aater Suleman.
Just by registering, you have a chance to win a FREE assessment valued at $495!Hope to see you there!