With virtualization driving the meteoric rise in server instance counts, it's no wonder that so many configuration automation tools are hitting their stride. Where once we either did without configuration management or created our own custom scripts, we now have many options to manage changes to large numbers of servers.
One of the best options is Puppet Enterprise, the commercial version of the Puppet open source project. Version 3.0, just arrived, passes along many advances borne from the community edition, as well as new features found only in the enterprise version.
If you're already well versed in Puppet, then this version will bring with it welcome changes. The first is the speed. Although I wasn't able to fully corroborate Puppet Labs' claims of a 60 percent faster catalog core compilation, 2.7x speed in agent runtimes, or the heralded "200 percent performance boost," the reality is definitely close to that. For longtime Puppet users with large-scale deployments, the speed improvements are a very big deal, as they will reduce the load on both Puppet servers (that is, Masters) and managed nodes, as well as the time required to roll out changes across the board.
Puppet Enterprise 3.0 also introduces a new orchestration engine that allows for more granular and more stable large-scale changes. As compared to earlier versions, the new orchestration features include finer-grained filtering to select subsets of systems to modify or directly control, as well as batching functions to permit a gradual rollout of changes rather than performing them all at once.
Another major change is the deeper support of Windows servers. Previously, many actions such as Live Management would not work with Windows. The new version brings Live Management (a Web UI for managing nodes in real time) and orchestration of Windows servers into the fold.
Puppet Enterprise supports a broad range of platforms, providing Red Hat, Ubuntu, Debian, Solaris, and AIX packages, as well as a general Unix tarball. In addition, the open source community has released code for a variety of other operating systems. These packages are unsupported by Puppet Labs, but they offer some functionality for other Linux distributions, various BSD flavors, and Mac OS X.
Inside the Puppet
Puppet is definitely a Linux/Unix-centric app. Although there is greater support for Windows in the new version, this tool is designed by and for Linux/Unix admins. Any Puppet deployment larger than a smattering of servers will require custom code and a fairly deep knowledge of Linux/Unix internals. This is not a click-and-drag tool, nor a Web-based configuration management tool, but a configuration file-based tool with a Web UI for monitoring and organisational tasks -- as it should be.
Working with Puppet requires learning Puppet's configuration language and knowing your way around Puppet's classes and modules, which are organised in configuration files in a specific hierarchy under /etc/puppetlabs/puppet. Without going into the heavy details, you can consider all modules to be includes in a big script, with classes defined and linked to specific server nodes or groups of nodes. This provides a very straightforward method of dealing with the complex and detailed requirements of managing multiple server platforms and distributions, not to mention switching and storage applications.
The Web UI included with Puppet Enterprise is well appointed and straightforward, allowing for the creation and management of nodes, groups, and classes, as well as report generation and viewing. It is a useful tool for manipulating node organisation and quickly determining issues with certain parts of the framework. It also provides limited Live Management of nodes or groups of nodes. However, for many implementations it may be easier to think of the UI as read-only, and to work mostly through the command line. The deeper into Puppet you get, the more likely this will become, as you may discover that you can only apply certain configurations and modules to nodes and groups through the CLI, and these changes may not be reflected in the Web UI.
An example might be a module downloaded through the Puppet Forge module-sharing site that cannot use a class due to the nature of what it's configuring. In this case, you will need to apply the module to nodes or groups from within the Puppet configuration files, as you can't define a class that maps to a class definition within the Web UI. This configuration element will thus not appear in the Web UI.
I also encountered a few bugs in the Web UI, such as the fact that you can add a group with a name containing a period, but you cannot thereafter edit or delete that group through the UI. This would seem to be an input validation bug, because it appears that a period is an illegal character in group names.
Standing up the Puppet
Installing Puppet is conceptually very simple. Choose a supported platform for your Puppet Master server, and run the install script. This will prompt for a variety of packages and options to be installed: the Puppet Master, PostgreSQL, Cloud Provisioner, and so forth. The install script will also prompt for a username and password for the first administrator in the Web UI.
It's all very simple, but somewhat lacking in error checking and error reporting. For instance, if you install on a Linux system that has PostgreSQL already installed but not configured or running, the installer will happily install its own PostgreSQL binaries -- then try to use the wrong client to connect, which will fail, and produce a fairly useless error message saying that the PostgreSQL server failed to start, even though the server was clearly running. Fortunately after some digging, that root cause was discovered and fixed, but it wasn't the only time the installer bailed without any useful logging or apparent cause. The installation scripts are simple bash scripts, so debugging wasn't a big challenge.
These quibbles and pitfalls aside, the initial configuration is very straightforward, requiring DNS for all nodes and (obviously) clear network connectivity. Once the Puppet Master is installed, each node is configured essentially the same way, by running an installer for that node's platform, which generates a certificate and contacts the master server for approval. When the node is approved, it becomes configurable through Puppet and can be added to groups or bound to classes through the Web UI or CLI.
Then comes the harder part: configuring Puppet to make changes to those systems. This is done through modules, either custom-coded or downloaded from the Puppet Forge site and customised.