Chef Tutorial

Chef is an automation platform that configures and manages your network infrastructure. Chef transforms infrastructure into code. “Infrastructure into code” here means “deploy your code/application/configuration and policy” on many machines or instances automatically via your code.

As shown in the diagram below, there are three major Chef components:

+ Workstations: simply personal computers where all development configuration code is created, tested, and changed before uploading to the Chef Server. Each Chef workstation also has a command line tool called “Knife”, which will be used to upload configuration changes to the Chef Server.

Workstations are the place to write Recipes and Cookbooks:

++ Recipes: A Recipe is a collection of resources that describes a particular configuration or policy. It describes everything that is required to configure part of a system and in which order it is to be used. The user writes Recipes that describe how Chef manages applications and utilities (such as Apache HTTP Server, MySQL, or Hadoop) and how they are to be configured.

++ Cookbooks: Multiple Recipes can be grouped together to form a Cookbook. A Cookbook defines a scenario and contains everything that is required to support that scenario. A Cookbook also includes attributes, libraries, metadata, and other files that are necessary for supporting each configuration. Cookbooks are created using Ruby language and Domain Specific languages are used for specific resources.

+ Chef Server: The centralized store of our infrastructure’s configuration. The Chef server stores, manages and provides configuration to all nodes that make up the infrastructure.

+ Nodes: are the servers where your code needs to run. Chef server manages Nodes by Chef client, which is a software installed on each Node. Chef client retrieving configuration information from the Chef Server. Nodes can be a cloud-based/virtual/physical server in your own data center.

Any changes made to your infrastructure code must pass through the Chef server in order to be applied to nodes. Prior to accepting or pushing changes, the Chef server authenticates all communication via its REST API using public key encryption.

Chef client periodically pulls Chef server to see if there are any changes in cookbooks or settings. If there are changes then Chef server sends the latest configuration information to Chef client. Chef client applies these changes to nodes.

Sample Cookbook showing configuration of switch interface as Layer 3

cisco_interface 'Ethernet1/1' do
action :create
ipv4_address '1.1.1.1'
ipv4_netmask_length 24
ipv4_proxy_arp true
ipv4_redirects true
shutdown true
switchport_mode 'disabled'
end

Or configure interface as Layer 2:

cisco_interface 'Ethernet1/2' do
action :create
access_vlan 20
shutdown false
switchport_mode 'access'
switchport_vtp true
end

In summary, please remember the following important facts about Chef:
+ Use “pull” model (nodes are dynamically updated with the configurations that are present in the server)
+ Use TCP port 10002 (default command port) for configuration push jobs
+ Use Ruby for device configuration
+ Files needed for operation: Recipe, Cookbook…
+ Chef server works only in Linux/Unix but Chef client and Workstation can work in Windows as well.

We also made a comparison list of Ansible, Puppet and Chef automation tool here: