Here is an example shared configuration for knife. 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.rb in your chef-repo directory.
So that we can interact with api.opscode.com, and an internal Open Source Chef server, you'll 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'll organize it like so.
- Re-name your Open Source chef-server key according to your username on that system.
- Re-name your Opscode API key according to your Opscode platform username, for example I would move my Opscode key to ~/.chef/atomic-penguin.pem to 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.
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.
The knife-reset function simply sets my OPSCODE_USER variable equal to my internal Chef server username, and ORGNAME equal to "chef". It then exports the variables so my knife configuration gets reset back to my primary Chef server.
My ginsu function sets my OPSCODE_USER variable equal to my Opscode platform username, and ORGNAME equal to my Opscode organization name. It 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 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-repo, your ~/.chef/knife.rb will no longer work.
Set a local Ruby variable "user" equal to the OPSCODE_USER or the Unix ENV variable USER.
user = ENV['OPSCODE_USER'] || ENV['USER']
Switching back and forth between different keys and user names occurs by changing, and exporting, the OPSCODE_USER and ORGNAME Bash environment variables.
client_key "#{ENV['HOME']}/.chef/#{user}.pem"
validation_client_name "#{ENV['ORGNAME']}-validator"
validation_key "#{ENV['HOME']}/.chef/#{ENV['ORGNAME']}-validator.pem"
I used an if/then/else block 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.
if ENV['ORGNAME'] == 'corporate'
chef_server_url "https://api.opscode.com/organizations/#{ENV['ORGNAME']}"
elsif ENV['ORGNAME'] == 'chef'
chef_server_url 'http://chef.example.com:4000'
end
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_COPYRIGHT or COOKBOOK_EMAIL. The command 'knife cookbook create ' will fill in the company name as the cookbook maintainer, and copyright owner in that case.
cookbook_license 'apachev2'
cookbook_copyright ENV['COOKBOOK_COPYRIGHT'] || 'Corporate, Inc.'
cookbook_email ENV['COOKBOOK_EMAIL'] || '[email protected]'
This was partly adapted from Stephen Nelson-Smith's (@LordCope) book Test-Driven Infrastructure with Chef (http://shop.oreilly.com/product/0636920020042.do).