Posted on by & filed under infrastructure, IT.

The difficulty in surfing is a function of having to move while balancing on a board that is also moving on an unpredictable surface. By contrast, skateboarders and snowboarders move on surfaces that are fixed, or at least predictable. The surfer has neither guarantee and must deal with conditions as they arise. It is with this in mind that I have approached our Chef-oriented continuous integration environment at Safari Books Online. As infrastructure testing tools emerge and test-driven development practices are applied more comprehensively to systems engineering, the most practical way to leverage these useful testing strategies and technologies is to accept that you are moving on a moving platform and that you will get more out of it if you learn it and love it.

Change is constant and inevitable. You must have strategies to deal with changes, or you will find yourself beset by what seem like inexplicable and inescapable regression bugs on workstations that worked just fine yesterday. Originally, this blog post was going to be a very quick and direct step-by-step tutorial describing how to get up and running with a test-kitchen workstation with chef-zero and Berkshelf, but between the time I originally documented the process and started writing the blog post, gems and cookbooks changed, resulting in bugs for my specific configuration.

Through some searches of Opscode forums and Github issues, I was able to find where the bugs were and how to pin the cookbook revisions in the Berksfile and the versions in the Gemfile in order to get new nodes up and running–but it doesn’t make for a very pretty (or reliable) tutorial. And so it seems worthwhile to share my experiences and point out that by loading community cookbooks from remote repositories, and by using particular test suites, you will likely encounter bugs, some of which may already have known solutions. The platform is moving, and accepting the inevitability of regressions is a step towards peace of mind.

Sometimes, though, you will find yourself with an error that appears to be otherwise unreported. Recently, we encountered this sort of scenario a few times and each time, I cautiously troubleshot the errors and tried different gem or cookbook versions, seeing if I could resolve it through version mix-and-match. If not, I reported the bugs via Github issues, and time after time, the developers of these tools quickly respond and graciously patch reported bugs, allowing us to remove version pinning in our Berksfile or Gemfile within days. While the platform is itself moving on a fluid surface, it’s refreshing to know that we can respond to it and help shape our course by providing feedback to the developers of the tools, providing greater future stability for ourselves and others.

Once you get the hang of working with the tools in the Chef ecosystem, you’ll develop a greater awareness of what’s breaking and why, and if you build a continuous integration system through which to deploy changes, as we have been doing and continue to do, you will be able to keep your test-kitchen workstation running longer without interruption and will be to recover more quickly when it gets gnarly.

Tags: automation, berkshelf, chef, chef-zero, continuous integration, devops, git, gitlab, jenkins, PaaS, sysops, systems engineering, test-kitchen,

Comments are closed.