DevOps Zone is brought to you in partnership with:

Matthias Marschall is a software engineer "Made in Germany". His four children make sure that he feels comfortable in lively environments, and stays in control of chaotic situations. A lean and agile engineering lead, he's passionate about continuous delivery, infrastructure automation, and all things DevOps. Matthias is a DZone MVB and is not an employee of DZone and has posted 38 posts at DZone. You can read more from them at their website. View Full User Profile

Automated Configuration Management With Opscode Chef: The Basic Moving Parts

09.02.2011
| 6890 views |
  • submit to reddit

The Moving Parts

Managing your infrastructure with Opscode Chef involves a few moving parts you need to be aware of. As I found it quite hard to differentiate, I want to share the basics with you:

  • Chef server There you manage all your nodes and roles. The chef server distributes cookbooks to the nodes.
  • Chef clients (Nodes) Every client will be registered as a node at the chef server. It will receive cookbooks to run from the chef server.
  • Your workstation You will write cookbooks and role definitions on your local box. From there you will upload your cookbooks to the chef server, create roles at the server or manage the chef server using its command line tool knife.


The Opscode Chef Server

The Chef server is your central place where you find all the machines (nodes) to be managed by chef. In the chef server, you find a mapping of nodes to the roles they play. And, you upload all your cookbooks (definitions how to setup a server with a certain role) to the chef server, which distributes it to the nodes to run there.

You have two ways of getting a chef server: Either choose one of your machines to become the chef server and set it up accordingly. Or use the Opscode chef platform (in private alpha as of writing of this article) as your chef server. The advantage of the chef platform is that you have one moving part less to care about.

The Opscode Chef Clients

Every server you want to configure via chef needs to have the chef client software, be configured so it knows your chef server, and be registered at the chef server. The chef server will manage it as a node. You will then assign roles to the node. The roles define what will be installed on the node. E.g. a role called “rails_app” could define that you want to install “passenger_enterprise::apache2″ and “rails_enterprise” on every node with that role. Here’s an example role definition file:

name 'rails_app'
description 'The base role for systems that run Rails applications'
run_list "recipe[passenger_enterprise::apache2]", "recipe[rails_enterprise]"

Your Local Workstation

At your local workstation, you install and configure the knife command line tool to interact with the chef server. Additionally, you create all your cookbooks and role definitions on your local box and upload them to the chef server. To keep track of all your changes to your cookbooks (and to share them with your co-workers) it makes sense to store them in a version control system. It’s important to note that the chef server, not the chef clients, will pull it from there. You have to upload your changes from your local workstation to the chef server using the chef rake task rake upload_cookbooks. That is conceptually different e.g. from how capistrano deploys your application source code to the servers.

Mixing It All Together

After writing such a role file on your local workstation, you have to upload it to the chef server. There is a rake task for that. Just run rake roles within the directory where you manage your cookbooks (alternatively you could use knife to create the role, too). You can verify that the role is available on the chef server:

workstation $ knife role show rails_app
{
    "name": "rails_app",
    "default_attributes": {
    },
    "json_class": "Chef::Role",
    "run_list": [
      "recipe[passenger_enterprise::apache2]",
      "recipe[rails_enterprise]"
    ],
    "description": "The base role for systems that run Rails applications",
    "chef_type": "role",
    "override_attributes": {
    }
  }

If you already have a client called “app.example.com” registered as a node on the chef server, you can assign the “rails_app” role to it by running knife from your local workstation:

workstation $ knife node run_list add app.example.com "role[rails_app]"
{
  "run_list": [
    "role[rails_app]"
  ]
}

If you run the chef client app.example.com, the client will see that it has to apply the “rails_app” role and will retrieve and run all required cookbooks installing apache2, passenger, REE, rails, etc.

Have you ever used Opscode Chef? What are your experiences? Please let us know in the comments.

References
Published at DZone with permission of Matthias Marschall, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Nabeel Manara replied on Fri, 2012/01/27 - 11:36am

We’ve been very happy with Chef too. Notably, we use chef-solo, which we shell out to at deploy time using capistrano. This way we upgrade our code, data, and system config in concert.

I have to say that I’ve never seen a use case in typical webapp development that I felt demanded the client-server model.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.