In this post I want to discuss briefly an approach to setting up a shared Knife configuration file for teams using the same Chef Repository, while supporting customized configuration.
The repository has a shared
.chef/knife.rb which sets some local
paths where cookbooks and roles are located. In addition to this, I
wanted to test building the infrastructure using a Chef Server and my
own EC2 account.
At Opscode, we believe in leveraging internal DSLs. The
.chef/knife.rb (and Chef’s
solo.rb, etc) is no
exception. While you can have a fairly simple configuration like this:
1 2 3 4
You can also have something like this:
1 2 3 4 5 6 7 8 9 10
This is the
knife.rb included in the
The main part of interest here is the last three lines.
1 2 3
This says “if a file
knife.local.rb exists, then load its
Chef::Config class is what Chef uses for
configuration files, and the
#from_file method will load the
In this case, the content of my
1 2 3 4 5 6 7 8 9 10 11
Here I’m setting my Opscode Hosted Chef credentials and server. I also
cookbook_path to include the site-cookbooks directory (this
should probably go in the regular knife.rb). Finally, I set the knife
configuration options for my AWS EC2 account.
The configuration is parsed top-down, so the options here that overlap
knife.rb will be used instead.
In the Repository
In the repository, commit only the
.chef/knife.rb and not the
.chef/knife.local.rb. I recommend adding the local file to the
.gitignore or VCS equivalent.
1 2 3
There are many approaches to solving the issue of having shared Knife configuration for multiple people in a single repository. The real benefit here is that the configuration file is Ruby, which provides a lot of flexibility. Of course, when using someone else’s configuration examples, one should always read the code and understand it first :–).