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 Chef 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. Chef 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. In Chef, a resource is defined in a recipe, which then defines the actions to be performed on the system. Chef 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 Chef will not do anything.
Chef does as much work as possible on the node; 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 of 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 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 Chef 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. With Chef, for each node a list of recipes is applied, which in turn specifies resources. 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. Chef 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, Chef will always execute resources in the same exact order.
Opscode began as a consulting company named HJK Solutions, which built fully automated infrastructure for startups. Everything from installing operating systems to full application development. Over the course of building a dozen or so different startups on the same basic infrastructure timeline (over a one year period), we realized that getting to a place where everyone could have a fully automated infrastructure, regardless of the expertise of their system administrators, was possible. Only a few things stood in the way:
We solve these problems by:
The goal is to remove people from the process of building automated infrastructure, as much and as often as possible. Chef is the first part of a framework that will allow all of us to do that.
Join the Chef community, participate in the discussion going on right now on IRC, sign up for the Chef mailing Lists, and read the instructions on how to contribute to an Opscode open source project.
Here are some contributions from the Chef community:
Workflow: Berkshelf | Librarian | Spiceweasel
Development tools: test-kitchen | Food Critic | cucumber-chef | chef-workflow | chefspec | yard-chef | Cookbooks
Discussion: Guidelines | lists.opscode.com | Food Fight Show — Chat channels: chef | chef-hacking | openstack-chef
Plugins: Chef | Knife | Ohai | Report handlers | Ridley
Documentation Contribute to this documentation | Style Guide
It helps, but its not required. You can learn Just Enough Ruby for Chef.
Yes, absolutely. Chef 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.
Lots of companies, ranging from small startups to the largest companies on the planet.
The short version is that we had three broad requirements for the license under which we would release open source software:
For more detail, read the blog post about why we love open source.
There are some 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:
As Chef grows, the services we expose will likely be integrated with Puppet as well. There is more than one way to do it.
Cfengine and Chef aren’t very similar at all, outside of both applications embracing the concept of Single Copy Nirvana.
For history of Chef, where it came from and how it evolved, watch these two (short) videos:
For more information about Opscode, cookbooks for Chef, and the Chef community:
