Chef Cheat Sheet Tutorial

Are you finding difficulty in remembering all the commands that you need in order to work with Chef? Don’t worry, guys, this Chef cheat sheet will give you a quick reference to the basics that you must know to get started with Chef.We, at ACTE, are ready to support our learners in all possible ways, and that’s the reason we have created this handy reference, the Chef cheat sheet. This cheat sheet is designed for those who have already stepped forward into learning Chef but needs a more handy aid.

What is Chef?

This open-source tool, released by Opscode, is a config management technology developed primarily to automate infrastructure provisioning.

• Chef is used to deploy and manage both on-premises servers and those hosted in the cloud.
• It uses Ruby as its reference language.

Now, let’s move ahead to discuss the features of Chef.

• Chef makes no assumptions; it gets the current status of the machine via certain mechanisms.
• It is an excellent tool for integration with the cloud.
• As it uses Ruby, it is easy for anyone to get into Chef with basic development experience.

Chef Terminology :

Before proceeding toward its components and basic commands, let’s first understand the basic terms used in Chef.

• Node: A managed machine that executes the configuration for the node when the client runs
• Client: An authorized user in the Chef API
• Cookbook: A collection of recipes, resources, attributes, and definitions to configure a service or an application.
• Recipe: A list of resources to be added to a node. As it is written in Ruby, it gives us control over anything we would do in Ruby.

Chef Components :

Now, let’s check out the important components used in Chef.

• Knife: A system admin tool used to interact with the server to take cookbooks and custom config and load them into the server. Bootstrapping certain servers is also possible with this component.
  • Running knife- shows a list of commands that are supported.
• Chef client: It runs on managed servers, gathers information about itself, syncs the cookbooks, and compiles the collection of resources and converges it with the machine state.
• Web UI: A web-based interface that allows us to browse and edit cookbooks, nodes, and clients.
• Server/API: The heart of the system that exposes a REST API that is used by others and manages the knife, web interfaces, and nodes.

Chef Workstation :

• Configurations are developed and installed on the local machine.
  
  Chef Server
• It is the center of the Chef setup.
• Config files are uploaded here.
• Some are hosted, and some are built on-premises.
  
  Chef Nodes
• It is the end machine managed by the server.
• It contains the client that sets communication between the server and the node.
• Ohai is another component of Chef Node, which returns the current state of any node.

Files, Directories, and Templates :

It provides a file, remote file, and cookbook file to manage files and a resource to manage directories.

Directories :

• Create, remove, and manage directory permissions
• Owner and group will be kept default for the client, usually the root.
• Defaults can make cookbooks more concise although they shouldn’t be confusing.

Files :

• Allow us to manage permissions and ownership of the files on the node.
• To retrieve a file from the URL or cookbook, use remote_file or cookbook_file. They have a backup attribute that defines how many backfiles exist upon changing the content

• remote_file: It has the source parameter that contains the URL of the file to transfer.
  • It contains an optional checksum that uses SHA-256.
  • Actions are limited to create and create_if_missing.
• cookbook_file: It is the same as the remote file, but here files will be retrieved from the files/directory structure.

Templates :

• It supports text-based config files using ERB.
• Ruby code is wrapped in brackets. Things that are not parsed are not executed as Ruby code.
• Templates for complex configs can be created.
• Just as in a cook_book file resource, source and nodes are set. Add variables attribute that will assign an array. The array will be made available in variable @ nameservers.

Online learn.chef.io :

Chef helps you express your infrastructure policy – how your software is delivered and maintained on your servers – as code. When infrastructure is code, it becomes more maintainable, versionable, testable, and collaborative.

A great way to get started with Chef is to log in to a server, or node, and configure it directly.

What the following should provide us:

• describe what happens when Chef runs.
• write Chef code that defines a basic policy.
• apply that policy to a server.

In the next step, you’ll install the Chef tools and a text editor on your own machine, or use a virtual machine in the cloud that we provide that already has everything set up. You’ll use that machine in the lessons that follow.

The normal Chef workflow involves managing servers remotely from your workstation. But in this tutorial, you’ll log in to a server and manage it directly to get a feel for how Chef works.

The easiest way to get started is to use a free trial Ubuntu 14.04 virtual machine that we provide. The virtual machine runs in your browser and has the set of Chef tools, called the Chef DK, and several popular text editors pre-installed. You can also set up your own server to use with this tutorial.

Convergence and Desired State :

With the command sudo chef-client –local-mode hello.rb, when we run –local-mode we did it because the default mode is to talk to a chef server. Once we have a Chef server to work with, we can not use this mode.

What happens if you modify the content of the file that we create directly, what happens when Chef runs again?

Chef will then attempt to repair the file changes.

If we change the ownership for a file, Chef will only take action when it needs to. It will only take action if something is “out of policy”.

How do you keep track of changes to the recipes?

Cookbooks allow a way to package up the recipes and give it a version number and track changes.

A fundamental unit of configuration and policy distribution

When creating the cookbook, is describes a config for a particular scenario.

What to use cookbooks for:

• Specifiy resources to use and in which order they are applied
• Attribute values
• File distributions
• Templates
• Extensions to Chef (lib, definitions and custom resources)
• Version Control

Cookbook components:

• README
• metadata
• recipes
• testing directories (spec + test)

Chef-Client :

Agent that runs locally on the node that is registered with the chef server.

This will register and authenticate when it is first run. It will sync the cookbooks and take appropriate action to align with what the cookbook says.

Convergence :

Occurs when chef-client configures the system/node based off the information collected from chef-server.

When we run the convergence, the node will be up to date.

Configuration Drift :

Occurs when the node state does not reflect the updated state of polices/configurations on the chef server.

Recipes are primarily made up of resources and the CD and it configures in liason with the element.

Resources :

A statement of configuration policay within a recipe.

Describes the desired state of an element in the infrastructure and steps needed to configure.

Provider :

Defines the steps that are needed to bring the piece of the system from its current state to the desired state.

This works with resources and brings the piece of the system from the current state to the desired state.

Attributes :

Specific details about the node, used by chef-client to understand current state of the node, the state of the node on the previous chef-client run, and the state of the node at the end of the client run.

Data-bags :

A global variables stored as JSON data and is accessible from the Chef server.

We can use these when defining local users on our system.

Workstation :

A computer configured with Knife and used to sync with chef-repo and interact with chef server.

The workstation is what we are going to work on our recipes on. We can configure out Chef server for our node state and server state from the workstation.

Chef Server :

Chef server is the hub for all configuration data, stores cookbooks, and the policies applied to the node.

The node communicates with the Chef Server and our work to build out policies is done on the workstation and sent to the server and the Node converges with the Chef Client.

Knife :

Command line tool which provides an interface between the local chef-repo and chef-server.

Client.rb :

Config file for chef_client located at /etc/chef/client.rb on each node.

Ohai :

Tool used to detect attributes on a node and then provide attributes to chef-client at the start of every chef-client run.

Node Object :

Consists of run-list and node attributes that describe states of the node.

Chef-Repo :

Located on the workstation and installed with the starter kit, should be synchronised with a version control system and stores Cookbooks, roles, data bags, environments, and config files.

Organisation :

Used in chef enterprise server to restrict access to objects, nodes environments, roles, data-bags etc.

An organisation is used to make sure that your Chef infrastructure or organisation is separate from others.

Environments :

Used to organise environments (Prod/Staging/Dev/QA) generally used with cookbook versions

You can name things like which versions to use etc.

Idempotence :

Means a recipe can run multiple times on the same system and the results will always be identical.

Chef Enterprise :

• Allows the creation of organisations – Organisations separate the infrastructure, policies and cookbooks – Nodes are registered in organisations – Nothing shared between organisations – Enterprise chef server can contain many different organisations – OpenSource chef the local individual server acts as an organisation and does not allow creation of organisations. – Organisations can represent different companies, department, infrastructures, applications and so forth.
• For each organisation in order to start bootstrapping nodes you need to download the starter kit.
• Starter kit provides security credentials (validation.pem keys) to authenticate each node to the chef server.
• Chef enterprise scales by design to handle thousands of nodes and different organisations.

Role of the server :

• Stores system config information (policies for nodes)
• Authenticates workstations and nodes
• Delivers configurations to nodes
• Chef server holds the config and the node check-ins to receive instructions on its desired state
• The node downloads config instructions from the server and does all of the work

In the Chef Server website, we can see the policies of what’s required and see things like content to see what files are there and what it requires.

Again, the node communicates back with the chef server to figure out how it should become configured.

Ohai will populate attributes about information for the node.

What Is Chef – Chef Key Metrics :

• Chef supports multiple platforms like AIX, RHEL/CentOS, FreeBSD, OS X, Solaris, Microsoft Windows and Ubuntu. Additional client platforms include Arch Linux, Debian and Fedora.
• Chef can be integrated with cloud-based platforms such as Internap, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer, Microsoft Azure and Rackspace to automatically provision and configure new machines.
• Chef has an active, smart and fast growing community support.
• Because of Chef’s maturity and flexibility, it is being used by giants like Mozilla, Expedia, Facebook, HP Public Cloud, Prezi, Xero, Ancestry.com, Rackspace, Get Satisfaction, IGN, Marshall University, Socrata, University of Minnesota, Wharton School of the University of Pennsylvania, Bonobos, Splunk, Citi, DueDil, Disney, and Cheezburger.

“There are three dimensions of scale we generally look at for infrastructure — the number of servers, the volume of different configurations across those systems, and the number of people required to maintain those configurations.

• Chef provided an automation solution flexible enough to bend to our scale dynamics without requiring us to change our workflow.”
• Without a doubt Chef is one of the most famous Configuration Management tools and is closely competing with Puppet. But, before diving deep into “What is Chef”, it’s only fair that I first explain what is Configuration Management and why it is important.

Configuration Management :

Let us understand Configuration Management this way – suppose you have to deploy a software on top of hundreds of systems.

• This software can be an operating system or a code or it can be an update of an existing software.
• You can do this task manually, but what happens if you have to finish this task overnight because tomorrow might be a Big Billion Day sale in the company or some Mega Sale etc. in which heavy traffic is expected.
• Even if you were able to do this manually there is a high possibility of multiple errors on your big day.
• What if the software you updated on hundreds of systems is not working, then how will you revert back to the previous stable version, will you be able to do this task manually? AF-course not!
• To solve this problem, Configuration Management was introduced.
• By using Configuration Management tools like Chef, Puppet, etc. you can automate this task.
• All you have to do is to specify the configurations in one centralized server and accordingly all the nodes will be configured.
• It allows access to an accurate historical record of system state for project management and audit purposes.
• So basically, we need to specify the configurations once on the central server and replicate that on thousands of nodes.
• Configuration Management helps in performing the below tasks in a very structured and easy way:
• Figuring out which components to change when requirements change.
• Redoing an implementation because the requirements have changed since the last implementation.
• Reverting to a previous version of the component if you have replaced with a new but flawed version.
• Replacing the wrong component because you couldn’t accurately determine which component was supposed to be replaced.

There are broadly two ways to manage your configurations namely Push and Pull configurations :

• Pull Configuration:  In this type of Configuration Management, the nodes poll a centralized server periodically for updates. These nodes are dynamically configured so basically they are pulling configurations from the centralized server. Pull configuration is used by tools like Chef, Puppet etc.
• Push Configuration: In this type of Configuration Management, the centralized Server pushes the configurations to the nodes. Unlike Pull Configuration, there are certain commands that have to be executed in the centralized server in order to configure the nodes. Push Configuration is used by tools like Ansible.

Let us see what were the functions performed by Chef at Gannett:

• Gannett started building VPC (Virtual Private Cloud) for development environment that would mimic the production. None of the tools that they were already using were appropriate. But they found that Chef worked well with the cloud and both Linux and Windows environment. They used Chef to build a development environment that perfectly matched production environment.
• For an application to move into the VPC, it had to be provisioned and deployed with Chef.
• Security would be involved early on and would manage the mandatory controls for access to Chef and for maintaining system security standards.

Now is the time to understand what were the results of this process:

• Gannett’s deployment became quicker and more reliable. Application provisioning and deployment, which once took weeks, after using Chef it took minutes.
• All new applications were deployed on the cloud with Chef. These applications were deployed to all environments in the same way that they were deployed to production. Also, testing occurred in each environment, so that the deployments were reliable.
• All infrastructure was treated as code, which greatly increases visibility into any changes that occurred. Development, Operations, Security and Finance all were benefited from this.

Summary :

Your web server is shaping up! With a cookbook you’re now better organized. A cookbook adds structure to your work. You can now author your HTML code in its own file and use a template resource to reference it from your recipe.

You also saw the run-list. The run-list lets you specify which recipes to run, and the order in which to run them. This is handy once you have lots of cookbooks, and the order in which they run is important.

Keep in mind that the web server cookbook you wrote in this lesson likely won’t be the one you’d use in production. Only you know the specific needs for your infrastructure. You bring your requirements and Chef provides the tools that help you meet them.