Chef

Table Of Contents

Why Chef?

The idea that you know best about what should happen in your organization goes hand-in-hand with the notion that you still need help keeping it all running. It is rare that a single individual knows everything about a very complex problem, let alone knows all of the steps that may be required to solve them. The same is true with tools. Chef provides help with infrastructure management. And Chef can help solve very complicated problems. Chef also has a large community of users who have a lot of experience solving a lot of very complex problems. That community can provide knowledge and support in areas that your organization may not have and (along with Chef) can help your organization solve any complex problem.

What are the core principles?

The key underlying principle of Chef is that you (the user) know best about what your environment is, what it should do, and how it should be maintained. The chef-client is designed to not make assumptions about any of those things. Only the individuals on the ground—that’s you and your team—understand the technical problems and what is required to solve them. Only your team can understand the human problems (skill levels, audit trails, and other internal issues) that are unique to your organization and whether any single technical solution is viable.

Idempotence

A recipe can run multiple times on the same system and the results will always be identical. A resource is defined in a recipe, which then defines the actions to be performed on the system. The chef-client ensures that actions are not performed if the resources have not changed and that any action that is performed is done the same way each time. If a recipe is re-run and nothing has changed, then the chef-client will not do anything.

Thick Clients, Thin Server

Chef does as much work as possible on the node and as little as possible on the server. A chef-client runs on each node and it only interacts with the Chef server when it needs to. The Chef server is designed to distribute data to each node easily, including all cookbooks, recipes, templates, files, and so on. The Chef server also retains a copy of the state of the node at the conclusion of every chef-client run. This approach ensures that the actual work needed to configure each node in your infrastructure is distributed across the organization, rather than centralized on smaller set of configuration management servers.

Order Matters

When the chef-client configures each node in the system, the order in which that configuration occurs is very important. For example, if Apache is not installed, then it cannot be configured and the daemon cannot be started. Configuration management tools have struggled with this problem for a long time. For each node a list of recipes is applied. Within a recipe, resources are applied in the order in which they are listed. At any point in a recipe other recipes may be included, which assures that all resources are applied. The chef-client will never apply the same recipe twice. Dependencies are only applied at the recipe level (and never the resource level). This means that dependencies can be tracked between high-level concepts like “I need to install Apache before I can start my Django application!” It also means that given the same set of cookbooks, the chef-client will always execute resources in the same exact order.

Why was Chef created?

Chef began as a consulting company named HJK Solutions, which built fully automated infrastructure for startups. Chef then changed its name to Opscode, which was a cool name for a while. But then interactions started going like this:

“So where do you work?”

“Opscode.”

“What does Opscode do?”

“Devops software, infrastructure automation, you know...”

“Oh, you mean like Chef?”

“Yes, just like Chef.”

Sometimes we felt like we were explaining “Why Opscode?” more than we wanted to. And then Opscode itself turned out to be a weak brand, easily confused and often misspelled:

_images/includes_chef_why_origins.png

So now we call ourselves what we should have called ourselves all along: Chef. Everything else is still the same. Our software removes people from the process of building automated infrastructure, as much and as often as possible. Chef is a system integrations framework built on top of a configuration management system. It’s powered by Ruby and by a simple DSL. Chef is open source, with an outstanding community, and a license that allows everyone to safely integrate Chef into their organization, and then extend it to match each organization’s unique complexity, requirements, and scale.

How can I help?

Join the community, participate in the discussion going on right now on IRC, sign up for the mailing Lists, and read the instructions on how to contribute to an Chef open source project. For more information about participating in the community, see

Do I really need to know Ruby?

It helps, but its not required. Many recipes are just structure and patterns that use Ruby as the definition language. Having actual Ruby coding skills? Helpful, but not required, especially to get started. You can learn Just Enough Ruby for Chef.

Can I trust Chef?

Yes, absolutely. The chef-client will not do anything to your system that isn’t in a recipe. Because Chef is an open source project, you have full access to the source code and visibility into how it all works.

Who uses Chef?

Lots of companies, ranging from small startups to the largest companies on the planet.

Why the Apache license?

The short version of why Chef chose the Apache license for Chef is because we defined three broad requirements for a license under which we would release open source software:

  • We are an open source company and we make money from our open source software so we wanted a license that allowed us to build a business from the things we created
  • We wanted anyone (or any company) whose problems were solved by our software to be able to use it, in any environment they wanted, in whatever way they wanted
  • We wanted to build an open and equal community of users and did not want to reserve any rights for ourselves that we didn’t grant to the all of the other people (and companies) who helped build our software

For more details, read the blog post about why we love open source.

Comparisons

There are other applications out there that do things similar to Chef. We believe that we are different (and better) and that by choosing Chef you are choosing the best option.

Puppet

Puppet evolved from CFEngine and showed potential to be a new kind of configuration management. The original design of Chef was strongly influenced by our own experiences working with and contributing to the Puppet project. That said, Chef does not contain any code from Puppet, and is not a “fork” of the Puppet project.

Chef is different from Puppet in a number of important ways:

  • Chef uses Ruby as the configuration language, as opposed to a custom DSL
  • Chef is designed from the ground up to integrate with other tools, or to make that integration as simple as possible. Chef is not the canonical representation of your infrastructure. It is a service that exposes data about the state of your infrastructure
  • The chef-client applies resources in the order they are specified in recipes. There is no dependency management. This means multiple chef-client runs will always apply the resources under management in the same order, every time
  • Resources have actions, which can be signaled
  • Resources can appear more than once and they inherit the attributes of the earlier resource. In other words, you can tell Apache to start and stop in a recipe by specifying the resource twice, with the second one only changing the action attribute

CFEngine

CFEngine and Chef aren’t very similar at all, outside of both applications embracing the concept of Single Copy Nirvana.