Updated on February 5, 2016 by UpGuard
Configuration Management (CM) tools like Pallet and Puppet are to sysadmin and DevOps professionals what a dishwasher is to an exhausted homeowner who’s just come home to the pile of dirty dishes from last night’s party – a huge life and time saver.
You need to deploy the latest JRE version to all 200 servers in your datacenter, and get a report of which ones failed; you need to quickly create a new virtual server with CentOS, Tomcat and MySQL automatically installed; you need a report of how many servers in your datacenter have port 3222 open then close it on all of them; you need to issue a command for only the servers running Win 2008 server to automatically restart next Friday at exactly 3.00am so an installed update can take effect after rebooting – all these are scenarios that a CM tool can set up and execute simultaneously and automatically so you don’t have to do them manually. Pallet and Puppet are two such tools, and we’ll take a closer look to see what differentiates them.
Pallet is actually more of a CM framework or library tailored towards developers than a standalone CM tool, that’s unlike most CM tools which are geared towards admins. Thus it’s lightweight and can be integrated or embedded into other applications. Pallet is designed for cloud-based environments but can also work in traditional on-premise servers. It uses Clojure which runs on a JVM with native support for clusters, node dependencies and agile development; in fact Clojure is itself a JVM interpretation of the LISP language. Pallet is managed by parent company PalletOps, and kicked off operations in 2011. Compared to Puppet, it is a newcomer with a tiny market share; even other latecomers like Ansible and Salt are bigger than Pallet. Pallet is currently available only for Linux/ Unix. Its documentation is still a work in progress and the user community is small but helpful.
Puppet, on the other hand, is a giant in the open-source CM arena. Developed by PuppetLabs and first released in 2005, it commands the largest CM market share and user base. Big-league organizational Puppet users include Google, Red Hat, Siemens, Los Alamos Labs, and Stanford and Harvard Universities. Such clients lend a lot of credibility and gravitas to any software vendor. Puppet is developed in Ruby, and its CLI supports both pure Ruby (to be deprecated in future versions) and its own Ruby-based DSL, so users must first learn Ruby to use Puppet effectively. It also has what is hands-down the most highly developed GUI of all CM tools. It’s slick and powerful, able to both serve as a monitoring tool as well as issue some commands, though it still cannot perform all functions like the CLI can. Puppet utilizes a master-agent model, wherein a central master server sends out agents to all nodes to be controlled in the environment; these agents in turn execute the desired actions on the client nodes. The different configs and setups, called states, are described and stored in files called manifests. From its market dominance it’s also no surprise to hear that Puppet has a massive and helpful user community.
As with many other comparisons in life between two competing options, the choice of Pallet vs. Puppet comes down to what your needs are. Puppet is geared more towards sysadmins. Admins usually value environmental stability and inter-operability, and they look for tools to enable them do as much ‘administering’ as possible from one centralized tool or platform. Whether such a tool has quick-deployment capability or imperative (rather than declarative) syntax is not usually very important to admins. So Puppet may be a better fit for sysadmins.
Pallet, because of its fast turnaround capacity in setting up and getting going, is actually more similar to another CM tool, Chef. And that also implies it’s more suited to a development setup where you may not require a full-fat tool with all the bells and whistles, where it may be more important to be able to quickly get the ball rolling, to quickly start issuing and executing imperative statements and commands to a few servers, or to even embed some CM functionality in another app. Pallet is perfect for such tasks, but Puppet with its many libraries and dependencies, could be about as nimble as a fully loaded semi-trailer in such a situation.
These differences will also highlight another factoid – Pallet may be better suited to cloud-based environments where virtual servers are more likely to be short-lived and experimental, and Puppet may be a better fit for a full datacenter hosting 24-7 production servers, even though it also has now added support for cloud deployments.
So the answer to the question: Pallet or Puppet? It depends. If you have to join your friends on a hike, do you choose a pair of customized heavy-duty hiking boots or just a pair of sneakers for comfortably walking long distances? They can both do the job, but one will be better than the other, so you’ll look at or ask about the terrain, walking distance and other factors before making your decision, right? Good – case closed.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.