Review: Puppet vs. Chef vs. Ansible vs. Salt

The leading configuration management and orchestration tools take different paths to server automation

Page 4 of 4

Puppet or Chef? Ansible or Salt?

Whereas Puppet and Chef will appeal to developers and development-oriented shops, Salt and Ansible are much more attuned to the needs of system administrators. Ansible's simple interface and usability fit right into the sys admin mindset, and in a shop with lots of Linux and Unix systems, Ansible is quick and easy to run right out of the gate.

Salt is the sleekest and most robust of the four, and like Ansible it will resonate with sys admins. Highly scalable and quite capable, Salt is hamstrung only by the Web UI.

Puppet is the most mature and probably the most approachable of the four from a usability standpoint, though a solid knowledge of Ruby is highly recommended. Puppet is not as streamlined as Ansible or Salt, and its configuration can get Byzantine at times. Puppet is the safest bet for heterogeneous environments, but you may find Ansible or Salt to be a better fit in a larger or more homogenous infrastructure.

Chef has a stable and well-designed layout, and while it's not quite up to the level of Puppet in terms of raw features, it's a very capable solution. Chef may pose the most difficult learning curve to administrators who lack significant programming experience, but it could be the most natural fit for development-minded admins and development shops.

For more in-depth looks at these tools, read the full reviews:

Orchestrators at a glance

 Puppet 3.0Chef 11.4Ansible 1.3Salt 0.17
Pros
  • Modules can be written in Ruby or a simpler, Puppet-specific subset of Ruby
  • Push commands let you trigger modifications immediately
  • Web UI handles reporting, inventorying, and real-time node management
  • Detailed and in-depth reporting on agent runs and node configurations
  • Cookbooks and recipes can leverage the full power of Ruby
  • Centralized JSON-based "data bags" allow scripts to populate variables during runtime
  • Web UI lets you search and inventory nodes, view node activity, and assign Cookbooks, roles, and nodes
  • Modules can be written in nearly any language
  • No agent required on managed clients
  • Web UI lets you configure users, teams, and inventories, and apply Playbooks to inventories
  • Extremely simple to set up and get running
  • State files can be simple YAML configuration templates or complex Python or PyDSL scripts
  • Can communicate with clients through SSH or through a locally installed agent
  • Web UI offers views of running jobs, minion status, and event logs, and lets you execute commands on clients
  • Extremely scalable
Cons
  • Requires learning Puppet DSL or Ruby
  • Installation process lacking in error checking and error reporting
  • Requires knowledge of Ruby programming
  • Currently lacks functional push commands
  • Documentation is sometimes vague
  • Lacks support for Windows clients
  • Web UI doesn't tie into an existing Ansible deployment automatically; inventories must be imported
  • Web UI is not as mature or complete as competitors
  • Lacks deep reporting capabilities
PricingFree open source version; Puppet Enterprise costs $100 per machine per year

Free open source version; Enterprise Chef free for 5 machines, $120 per month for 20 machines, $300 per month for 50 machines, $600 per month for 100 machines, and so on

Free open source version; AWX free for 10 machines, then $100 or $250 per machine per year depending on supportFree open source version; SaltStack Enterprise costs $150 per node per year, with volume discounts and site licenses available

This article, "Review: Puppet vs. Chef vs. Ansible vs. Salt," was originally published at InfoWorld.com. Follow the latest developments in application development, cloud computing, and open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.

| 1 2 3 4 Page 4
From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies