Cucumber-chef begins with a very simple premise. If we are framing our infrastructure as code - if we’re writing cookbooks, recipes and other pieces of automation in a high level programming language, such as Ruby, then it makes sense to follow the current wisdom across the software development world to maximise the quality, maintainability and reusability of our code, providing maximum chance that we’ll deliver value with it. One area which has been shown to have a very positive effect is the proactive of ‘test-driven’ development. In this paradigm, the developer begins by writing a test that captures the intended behaviour of the code they are going to write. This test will start out by failing. The developer then writes code to make the test pass, and iterates thereafter. Cucumber-Chef provides a framework to make it easier to do test-driven development for infrastructure.
Throughout this documentation, a few terms will crop up regularly. It makes sense to define these up front, as they’re just terms we’ve been using since we started writing Cucumber-chef. They may even change, but in the meantime, so we’re all n the same page, here are some of the terms we use:
Cucumber-chef is tightly integrated with Chef - it uses your knife.rb for credentials, and any cucumber-chef-specific configuration goes in knife.rb under the cucumber-chef namespace.
On installation, the first thing you should do is run:
$ cucumber-chef displayconfig
This will look for your knife.rb, and extract the relevant sections, check them, and display them on the screen. If any entries are missing, it will alert you.The current recommendation is to keep your knife.rb inside your organisation’s chef repository, in .chef, and use environment variables to specify username, organisation name and cloud provider credentials. Cucumber-chef supports and encourages this approach. It will search for a directory called .chef in your current directory, and then carry on going up the directory tree until it finds one. In practice this means that if you stay within the chef-repo directory for the organisation on which you’re working, cucumber-chef will use the knife.rb; if your elsewhere in the filesystem rooted in your home directory, and have .chef in your home directory, cucumber-chef will use that. Otherwise you’ll need to either change into a directory where a .chef can be found, or copy, creatre or link accordingly. In most cases we anticipate that you’ll be inside the chef-repo of your organisation, and the documentation is written from this perspective.
In its current incarnation, cucumber-chef makes two important assumptions. Firstly, we assume you’re using the Opscode platform rather than your own Chef server. Secondly, we assume that you are comfortable with using Amazon’s EC2 service for providing the ‘bare metal’ on which we set up the test lab. Future releases may well allow you to use your own Chef server, and will definitely look at offering alternative cloud providers. In the meantime, we welcome patches and pull requests!
Set your environment variables:
$ export OPSCODE_USER=platform_user_name $ export ORGNAME=platform_organisation $ export AWS_ACCESS_KEY_ID=SEKRITKEY $ export AWS_SECRET_ACCESS_KEY=REELYSEKRITKEY