Lowering Chef development iterations

Hi guys,

I’m new to chef and on my new job

  1. I have to copy a recipe
  2. Upload it to a chef server
  3. Run it on the client. Sometimes it seems to get stuck and I have a nuke the whole EC2 instance

With can take like 30 minutes every time I try something out. Which I want to do a lot of since I’m new to this.

I did notice https://www.safaribooksonline.com/blog/2015/06/04/super-charged-chef-cookbook-development/ but that looks massively complicated way of doing it. Am I missing a trick?

The part you are probably missing is Test Kitchen. It replaces all three steps with kitchen converge, along with a framework for writing tests so you aren’t inspecting the results manually.

1 Like

Yes, you can use chef-solo, vagrant and test kitchen to do test driven
infrastructure.
So you’ll test local, then deploy of chef master when working

1 Like

Thanks, I don't necessarily want to setup some testing framework. I just want to kick the tires and such to better understand the syntax that I wish was straight up shell :wink:

Like, how do I validate a recipe and such in order to check it doesn't have syntax errors and such?

Like, how do I validate a recipe and such in order to check it doesn't have syntax errors and such?

You can use rubocop and foodcritic to identify most issues. Chefspec (an extension of rspec) will quickly do a converge to catch any remaining issues.

Beyond that, you will probably want to use test-kitchen for TDD. It's really very quick and simple -- I git clone and kitchen verify all the time on Github repos for cookbooks I haven't used before; the longest part is waiting for the converge to pull down binaries or install packages, and test-kitchen can cache much of that too.

1 Like

Another thing I don’t quite understand about the kitchen based iterations. Once you have a machine running, do you destroy & converge to test a new change? Because even then it seems to take ~5mins.

Or do you leave it running, and run converge?

You generally re-converge/verify on a single machine. If you make major changes in your code sometimes you need to destroy and recreate the VM, but as you said it’s slower to do that. CI always tests from a fresh VM (hopefully) so even if you miss something, CI will catch it.

Trouble I have is the newly spawned machine triggers alerts, false negatives? So I am looking for a way to suspend the machine when I am not {converge,verify}ing.

Wondering nobody mentioned the use of kitchen-docker or the vagrant-docker-provider to massively speed up feedback cycles during development and testing.

Here is an intro I once wrote for TDD with Chef and Vagrant. Better start here:

It uses an environment with lots of stuff preconfigured to make the feedback cycle faster, e.g. using vagrant-docker provider for testing with “VM-like” docker containers and using vagrant-cachier for caching downloaded files:

HTH,
Torben

I tried the Docker driver but it doesn’t seem to support systemd very well. :confused:

So I am back onto Vagrant.

kitchen-docker driver or the vagrant-docker provider?

I’m usually staying with the vagrant driver in test-kitchen, but use the vagrant-docker provider in vagrant. That lets me reuse other vagrant plugins such as vagrant-cachier etc…

Not sure though what exactly you mean with systemd support…

This is my complaint with the docker driver. Admittedly not tried vagrant-docker Systemd & kitchen-docker status