Perfectly positioned to provide automation for the infrastructure providing both private and public clouds (and a darling of the burgeoning DevOps scene), Puppet has seen a groundswell of adoption in recent years. It’s undoubtedly very capable but may not be what some enterprises expect.
For those not familiar with Puppet it’s a tool which helps to automate system administration tasks. They’ve managed to build a large mindshare and strong brand recognition although it’s still a relatively small company of around 190 staff globally, headquartered out of Portland, Oregon in the US. The London based team is actively growing (interested in a job with PuppetLabs?) and the first usergroup meeting in London recently attracted 45 people at pretty short notice. Their financial results speak for themselves with year on year sales more than tripling and over 9 million downloads. Pretty impressive for a company which in 2010 only had 11 staff! They’re not the only show in town (Chef, Salt Stack, & Ansible are notable competition) but they seem to be getting the most traction.
Puppet’s success lies in the VM sprawl ushered in by virtualisation combined with the availability of cloud infrastructures which can scale rapidly and on demand. If you need to quickly spin up hundreds, maybe thousands, of servers and guarantee that their configuration is identical and correct, how would you do it? How do you manage the rapid releases required by your software development lifecycle, especially if you’re aiming for continuous delivery? How do you deal with configuration drift in your test and development environments? This is where Puppet comes to the rescue.
I’ve been keeping an eye on Puppet as a configuration management tool since 2009 when it first popped up on my radar (maybe it was Thoughtworks Radar). At the time I was looking for tools to help deploy RedHat Linux 4.6 but sadly I didn’t opt for Puppet – in hindsight I consider that a missed opportunity! Earlier this year it was covered at the London VMUG and I’ve recently had conversations with PuppetLabs staff both at VMworld Europe (Jose Palafox) and in the UK (Steve Thwaites). Have a read of the official PuppetLab intro then continue reading to get my initial thoughts.
Puppet comes in two flavours, the open source (Puppet) and the commercial (Puppet Enterprise), both of which are created by PuppetLabs. As is often the case the commercial offering wraps up the open source ‘core’ and adds features, functionality, and support which enterprises tend to require (for full details check out PuppetLabs helpful comparison page). Headline additions in the recently released v3.0 Enterprise edition include a GUI, the recently announced VMware integration, role based access controls (RBAC), and a single cross platform installer.
Puppet can manage configuration throughout the stack, from physical and virtual machines through to operating systems, middleware, and applications (see the diagram on the right).This means it needs to integrate with a wide variety of other systems, which is done via ‘modules’ stored in the freely available online repository PuppetForge – currently there are nearly 1,600 covering Cisco and Juniper switches, Netapp, Windows, Linux, VMware, AWS, Azure, Google Compute Engine and more.
A distinguishing feature is that Puppet uses a declarative approach rather than an imperative approach – ie it specifies ‘what’ to do rather than ‘how’ to do it. Declarative languages are nothing new but it does mean you have to think differently about how to achieve what you need – I’m planning another blogpost to dive into this concept so keep an eye out.
Puppet aims to ensure systems are always in compliance, which it does by regularly enforcing the chosen configuration (every 30 mins by default) and reporting on any deviations. Puppet runs using a client/server architecture, with a central PuppetMaster coordinating remote nodes via an agent (which needs installing).
For the last few years there has been basic integration with VMware but it’s limited to creating, starting, and stopping VMs (although configuring the guest OS is obviously possible just as you would a physical server). At the recent VMworld conference in Barcelona VMware announced integration with vCAC (specifically vFabric Application Director), whereby the PuppetForge modules can be used as part of the blueprints used to deploy applications – watch VMworld session VCM5271 for some good content, the integration demo starts at the 30 minute mark. Unfortunately this integration is only offered in the top end edition of VMware’s vCloud Suite which isn’t cheap – given the cost of Puppet ($99 per managed node per year) you’re not going to justify the price with Puppet integration alone unless you have a large estate! You can integrate the open source version of Puppet with vCAC although you may need to do some specific configuration to get it working. A related Puppet integration is Razor (written by Nick Weaver) which uses similar concepts (declarative language, agents) and lets you deploy ESXi (among others) to bare metal servers – it’s a cool service so deserved a mention! 🙂
Despite the addition of a GUI don’t assume it’s a point and click tool – Puppet is very much a command line tool and you’ll need an understanding of Linux to use it. The documentation is littered with references to Git, subversion, yum, and other common Linux tools and the GUI is really just a reporting tool – most of the time to configure anything you’re working at the command line and editing files by hand (though there are IDE options for Puppet).
For anything but the simplest implementations, you’ll also want to be familiar with development concepts such as objects, classes, variables, properties, and inheritance. You may be able to reuse some of the PuppetForge modules but even then you’ll likely want to add your own tweaks which require development in Puppet’s proprietary language. PuppetLabs have provided a pretty good set of resources for learning and Puppet certification is available in two tracks, Puppet Professsional (for sysadmins) and Puppet Developer. Even for the Puppet Professional track experience of some of development concepts mentioned earlier are required.
Despite it’s open source background PuppetLabs were keen to stress that Microsoft Windows works well and is fully supported. From reading forums and speaking to a few colleagues I’d say it’s still the less common use case, typically losing out to Microsoft’s SystemCentre suite, a situation which PuppetLabs are aware of. This isn’t the fault of PuppetLabs it’s simply a function of Linux being more suited to this style of management where all configuration resides in text files compared to Windows’ registry and binary files. A typical example is creating a user – on Windows you have to specify passwords in clear text because there’s no API for using password hashes, something which can be achieved on any Unix flavour including Mac OSX. Microsoft have recognised the need for a declarative approach to configuration management and recently released Desired State Configuration in Powershell v4, which looks very similar to Puppet but using Powershell. Which tool you use is likely to depend on the degree of homogeneity in your environment.
Apparently there’s a blogger program in the works although my enquiry has so far gone unanswered – if I hear anymore I’ll let you know.
Download the ‘learning VM’ and work through the tutorials on the PuppetLabs website.
Follow Puppet Labs on Twitter: @puppetlabs
Good review via Javaworld