Using Chef for infrastructure automation – reading list

I have recently read (and re-read) several books on Chef in order that I can recommend books to clients who are starting with infrastructure automation (and to remind myself of the more obscure uses of knife, encrypted databags, and so on). In this post I comment on these books:

  • Chef Infrastructure Automation Cookbook by Matthias Marschall
  • Managing Windows Servers with Chef by John Ewart
  • Test-Driven Infrastructure with Chef (2nd Edition) by Stephen Nelson-Smith
  • Automation Through Chef Opscode by Navin Sabharwal and Manak Wadhwa

Summary: read Chef Infrastructure Automation Cookbook for a good introduction to Chef on both Linux and Windows; read Managing Windows Servers with Chef if you manage many Windows machines; but most of all read Test-Driven Infrastructure with Chef because without a test-driven approach your infrastructure code will rapidly become tangled, unsupported, and obsolete.

Chef Infrastructure Automation Cookbook by Matthias Marschall

Published by PackPub:

Chef Infrastucture Automation Cookbook

This book is a good introduction to Chef. Chapters 1 and 2 and parts of chapter 3 form a solid overview of Chef and the supporting tools, with chapters 4 and 5 providing examples (‘recipes’) for how to do various things (note that these are not always full ‘Recipes’ in the Chef sense). In many senses, the good practices around Chef, especially the use of related tools such as Vagrant, Berkshelf, knife preflight, and so on, are as important as the core tools, so it is good to see these covered early on. In particular, the author explains how to make use of community cookbooks in terms of version control – getting this wrong can lead to cookbook sprawl and version drift.

Specific examples like installing nginx are clear and easy to follow. At one place I worked recently, we used nginx quite extensively for internal (build & test) systems, and the nginx config file lends itself well to configuration via Chef. Incidentally, this is a good example of how you might choose certain applications (say nginx) over others (say Apache + mod_proxy) based on how easy they are to configure using Chef. The discussion of using search to find nodes in elastic (‘cloud’) infrastructure is clear, although I would have liked a bit more discussion about node search as a fundamental part of building a cloud infrastructure, where we often do not know the machine name(s), only their roles or purposes.

The ‘See also’ links in each section, taking you to Github repos, videos of talks, slide decks, blog posts, etc., are very valuable for following up on material just learned. The first two or three chapters of the book are not really cookbook recipes in this sense, although actually these early chapters are a very useful introduction to Chef and the supporting tools (Vagrant, TestKitchen, ChefSpec, knife, etc.). Perhaps the book should be called simply ‘Chef Infrastructure Automation’. Other minor gripes: the section on idempotency is a bit short given how important idempotence is to Chef; Chef on Windows is not really touched on at all (although there is a separate PacktPub book for that: Managing Windows Servers with Chef); and the choice between Hosted / Private / open source Chef is not really explored. However, aside from these small points, the book is well-written and valuable.

Managing Windows Servers with Chef by John Ewart

Published by PacktPub:

Managing Windows Servers with Chef

This is a useful guide for Windows sysadmins, who can finally leave the world of error-prone point-and-click Windows administration behind, and use the power of Chef for automation. The book assumes that the reader is a Windows sysadmin, so covers things like: installing MSIs (using the windows_package resource); configuring printers; working with zip files; and (because we’re talking about Windows!) rebooting machines after installing software. There are useful examples of non-standard tasks too, such as installing Umbraco CMS for an intranet.

I used to be part of a team at a major online retailer in the UK that managed over 600 Windows servers using Chef, so I am fairly familiar with the ‘interesting’ (painful) aspects of automating Windows. With PowerShell v3 and WinRM, Windows automation became much less crazy, and the book shows how to ‘shell out’ to PowerShell for the few things that the Chef Cookbooks and Resources do not cover. A nice touch in the book is that it covers cases where recipes need to work cross-platform on both Windows and Linux. The book also covers the use of ChefSpec for testing recipes, which is A Good Thing: cookbooks need testing before being deployed (see below).

Aside from the lack of an overview of how Chef really works, and no real mention of how Chef can (and should) be used by both sysadmins and development teams, this book is a valuable introduction to Chef for anyone managing Windows servers.

Other books on Chef

Automation through Chef Opscode by Navin Sabharwal and Manak Wadhwa

Published by Apress:

Automation through Chef Opscode

I was puzzled by the title of this book from Apress: the product is called ‘Chef’, not ‘Opscode’; ‘Opscode’ was the previous name of the company that produces Chef. The book has comprehensive coverage of installing and configuring Chef (nodes, workstation, server), including a useful section on high availability for the Chef Server. The core principles of Chef are covered briefly (idempotence, execution order, etc.) although I’d have preferred to see more on these. The section on the knife tool (Chapter 6) is well done, and covers all the major commands. The chapter on using cookbooks demonstrates the focus of the book: sysadmins that need to install standard, relatively simple open-source applications such as WordPress, nginx, and MySQL. Using Chef in combination with Vagrant for provisioning is covered in chapter 12, including details of installing Vagrant on Windows (although we’d now use Chocolatey for that: cinst vagrant).

However, although the details of the Chef tools and commands are covered pretty well, an understanding of the purpose (philosophy?) of Chef is not something you’ll get from this book. There is little mention of collaborative (Dev + Ops) approaches to cookbook development; instead the assumption in the book seems to be that a single team will be using Chef, which to me is a missed opportunity.

 Test-Driven Infrastructure with Chef (2nd Edition) by Stephen Nelson-Smith

Published by O’Reilly:

Test Driven Infrastructure with Chef

I reviewed the first edition of Test-Driven Infrastructure with Chef back in June 2012; it was clear to me then that when developing code for infrastructure, we would need to apply good software development practices if we were to avoid untestable spaghetti infrastructure code. Since then, I have (sadly) seen more than one team set off on a ‘DevOps’ or ‘automation’ journey, thinking that “it’s just a bit of [PowerShell/Ruby] – we don’t need tests”, and then discovering after two or three months that they have:

  1. A mountain of untestable code
  2. Invented a new DSL for configuration templating
  3. Reached an impasse with their scripting approach

Let’s be really clear on this: the days of untestable spaghetti scripts should be over. We need to use first-class, well-understood software development practices and tools for our infrastructure code:

  • Version control for scripts & code, preferably using Git and possibly package management
  • Test-Driven Development (TDD)
  • Continuous Integration (CI) – and that’s true CI, not just a Jenkins server!
  • Deployment pipelines for control and visualisation of changes
  • Code reviews

The software development community has known about and proven these practices since at least 1999; there is no excuse for not treating infrastructure as code, not in 2014. I was therefore very pleased to be given a copy of the 2nd Edition of Test-Driven Infrastructure with Chef in the pub one night by the author over a beer late in 2013:

Test-Driven Infrastructure with Beer

I am fortunate to have taken part in Chef training given by Steven Nelson-Smith, so I know from first-hand experience that Stephen not only knows Chef inside-out, but also explains Chef incredibly well. I like the introduction to Ruby at the start of the book because many of the people we’d want to become familiar with Chef may well have never coded before, whether in Ruby or not. In addition to covering essential TDD tools such as TestKitchen and Serverspec, Stephen expands on the MASCOT approach to infrastructure as code: Mainstream, Automated, Side-effect-aware, Continuously-integrated, Outside-in, Test-first. We also see how to use Cucumber with and Leibnitz for acceptance testing of infrastructure requirements.

It’s worth saying that the approach taken by the book assumes that you are a thinking person, keen to understand the reason behind doing things, not simply eager to ‘bosh out’ a couple of scripts to configure something quickly on a server. If you dislike the ‘purpose’ and ‘understanding’ approach, then this book is probably not for you; to be honest, if you are not interested in the ‘understanding’ part, then infrastructure automation is probably not for you either, because with the power of Chef (or Puppet, Ansible, CFengine, etc.) comes the danger of destroying an entire Production infrastructure quicker than you can type knife cookbook upload to fix the problem.

For quick examples of how to configure WordPress or nginx, head to one of the other books mentioned here. What Test-Driven Infrastructure with Chef (2nd Edition) will give you is the solid understanding of how and why to go about developing code for infrastructure using Chef in a way which enables safe, testable, tested changes.

Join the discussion...

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.