Here is an example shared configuration for knife, the command and control utility which ships with Opscode Chef. You can drop this off in your
chef-repo/.chef/ directory, and multiple developers can use the same knife configuration to interact with more than one Chef server, or the Opscode platform.
By using Bash functions and environment variables we can change the chef server, which knife is configured to use, on the fly.
NOTE: knife will probably ignore your
~/.chef/knife.rb once you begin using a shared knife configuration.
So that we can interact with
api.opscode.com, and an internal Open Source Chef server, you will need to name your keys according to your Chef server username, Opscode username, and Opscode platform organization name. Assuming you already have a
~/.chef directory, we will organize it like so.
- Re-name your Open Source chef-server private key according to your username on the chef-server system. For example, move your chef-server private key to
- Re-name your Opscode API key according to your Opscode platform username, for example I would move my Opscode key to
~/.chef/atomic-penguin.pemto correspond to my own username.
- Re-name your Organization validation key so that it corresponds to your organization’s name on the Opscode platform. For example, move your Opscode organization validation key to ~/.chef/companyname-validator.pem.
Environment in ~/.bashrc
Somewhere near the end of my
~/.bashrc, I am going to set 4 environment variables which will later be referenced in my shared knife configuration. I am also going to use a couple of Bash functions to switch context between multiple servers.
The variables are as follows.
OPSCODE_USER– Set to your primary username. This should be either your internal chef-server username or Opscode platform username.
ORGNAME– Should be set to “chef” for an internal chef-server. Set this as your Opscode platform orgname, if using that as your primary Chef server.
COOKBOOK_COPYRIGHT– Set to your full name.
COOKBOOK_EMAIL– Set to your e-mail address.
I have two knife related Bash functions in my
~/.bashrc file. I use a function called “ginsu” to interact with the Opscode API. Then I use the “knife-reset” function to restore default behavior to interact with our internal Chef server. This is just an example, you could use the ginsu function as a template. This way you could have an “opscode-knife” function, or maybe “prod-knife”, “dev-knife”, or “preprod-knife” to correspond to different servers or environments.
knife-reset function simply sets my
OPSCODE_USER variable equal to my internal Open Source chef-server username, and
ORGNAME equal to “chef”. The
knife-reset function then exports the variables so my knife configuration gets reset back to my primary Chef server.
ginsu function sets the
OPSCODE_USER variable equal to my Opscode platform username, and
ORGNAME equal to my Opscode organization name. The
ginsu function then exports the variables and passes any parameters to the knife command. This way I can do a
ginsu cookbook site share yumrepo "Package Management" to upload my yumrepo cookbook to the Opscode Community Cookbook site.
This is the actual knife configuration file, which we can drop off in the
chef-repo/.chef directory. I will explain the important parts, so you can modify this to fit your own needs easily. Note, once you drop this off in your
~/.chef/knife.rb will no longer work.
Set a local Ruby variable
user equal to the
OPSCODE_USER or the environment variable
Switching back and forth between different keys and user names occurs by changing, and exporting, the
ORGNAME Bash environment variables.
1 2 3
I used an if/then/else block in my shared knife.rb to switch the URL of my Chef server based on the
ORGNAME. You could use a
CHEF_SERVER environment variable in your
~/.bashrc if that would work better for you. Obviously you’ll want to change the hardcoded
corporate string to match your Opscode platform orgname, and also edit the
chef_server_url to point another Chef server.
1 2 3 4 5
If you commit all your Community Cookbooks under corporate copyright rather than individual developer names, then you might want to hardcode the company name and a generic development team e-mail address. This way, your developers don’t have to set
COOKBOOK_EMAIL. The command
knife cookbook create <cookbook name> will fill in the company name as the cookbook maintainer, and copyright owner in that case.
1 2 3
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
This was partly adapted from Stephen Nelson-Smith’s (@LordCope) book Test-Driven Infrastructure with Chef (http://shop.oreilly.com/product/0636920020042.do).