Chef is a configuration management system written partly in Ruby and Erlang.
Before we begin our exciting journey towards becoming Chef masters, I think it would be prudent on our part to understand the underlying ecosystem.
The Chef ecosystem is primarily comprised of the following components:
WebUI: This is a Rails application that is used to view information about the Chef server over the Web.
ErChef: Prior to version 11.x, the Chef server API core (the code responsible for catering to requests by Knife or chef-client) was written in Ruby. However, since 11.x, this code has been rewritten in Erlang.
Bookshelf: This is used to store cookbooks content such as files, templates, and so on, that have been uploaded to chef-server as part of a cookbook version.
chef-solr: This is a wrapper around Apache Solr and is used to handle the REST API for indexing and search.
Rabbit MQ: This is used as a message queue for the Chef server. All items that are to be added to a search index repository are first added to a queue.
chef-expander: This is a piece of code that pulls messages from the RabbitMQ queue, processes them into a desired format, and finally posts them to Solr for indexing.
PostgreSQL: This is another major change since version 11.x. Earlier, CouchDB used to be the data storage; however, since version 11.x, PostgreSQL has become the data storage solution used by Chef.
chef-client: This is a Ruby application that runs on every machine that needs to be provisioned. It handles the task of authenticating with chef-server, registering nodes, synchronizing cookbooks, compiling resource collections, handling exceptions and notifications, and so on.
Knife: This is a Ruby application that provides an interface between a local chef repository and the Chef server.
The typical architecture of the Chef ecosystem can be understood by looking at the following figure:
Other than these components, we've chef-shell (shef), Ohai, and chef-solo that form an integral part of the chef ecosystem. We also have chef-zero, which is being adopted by people to quickly test their code or deploy chef code locally. It's a small, fast, and in-memory implementation of the Chef server and it helps developers to write a clean code without all the hooks that were earlier placed into the code to ensure that chef-solo can execute the code.
With the understanding of the Chef ecosystem, we will be covering the following topics in this chapter:
Different modes of running Chef
Terminology used in the world of Chef
The anatomy of a Chef run
Using the Chef Solo provisioner
Setting up a work environment