This chef cookbook provides dead simple way to test and verify node's setup after chef run using cucumber and aruba. Unlike similar tools it's designed to be fully understood and ready to use in less then 5 minutes by the average developer.
It could be used as a tool to support BDD style in development of your infrastructure and as a regression testing tool.
Cookbook depends on Opscode's chef_handler cookbook. (Run knife cookbook site install chef_handler
to install it)
There are no additional limitations on environment. You can use it with any kind of chef (hosted/private/solo).
node["simple_cuke"]["suite_path"]
- Location for the test suite on the target node (/var/chef/handlers/suite
by default)node["simple_cuke"]["reporter"]
- Reporter which would be used to notify you results of tests.node["simple_cuke"]["suite_cookbook"]
- Cookbook for the test suite diectory structure (usessimple_cuke
by default)
- Install this cookbook to your chef repo. (
git clone git://github.com/iafonov/simple_cuke.git cookbooks/simple_cuke
) - Add
recipe[simple_cuke]
torun_list
- Start writing cucumber features and place them in
files/default/features
folders of cookbooks - Run
chef-client
and enjoy
After each chef-client
run a set of cucumber features is executed on a target node. As simple as it is. No black magic involved*.
Add role name as tag to the scenario or feature and it would be run only on nodes that have this role. Features/scenarios without tags would be run always.
The cookbook will automatically install and link aruba gem for you. Aruba is a set of handy cucumber steps that are intended to test command line applications and test manipulation with file system - this is exactly what is needed during verification of infrastructure setup. I recommend you to quickly go through provided steps definitions to prevent reintroducing already available steps. You can see the complete definitions list here.
There are no restrictions - you can use your own defined steps. Put the step definitions into features/step_definitions/[younameit]_steps.rb
file and they would be loaded automatically.
Simple example - check that Apache is running:
@appserver
Feature: Application server
Scenario: Apache configuration check
When I successfully run `ps aux`
Then the output should contain "apache"
Slightly more advanced example: check services are running, bind to their ports and aren't blocked by firewall:
@base
Feature: Services
Scenario Outline: Service should be running and bind to port
When I run `lsof -i :<port>`
Then the output should match /<service>.*<user>/
Examples:
| service | user | port |
| master | root | 25 |
| apache2 | www-data | 80 |
| dovecot | root | 110 |
| mysqld | mysql | 3306 |
Scenario Outline: Service should not be blocked by firewall
When I run `ufw status`
Then the output should match /<service>.*<action>/
Examples:
| service | action |
| OpenSSH | ALLOW |
| Apache | ALLOW |
| Postfix | ALLOW |
By default reporting is done to console but you can override this behavior and add custom reporter to files/default/reporters
folder. Reporter is a plain ruby class with the following skeleton:
class CustomReporter
def success(report)
end
def fail(report)
end
end
You can set reporter via node["simple_cuke"]["reporter"]
attribute. (If your class has name CustomReporter
you should set this attribute value to custom
)
For example you can send an email if test suite failed, write it to file or notify monitoring service.
The idea behind implementation is to be as simple and straightforward as possible. The workflow consists of the following three steps:
- Default recipe synchronizes the
files/default/suite
folders of cookbooks with remote node via callingremote_directory
LWRP. - Chef handler is registered.
- When handler is executed it installs the bundle (it consists of cucumber & aruba) and runs cucumber features.
© 2012 Igor Afonov