Chef automation platform uses simple cooking analogies To provision, build, and deploy environments rapidly
JohnCrawfordIBM 100000BANX Comments (2) Visits (4486)
Chef uses cooking analogies
by Budi Darmawan
This time, I’ll talk like a foodie… about chef, cookbooks and recipes. Well, this is not exactly about food though. The chef here would ‘cook’ the recipe to build a distributed server environment. This blog post describes my journey in understanding chef and its implication for a distributed system implementation.
Chef is owned by Opscode, Inc., (www.opscode.com) who describe it this way:
Chef is an open-source automation platform built to address the hardest infrastructure challenges on the planet. Chef gives you the power and flexibility you need to move faster in a complex world - from rapid provisioning and deployment of servers to the automated delivery of applications and services—at any scale.
So chef would allow configuration of servers (real or virtual) and automating the configuration of those devices. That means a complex distributed system deployment can be defined and implemented using the functionality provided by chef. My effort is related to implementation of a software solution that is based on a distributed configuration of machines.
Chef has two components, a server and a client. The chef-server acts as configuration file provider. It receives HTTP requests. Information is retrieved using a standard HTML GET protocol. The chef-server also acts as a repository for client state data. Any chef clients which are connected to the chef server will store configuration files that contain data relating to the roles and recipes which have been retrieved and executed by that client.
The chef-client performs all configuration tasks. It retrieves its role data from the chef server and then expands and parses the data to determine which recipes it must execute to fulfill that role. The chef client then executes the recipe (in its proper sequence) to build the role.
Notes on roles
Recipes are the main component of the chef client. They are written in Ruby and organized in a cookbook. Typically there is a default recipe for each cookbook which will invoke a file named default.rb. All other recipes within the cookbook must be referenced by their specific name.
The cookbook contains not just the recipes, but also the supporting resources such as default attribute definitions, installation files, object templates and others.
Now that I have laid out the basic concepts of chef, let me give you an example. In the code that follows, we are building a set of database servers for DB2.
In this example, all operations are related to DB2, so we can define only one cookbook: the DB2 cookbook. Our sample cookbook contains the following files:
Some attributes can be pre-defined in the cookbook, such as:
This DB2 cookbook would include the following recipes:
In order to determine the appropriate roles, thought must be given to the various types of servers which could possibly be required. The following are some of the possibilities:
With that structure defined, there are three possible roles. I will call them db2, db2appl1 and db2appl2. The definition would be created in such a way that db2appl1 and db2appl2 include the db2 role.
Sample role db2:
Sample role db2appl1:
With this structure defined, the command to build the appl1 DB2 server is invoked on the proposed db2appl1 server with the command:
chef-client --json-attributes http
This would resolve the role into its individual recipes to be invoked:
Each recipe would be invoked in sequence to install DB2, setup the environment variable and then invoke the DDL.
As you can see, chef takes many of the automation tools and techniques that have been used over the years (e.g. scripts and configuration files) and allows you to map your entire infrastructure to code elements. By assigning different roles to each client, Chef can coordinate the deployment of complex applications in your environment.
Budi Darmawan is an Enablement Specialist with IBM Cloud and Smarter Infrastructure group. He develops and presents training classes from his home base in Austin, Texas. Budi has been with IBM for 23 years.