As a step towards integrating your Chef cookbooks with Jenkins CI and your testing/release pipeline it is important to make sure that local changes pass unit and integration tests before being accepted and committed into version control. For example, when running test kitchen it is important to fully simulate what data bags and encrypted data bags are doing on a local box for many tests to pass correctly. So, today I would like to focus on a stumbling block towards Jenkins and integration testing that I ran in to recently. There are a few lessons that I learned along the way that I would like to share to help clarify things a little bit because there wasn’t much good info out there on how to do this.
First, I need to give credit where it is due. This post was a great resource in my journey to find a solution to my test kitchen data bag issue.
The largest roadblock I found along the way was that the version of test kitchen I was using was being shipped with chef-solo as the primary driver. There has been a lot of discussion around this topic lately and (from what I understand) has pretty much become the general consensus within the Chef community that chef-solo should be replaced by chef-zero. There are a number of advantages to using chef-zero instead of chef-solo, including a lesson I learned the hard way, which is that chef-zero has the ability to act as a stand alone Chef server – unlocking the ability to store data bags and encrypted data bags without having to do any sort of wacky hacking to get Chef to compile and converge correctly.
There was a good post written recently that expounds more on the benefits of using chef-zero instead of chef-solo. It is here, and is definitely worth the read if you are interested in learning more about the benefits of chef-zero.
So with that knowledge in mind, here is what a newly updated sample .kitchen.yml file might look like:
--- driver: name: vagrant provisioner: name: chef_zero platforms: - name: ubuntu-13.10-i386 - name: centos-6.4-i386 suites: - name: default data_bags_path: "test/integration/data_bags" run_list: - recipe[recipe-to-test] attributes:
It’s a pretty straight forward config. The biggest change that you will notice in this config is that instead of using chef-solo as the provisioner it has been changed to chef-zero – I now know that it makes all the difference in the world. The next big change to observe is the data_bags_path in the suites section. This bit of configuration basically tells the Chef provisioner to go look at the specified file path when chef-zero spins up and use that to store data bag, encrypted data bag or other information that potentially would live on the Chef server that client’s would use.
So in the test/integration/data_bags directory I have a directory and json file inside that directory for the specific data I am interested in, called sensu/ssl.json. This file essentially contains the same information that is stored on the Chef server about the ssl certificates used for live hosts in the production environment, just mirrored into a sandbox/integration testing environment.
If you’re interested, here is a sample of what the ssl.json file might look like:
{
"id": "ssl",
"server": {
"key": "-----BEGIN RSA PRIVATE KEY-----gM
"cert": "-----BEGIN CERTIFICATE-----gM
"cacert": "-----BEGIN CERTIFICATE-----gM
},
"client": {
"key": "-----BEGIN RSA PRIVATE KEY-----gM
"cert": "-----BEGIN CERTIFICATE-----gM
}
}
Note that the “id” is “ssl”. As far as I know the file name must match up to the id when you are creating this json file.
Now you should be able to create and converge your test recipe with test kitchen:
kitchen create ubuntu kitchen converge ubuntu
If you have any difficulty, let me know. I tried to be thorough in this write up but could have accidentally skipped important information. The main keys or takeaways though should be 1) use chef-zero wherever possible and 2) make sure you have your data bag paths and files created correctly and referenced correctly in your .kitchen.yml file. Finally, if you are still having issues, make sure you have triple checked the spelling and json syntax of your paths and configs.
