Opscode Chef is a bit complex when compared to other configuration management tools like Puppet and Ansible. With complexity, it is heard to remember what component do what. This post will help you learning different Chef terms as well as the basic architecture of Chef. In our next post we will show you what different terms we use in Puppet, Ansible, and Chef. We will approach this in a different fashion ie just not terms but where they fit in Chef setup. We will go with a top-down approach in describing each component related coding of cookbooks and related actual component os Chef architecture.

Layers of chef:

First layer: Organisations

Second layer: Environments

Third layer: Roles

Fourth layer: Chef-server

Fifth layer: Nodes

Sixth layer: Chef-client

Seventh layer: Resources

Eight layer: Attribute and action

Organisations in Chef

Before understanding what is an organisation we should know how many types of chef servers are there prior to 2014 where everything is merged to one single offering called Open source Chef.

Type of Chef server

  • Open source chef: The free Chef server
  • Enterprise Chef: Commercial offering of Chef server

Where Chef server is hosted?

  • Hosted chef: Chef server offering from Opscode where they host Chef server, clients uses it to manage their nodes
  • On premises Chef: Do not want to use hosted Chef server then implement it on your premises which can be either enterprise Chef or Open source chef

So much complex right? Thats where Chef people too thought and in 2014 they removed all these confusions and all these types. Now all these type of Chef offerings are gone and you are presented with just one offering called Open source Chef and it is free for up to 25 nodes to manage.

Coming back to Organisations..

Independent tenants/companies using enterprise chef, Share nothing with other organisations, may represent different companies, BU and departments.

Under each organisation we may have one or more environments. The organisations are more useful when you offer Chef server as SaaS(Software As A Service). For example where I work we offer Chef as a SaaS and we use organisations extensively. If you install Chef server locally in your location for your company, then Organisations will not make much sense.

Environments in Chef

Reflects your patterns and workflows for your dev, test, stage and prod. These environments is know for a long time and many organisations follows this and this is not specific to Chef. The _default is def env in Chef. We test our chef code in dev/test/stage before moving to production.

Definition of your environment policy may include below properties.

  • May include data attributes for your environment configuration
  • Location of your software repository will differ with different environment.
  • The environments can be controlled using either tagging of chef cookbooks in GIT repo or creating seperate folder for each environment.

What are roles, policies, and run-list in Chef?

Roles: A way to classify types of servers. Allows you define a policy. Suppose if you want to make a server as web server for which we require a web server software, some hardening  etc. Some example roles are database role for creating server with database, web server role for making a server web facing one etc.

Policy is determined by the configurations included in each node’s run-list. A policy states what state your server should be.

Run list: A list of chef configuration files to be applied on nodes.

Chef server components

  • Web server and its interface can be implemented on Apache/Nginx web servers etc.
  • Erchef(Core Chef server software)
  • BookShelf(Used to store cookbooks content like files, templates etc)
  • Chef Solr(Search index)
  • Database(PostgreSQL)
  • Cookbooks

We will explain more about Chef server in our next post.

Nodes of Chef

On which chef client runs and configure them. All your servers can be a chef-node and even your chef-server can act as chef-node if you want to manage your chef server by Chef it self.

Note: A node is part of only one organisation, one environment and one more zero roles.

Chef-client

Gathers node system configuration, download policies from chef-server and implement those policies on chef-client/node.

Resource in Chef

A piece of system and its desired state and it can be file, service, package, user etc.

Syntax:

resource ‘Name’ do
Attribute :actions
Done

An attribute is a property of resource.

Actions are what we do to an attribute.

Example resources are

package, file, link, directory, group, execute,  mount, remote_file, template, user, service, bash, chef_gem, gem_package, cron, deploy_revision,  etc.

Other Chef terms worth to know.

Knife: Chef admin tool used for. All kinds of chef admin jobs are done through knife. These include pushing cookbooks to chef server, controlling chef server, adding nodes to chef server etc.

Chef-solo: chef-solo is a command that executes chef-client in a way that does not require the Chef server in order to converge cookbooks. This is similar to puppet apply command.

Chef-zero: Chef Zero is a simple, easy-install, in-memory Chef server that can be useful for Chef Client testing and chef-solo-like tasks that require a full Chef Server. It IS intended to be simple, Chef 11+ compliant, easy to run and fast to start. It is NOT intended to be secure, scalable, performant or persistent.

Cookbooks: A fundamental unit of configuration and distribution policy.

Recipes: A group of resources which describe their desired state. These are building blocks of chef which can do install and configure software, manages files, deploy applications and run other recipes.

Ohai: This is similar to puppet facter which gathers facts about chef node and give that to Chef server to tailor its cookbooks.

Supermarket: Public repo of cookbooks(supermarket.chef.io)

Chef Workstation: This is where all your Chef work is done like creating cookbooks, recipes, testing with kitchen etc.

ChefDK: It is a Chef development kit installed on Chef workstation for testing, creating and playing with cookbooks and recipes.

chef-repo: This is where you store your cookbooks, recipes etc.

Test-kitchen: This is part of ChefDK. Very useful tool to test run your cookbooks on any providers like OpenStack, docker, Vagrant/VirtualBox etc.

Berkshelf: Berkshelf is a dependency manager for Chef cookbooks. With it, you can easily depend on community cookbooks and have them safely included in your workflow. Barkfile which is created in cookbooks is actaualy used by this.

Chefspecs: This is testing framework used to write test cases for your chef code so that we can deploy good code.

inSpecs: Similar to Chefspecs, useful for testing.

Post Views: 8,694
The following two tabs change content below.
My Twitter profileMy Facebook profileMy Google+ profileMy YouTube channel

Surendra Anne

Mr Surendra Anne is from Vijayawada, Andhra Pradesh, India. He is a Linux/Open source supporter who believes in Hard work, A down to earth person, Likes to share knowledge with others, Loves dogs, Likes photography. He works as Devops Engineer with Taggle systems, an IOT automatic water metering company, Sydney . You can contact him at surendra (@) linuxnix dot com.