Chef, Puppet, Ansible, Saltstack, Fabric

What are the pros and cons of Chef, Puppet, Ansible, SaltStack and Fabric? (Updated: 13/8/17)

Working in production today often means continuous deployments and an environment distributed all over the world. When your infrastructure is decentralized and cloud-based and you’re dealing with frequent deployments of largely identical services across largely identical servers, having a way to automate the configuration and maintenance of everything is a large boon. Deployment management tools and configuration management tools are designed for this purpose. They enable you to use recipes, playbooks, templates, or whatever terminology to simplify automation and orchestration across your environment to provide a standard, consistent deployment.

There are several considerations to keep in mind when choosing a tool in this space. One is the model for the tool. Some require a master-client model, which uses a centralized control point to communicate to distributed machines, while others can or do operate on a more local level. Another consideration is the makeup of your environment. Some tools are written in different languages and support for particular OSs or setups can vary. Making sure your tool of choice will mesh well with your environment and the particular skills of your team can save you a lot of headaches here.

1. Ansible

1
Ansible is an open source tool used to deploy applications to remote nodes and provision servers in a repeatable way. It gives you a common framework for pushing multi-tier applications and application artifacts using a push model setup, although you can set it up as master-client if you’d like. Ansible is built on playbooks that you can apply to an extensive variety of systems for deploying your app.

The Ansible Tower dashboard

 

When to use it: If getting up and running quickly and easily is important to you and you don’t want to install agents on remote nodes or managed servers, consider Ansible. It’s good if your need or focus is more on the system administrator side. Ansible is focused on being streamlined and fast, so if those are key concerns for you, give it a shot.

Price: Free open source version, with paid plans for Ansible Tower starting at $5,000 per year (which gives you up to 100 nodes).

Pros:

  • SSH-based, so it doesn’t require installing any agents on remote nodes.
  • Easy learning curve thanks to the use of YAML.
  • Playbook structure is simple and clearly structured.
  • Has a variable registration feature that enables tasks to register variables for later tasks
  • Much more streamlined code base than some other tools

Cons:

  • Less powerful than tools based in other programming languages.
  • Does its logic through its DSL, which means checking in on the documentation frequently until you learn it
  • Variable registration is required for even basic functionality, which can make easier tasks more complicated
  • Introspection is poor. Difficult to see the values of variables within the playbooks
  • No consistency between formats of input, output, and config files
  • Struggles with performance speed at times.

View video

2. Chef

2
Chef is an open source tool for configuration management, focused on the developer side for its user base. Chef operates as a master-client model, with a separate workstation needed to control the master. It’s based in Ruby, with pure Ruby used for most elements you write. The Chef design is transparent and based on following the instructions it’s given, which means that you’ll have to make sure your instructions are clear.

The Chef dashboard

When to use it: Before considering Chef, make sure you’re familiar with Git, as it’s required for configuration, and Ruby, as you’ll have to be writing in it. Chef is good for development-focused teams and environments. It’s good for enterprises looking for a more mature solution for a heterogeneous environment.

Price: Free open source version, standard and premium plans priced on a per node annual basis. The prices start at $137/node/annual for Chef Automate, or $72/node/annual for Hosted Chef.

Pros:

  • Rich collection of modules and configuration recipes.
  • Code-driven approach gives you more control and flexibility over your configurations.
  • Being centered around Git gives it strong version control capabilities.
  • ‘Knife’ tool (which uses SSH for deploying agents from workstation) eases installation burdens.

Cons:

  • The learning curve is steep if you’re not already familiar with Ruby and procedural coding.
  • It’s not a simple tool, which can lead to large code bases and complicated environments.
  • Doesn’t support push functionality.

View video

Find the Crap in Your Java App

Show me how >>

Fred

3. Fabric

3
Fabric is a Python-based tool for streamlining SSH in application deployments. Its primary usage is for running tasks across multiple remote systems, but it can also be extended with plugins to provide more advanced functionality. Fabric will configure your system, do system/server administration, and automate the deployment of your app.

The Fabric dashboard

When to use it: If you’re just starting out in the deployment automation space, Fabric is a good beginning point. It helps if your environment involves at least a little bit of Python.

Price: Free

Pros:

  • Good at deploying apps written in any language. It doesn’t depend on system architecture, but rather OS and package manager.
  • Simpler and easier to deploy than some other tools in this space
  • Extensively integrated with SSH for script-based streamlining

Cons:

  • Fabric is a single point of failure set up (generally the machine you’re running the deploy on)
  • Uses a push model, so not as well suited for a continuous deployment model as some other tools in this space
  • While it’s a great tool for deploying apps in most languages, it does require Python to run, so you must have at least a little Python in your environment for Fabric.

View video

4. Puppet

Puppet is one of the long standing tools in the full-fledged configuration management space. It’s an open source tool, but given how long it’s been around, it has been well vetted and deployed in some of the biggest and most demanding environments. Puppet is based on Ruby, but uses a customized Domain Scripting Language (DSL) closer to JSON for working within it. It runs as a master-client setup and uses a model-driven approach. The Puppet code design works as a list of dependencies, which can make things easier or more confusing, depending on your setup.

The Puppet Enterprise dashboard

When to use it: Puppet is a good choice if stability and maturity are key factors for you. It’s good for large enterprises with a heterogeneous environment and range of skills on the DevOps team.

Price: Puppet comes in a free open source version or a paid commercial enterprise version that runs $120 per node per year, with volume discounts.

Pros:

  • Well-established support community through Puppet Labs.
  • It has the most mature interface and runs on nearly every OS.
  • Simple installation and initial setup.
  • Most complete Web UI in this space.
  • Strong reporting capabilities.

Cons:

  • For more advanced tasks, you will need to use the CLI, which is Ruby-based (meaning you’ll have to understand Ruby).
  • Support for pure-Ruby versions (rather than those using Puppet’s customized DSL) is being scaled back.
  • Because of the DSL and a design that does not focus on simplicity, the Puppet code base can grow large, unwieldy, and hard to pick up for new people in your organization at higher scale.
  • Model-driven approach means less control compared to code-driven approaches.

View video

5. Saltstack

Saltstack
SaltStack (or Salt) is a CLI-based tool that can be set up as a master-client model or a non-centralized model. Based in Python, Salt offers a push method and an SSH method of communication with clients. Salt allows for grouping of clients and configuration templates to simplify the control of the environment.

When to use it: Salt is a good choice if scalability and resiliency are a big concern. It’s good for system administrators thanks to its usability.

Price: Free open source version, and a SaltStack Enterprise version that is based on an annual per node subscription basis. Specific pricing is not listed on their site (just a “Contact us” link), but others have reported a $150 per node per year starting point.

Pros:

  • Straightforward organization and usage once you’re past the setup phase.
  • Their DSL is feature-rich and isn’t required for logic and states.
  • Input, output, and configs are very consistent – all YAML.
  • Introspection is very good. It’s easy to see what’s happening within Salt.
  • Strong community.
  • High scalability and resiliency in the master model with minions and hierarchical tiers.

Cons:

  • Difficult to set up and to pick up for new users.
  • Documentation is challenging to understand at the introductory level.
  • Web UI is newer and less complete than other tool’s Web UIs in the space.
  • Not great support for non-Linux OSs.

View video

Ansible vs. Chef vs. Fabric vs. Puppet vs. SaltStack

Which configuration management or deployment automation tool you use will depend on your needs and preferences for your environment. Chef and Puppet are some of the older, more established options, making them good for larger enterprises and environments that value maturity and stability over simplicity. Ansible and SaltStack are good options for those looking for fast and simple solutions while working in environments that don’t need support for quirky features or lots of OSs. Fabric is a good tool for smaller environments and those looking for a more low lift and entry level solution.

Java 8

Java 8 exceptions have never been so beautiful – Try OverOps for Java 8

email
Yoda

Looking for more posts like this?

Join our force of more than 30,000 Java Jedi masters!

Watch a live demo
Yoda
Josh does product marketing for OverOps. He's a big baseball fan and a small beer nerd.
  • Valentin Napoli

    What about Rudder ? :/ http://www.normation.com/en/

  • Mars_Ultor

    I know its hard to do these comparisons but some things are just plain inaccurate. For Puppet,

    “Because of the DSL and a design that does not focus on simplicity, the Puppet code base can grow large, unwieldy, and hard to pick up for new people in your organization at higher scale.”

    Puppets design is focused exclusively on simplicity, its entire config method is based on manifests on how a node should look like, which can be written using classes and Puppet DSL, its as simple as it gets

    service { “nginx”:ensure => running,hasrestart => true,require => Package[“nginx”]
    }

    You cant get easier than this

    For Salt, “Difficult to set up and to pick up for new users.”

    l would say totally the opposite, out of all 4 applications, I found Salt to be the easiest to install and pick up, its certainly less complex architecture setup than Puppet (no SSL certs, just AES encrypted keys “salt-key -A” to accept., although you can make a valid argument that SHA1 certs are more secure than AES keys)

    Also you didnt mention Salts greatest benefit, its speed, its by far the fastest remote exec tool out of all them. And it has its own RAET connection option for UDP level communication

    • http://techneiq.com naveed

      Sounds like you have some good insight in to these tools. You might want to consider writing a similar article comparing these tools based on your experience.

      • Mars_Ultor

        Id love to write a comparison article but unfortunately Ive only worked with Salt and Puppet, havent had time to play with Ansible and Chef or Fabric or CFEngine. Maybe one day 🙁

  • Braden Wright

    Good read. I would add for Chef…. that while the default is pull it can do pushes via knife commands:

    knife ssh SEARCH_QUERY chef-client

    actually any command can be run this way on all or a subset of nodes. Also as a plus for Chef, there testing stack is really nice… using Test-Kitchen and Serverspec is a great combo, I’ve been soooooo please with Chef.

  • Isabel M

    The Chef in your post is way too old. At the time of you posting this guide, v12.0 is already available.

    • Dipak Warade

      I agree.

  • manuel

    Very useful!!! It was that I needed to read, Thanks.

  • Ernest Rider

    Fabric can be engineered to pull. Everything has to start with a push. One of the first things you do is to put an ssh check in fabric to make things local and not remote. Then you can base class a remote agent in fabric deploy it as a push and it will pull.

    i.e. anything is possible if you can program with the tool

  • Mehdi Yedes

    Saltstack: Difficult to set up and to pick up for new users? I find that quite inaccurate.

    I used all of the tools mentioned in your article and I would say that the most difficult tool to set up was Chef. Salstack is almost as easy as Ansible to setup.

    • forsetiboston

      I have been down the Chef road three times, and three separate Fortune 500+ companies. We phased out Chef at one place because it was taking literally a ‘week’ to deploy new builds across the production cluster. We went with SaltStack, now a few years after my first exposure I am being ‘pushed’ or encouraged to suggest Chef for our clients. The more I work with it the more I find it a ridiculous tool that requires a team of developers to manage. At the larger shop we had a team of four people dedicated to just Chef/deployments.

      Anyway SaltStack is by far the most simple to setup and learn. It was almost too simple.

      • Mehdi Yedes

        I am glad that someone with better experience with Chef actually agrees with me on this point.

      • intelno001

        This has been my experience with chef as well, almost exactly. Tons of dev work just to do simple operations.

  • Jared

    FYI: DSL stands for “Domain Specific Language” not “Domain Scripting Language”

    • Duc Quoc

      It does not matters. Decades ago people knew programming languages with specific purpose already. Then they are amazed with the “general purpose” languages (Pascal, C, …) . And now they are back with some cuter names “DSL” .

      OOP was condsidered better than functional paradigm, but now more and more functional languages is “coming back”.

      “Scriptlet” (mixing HTML and code PHP/JSP … ) was considered bad some years ago, but now the new “front end frameworks” mixes a lot (React, AngularJS, SASS, …).

      So, in the end, what works is more important than trying to play with words to advocate some paradigm/trend. What makes more values will be subsantial, regardless of what name people are trying to “coin” then.

      • Jared

        Step off your soapbox and take a deep breath.

        I merely offered my comment for the sake of accuracy. No one is trying to “play with words” to advocate anything. “DSL” is not newly coined, nor is it intended to be “cute”. It’s just an acronym for “Domain Specific Language”, which is a term for a language specialized to a specific application domain. It has nothing to do with popularity or trends. DSLs come in a variety of shapes and sizes, and can support a plethora of programming paradigms, depending on the domain. That’s the point 😉

  • Alik

    Very nice comparison, thanks a lot it was helpful.
    p.s: Your Chef link leads to Apple’s website 🙂

  • Scott Turner

    Some orgs don’t want to invest in retraining their staff to learn new declarative or scripting languages. Others want ops toolchain rationalization (1 solution for both app release automation and app config automation). Others want equal support of Windows & Linux. So Orcaconfig may be best for them (yep I work there) — here is a comparison chart http://www.orcaconfig.com/comparing-puppet-and-chef-and-ansible-and-orca/

  • Antek Baranski

    Would it be worth to revisit this comparison, all tools have moved forward since then, like ‘chef push’ and the other tools have not remained static either. 🙂

  • Gupta

    great article….very helpful comments too.

  • v3ss

    > Less powerful than tools based in other programming languages.
    Care to elaborate?