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)
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.
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.
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.