June 20, 2017

DevOps Digest 501: Flavors of Continuous Delivery, Part 1

DevOps Digest

We've arrived at the final challenge for building out our DevOps pipeline. If we think of Continuous Integration (CI) as a forge, shaping and building our product, and Continuous Testing (CT) as the craftsman’s eye, lovingly validating each step, then we can appreciate the hard-won truth of Continuous Delivery (CD) as the pointy end of the resulting sword.

Bluntly put, CD is what ultimately puts your product into your customers’ hands, and if you do it wrong somebody is going to get hurt — likely at both ends. CD is as much an art as a science: you’ve got to get your release cadence just right.

It would be nice if we could offer you a one-size-fits-all Big Box o’ CD solution, but we can’t. Nobody can. So in parts 1 and 2 of this section, we’ll offer up a handful of tools for you to hone your processes.


Our first tool is Puppet, the oldest and most venerable option, with both free and enterprise options available. It’s worth giving serious consideration for that reason alone, to say nothing of how it essentially defined the shape of modern infrastructure management tools.

In the Puppet vernacular, an agent is installed on each node needing to be managed. (Here, “node” refers to any device that requires management as part of a computing infrastructure including web/other servers, client workstations, virtual machines of any sort, or even mobile devices.) The agent then communicates with a master to receive configuration information and reports its successes and/or failures back to said master. This architecture can serve the needs of numerous nodes with a single master, or even multiple masters, though coordination grows progressively trickier as you scale.

Puppet was intended to be a cross-platform solution, so its configuration details are specified in terms of resources, rather than platform-specific scripts. A resource has a type, name, and a set of properties that need to be configured. Its language is both a Ruby adaptation and declarative in nature, so here is a sample resource definition:

user { ‘jwilliston’ :      ensure      => present,      comment     => ‘The new guy, don’t trust his code’,      gid         => developers,      shell       => ‘/bin/bash’,      home        => ‘/var/tmp’}


This defines a resource of type ‘user’, whose name is ‘jwilliston’, and must have the set of properties that follow. Any Puppet agent receiving this will ensure that the specified properties are set accordingly as it creates this user. This is only one of the built-in resource types available with Puppet, and you can also create your own. For more details, visit the Puppet Resource Type page.

Additionally, Puppet manages resource dependencies. The master builds out a catalog of resources to be installed, which also specifies their proper order of installation. This way, users only need worry about top-level details, like wanting a node to be a web server, and can leave Puppet to ensure that the lower-level stuff for said web server will be there when needed.

And Puppet is available for just about any platform you’re likely to be using. It does, however, lack any built-in facility to “push” changes to nodes, though third-party options exist. That may not be a big deal, particularly insofar as you can set the agent polling time for however responsive you need your systems to be.

Pros and cons aside, Puppet’s particular cross-platform “flavor” is probably system-level scripting. This is because advanced tasks can still require substantial input at the command line. Nevertheless, Puppet is a mature, stable choice with a solid web user interface for reviewing and managing many nodes.


If Puppet “tastes” like system-level scripting, then our next tool, Chef, resembles a higher-level, all-you-can-eat buffet table, where you’ll spend some time getting what you want. This is because Chef is extremely flexible, can be complicated to set up, and has a non-trivial learning curve.

The whole Chef approach is architecturally similar to Puppet but clothes itself in a set of cooking metaphors. The notion of resources is there, just at a lower level. Chef resources are the building blocks of recipes, which define everything required to configure some aspect of a node.

Recipes are stored in cookbooks, the fundamental unit for communicating configuration information. Cookbooks are aimed at fulfilling a particular set of requirements and are (unsurprisingly?) found at supermarkets, including the Chef’sofficial one.

There you’ll find many cookbooks geared toward installing and configuring a particular piece of software, though you’ll also find task-oriented cookbooks for configuring a piece of software in a particular way.

Finally, Chef administrators rely on a knife, a command-line utility that can manage cookbooks and recipes, set up whole environments, and even forcibly provision new nodes remotely.

The knife tool even lets you assign high-level roles to nodes, roles being defined in terms of things to do, called run-lists, and the data required to do those things, called attributes — which themselves can be simple properties, “data bags” (chef-specific JSON) of properties, and more. Roles can depend upon other roles and specify recipes to be run, parameters to be used relative to a particular node, etc. They comprise the few bits of Chef that don’t sound like they belong in a kitchen.

As high-level as Chef can initially seem, at some point you’re going to get your hands dirty. At that point, it’ll be time to polish up your Ruby skills. A salient difference between Puppet and Chef is that Chef is aimed at developers, insofar as it lets you get away with anything you can accomplish in Ruby — including support for test-driven development (TDD) tools. The mantra “infrastructure as code” comes to mind.

With Chef, you’re less likely to run into infrastructure management needs at a scale it can’t handle, but you’re going to have to devote more time and energy to take advantage of its power. But if you’re already familiar with Puppet, or even system-level scripting generally, you might find yourself drawn to the more elegant mechanisms of Chef, which include completely open-source analytics and node management web interface, a fact worth pointing out in distinction to Puppet as well.

Next week, we’ll round out our final chapter by exploring two other CD tools that you could use: SaltStack and Ansible.


See you next Tuesday!

John Williston