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.
The key underlying principle of Chef is that you (the user) knows 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.
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 change, then the chef-client will not do anything.
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 server when it needs to. The server is designed to distribute of data to each node easily, including all cookbooks, recipes, templates, files, and so on. The 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.
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.
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?”
“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:
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.
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
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.
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.
Lots of companies, ranging from small startups to the largest companies on the planet.
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:
For more detail, read the blog post about why we love open source.
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 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 share any code from Puppet, and is not a “fork” of the Puppet project.
Chef is different from Puppet in a number of important ways:
Cfengine and Chef aren’t very similar at all, outside of both applications embracing the concept of Single Copy Nirvana.
For a history of Chef, where it came from and how it evolved, watch these two (short) videos:
For more information about Chef, cookbooks, and the community: