Life of a system admin before Chef…

Let’s take a step back at what life was like before Chef. So in an organization, suppose you are the system administrator who is responsible for the uptime of the servers within your network. You are the only person managing all the machines and looking after their maintenance. If a problem occurs in one machine, then you will automatically receive notifications and you can easily jump into the problem and fix it. But it starts getting difficult if more than one machine fails at the same time and being a single person you are not able to fix all the systems as quickly as possible. The problem is that your environments are not in sync and only if all this could be automated it would become easier. Well there is where chef comes to rescue.

Chef to the rescue

Basically Chef is a company and the name of the pull based configuration management tool which is written entirely using Ruby and Erlang. It was founded by Adam Jacob in the year 2009 and was originally named as ‘Marionette’, which was later renamed to ‘Chef’. On April 02' 2019, the company announced that all their products are now open source under the Apache 2.0 license. Overtime it became so popular that it is used by Facebook, AWS OpsWorks, HP public cloud, etc. Configuration management turns your code into infrastructure so that it would become repeatable, testable and versionable. That’s exactly what chef does. The way you actually write down scripts in chef is a way so that you can code your environment. Hence you don’t have to be managing your environment on a hardware basis but actually use scripts called recipes that will automate things for you. It will make sure that every system is set up in the exact way as defined in the code, so you won’t face system failures.

How does Chef work?

Ultimately Chef is an automation tool that converts infrastructure to code. It basically means that you take the policies that you as an organization have created and convert that into a scripted language which will further help in automating the entire process. This enables chef to be able to manage multiple systems very easily no matter how broad and deep our systems become. The code is then tested continuously and deployed by chef so that you are able to guarantee that your system states are always maintained.

Components of Chef

Workstations are personal computers or virtual servers where all configuration code is created, tested or changed. This is basically the place where the administrator writes all the code, referred to as recipes. These recipes are written in Ruby language and are updated to the chef-server. As the number of nodes in your workspace increases, you can write new recipes and update those in server as well. If a specific collection of recipes is to be maintained, then a cookbook is created. Workstation communicates with the chef server using knife. Knife is a command line tool that uploads the cookbook to the server.

The chef server is middle man between workstation and the nodes. All cookbooks are stored here and the nodes check for updates on the server. These servers maybe hosted locally or remotely.

Nodes are the systems that require the configuration. Ohai fetches the current state of the node it is located in. These nodes communicate with the chef server using chef client. Each node can have a different configuration required but a chef client is installed on every node. It is a tool that runs on every chef node to pull code from chef server.

Chef client will:

  • Gather current system configuration.
  • Download the desired system configuration from the chef server.
  • Configure the node such that it adhere to the policy.

Chef Architecture

When a recipe is written inside a cookbook on workstation, it is uploaded to the chef server using knife. These updates are again pulled by the desired nodes using knife. But in order to connect nodes to the chef server, bootstrapping is done. It is the process of attaching the server to the node. After bootstrap, the cookbook is added into the run list of nodes. After specific time intervals as configured by the administrator, the ohai will gather current system state and check for updates on server with the help of chef-client. If any updates in recipes are performed and uploaded to the server, the node will pull the code and configure itself as per the requirements.

Features of Chef

Following are the most prominent features of Chef −

  • Chef uses popular Ruby language to write recipes.
  • Chef does not make assumptions on the current status of a node. It uses its mechanisms to get the current status of machine.
  • Chef is ideal for deploying and managing the cloud server, storage, and software.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Archita Joshi

Archita Joshi

Programming enthusiast | Curious learner