Building an infrastructure-as-code pipeline in the cloud Review the top configuration management tools in DevOps

Ansible vs. Chef vs. Puppet vs. SaltStack: A comparison

For teams that oversee ecosystems and software packages, configuration management tools have the power to boost operational consistency. But which products deserve attention?

Consistent configurations enable the many machines, servers and applications in use across an organization to function properly. Configurations also bolster security and performance.

A configuration management tool thus is an important feature in IT operations. But how do you evaluate your options?

Many IT teams can agree on some common principles. Core features must be intuitive to use. Tools must include meaningful visualizations. Automation is a critical ingredient in the mix, as manual methods are time-consuming and error-prone. Configuration managers also shield companies from potential compliance troubles. Additionally, a configuration management tool helps:

  • Push updates and patches to applications and settings;
  • Modify key sets of configurations; and
  • Scan systems to inspect loaded software versions.

The best configuration management tools have most (or all) of this functionality baked in.

Here's a look at four popular configuration management products.

Ansible

Red Hat Ansible's pitch is straightforward: Redefine how simple IT deployments can be. Ansible is first and foremost an automation platform. Accordingly, the software excels at system maintenance and management for the following:

  • cloud ecosystems
  • applications
  • networks
  • containers
  • security

While Ansible cannot be installed on a machine running Windows, it's compatible with numerous operating systems. These include nine leading flavors of Linux (RHEL, CentOS, Fedora, Ubuntu, Debian, Gentoo, Arch, Slackware and Clear) and three Unix derivatives (macOS, FreeBSD and Solaris). Ansible also relies on Python and is thus installable via pip.

Ansible is open source and uses procedural language for ad hoc commands or declarative configurations via modules. This is a hybridized approach.

The Ansible manager was traditionally agentless -- meaning no middleware is required -- but has expanded to enable agent-based use as well. The user can set automations using a password or SSH key and essentially wait for data to roll in, with no extra oversight duties needed. Configurations within Ansible are data descriptions. They're meant to be read by humans and computers alike, to the point where new users won't feel lost.

Additionally, Ansible can run as a remote configuration manager on a single machine. As the control node, this machine can control many other machines within the environment.

Ansible configuration management dashboard
A sample Ansible Tower dashboard

Ansible avoids traditional, error-prone scripting approaches by working toward desired states. If the computers within a network aren't updated to reflect an OS version (or include key applications), the software automatically remedies this issue. Other configuration managers might show the path necessary to achieve the same thing, but that puts the onus on IT teams, adding a task instead of removing one.

A central goal for configuration is the use of modules, which support certain actions and contextual automations. IT professionals can choose from over 1,300 modules in Ansible's main distribution.

Chef Infrastructure Management

Chef's Infrastructure Management products are made to deploy automation across cloud ecosystems, physical ecosystems or virtual machines. The management workflow includes a central workstation, which pushes instructions and more to a distribution server, which then passes those actions onward to targeted systems. These machines (remote or local) are destination nodes. Chef functionally lives on the server, though automations are established via the central node. The company offers AIOps support, thus opening the door for third-party integrations -- including platforms such as Zenoss, Moogsoft and Splunk Enterprise. While not exclusive to Chef, available integrations have made it easier for users to scale with greater visibility.

Chef's agent-based approach helps nodes be "autonomous actors" after setup, an important benefit according to the company. That's not to say that agentless alternatives are inherently inferior -- the agent model simply works better for high-profile industries where security is paramount, such as finance, healthcare, insurance and government. Chef shines when deployed within these environments.

The tool is made to help with scalability as organizations -- and their networks -- expand. Since these changes and others might introduce inconsistencies, remediation is needed. With Chef, teams can execute changes automatically, though they also have the option to test critical changes prior to implementation. Chef says these dry runs help to prevent errors or assess viability.

Whether your infrastructure runs on Azure, AWS, Google Cloud or otherwise, Chef won't force a switch. Chef officially supports the following operating systems and platforms:

  • Unix (AIX and Solaris) and two Unix variants (macOS and FreeBSD);
  • eight Linux distributions (Amazon, CentOS, Debian, Oracle Enterprise, Red Hat Enterprise, SUSE Server, Ubuntu LTS); and
  • Windows.

The Chef community provides unofficial OS-support packages, which are acknowledged within the tool's documentation. These include non-LTS versions of Ubuntu, Arch Linux, Fedora, Gentoo, openSUSE, Scientific Linux and Windows Server (semiannual channel). Teams that maintain ecosystems using any of these OSes may do so successfully, but organizations that oversee sensitive information should carefully evaluate their options. Chef is configurable via Ruby and uses procedural language. It's also open source.

Puppet Enterprise

Puppet Enterprise is another agentless tool that champions simplicity. It welcomes existing automation code, which enables developers and IT professionals to hop aboard without the steep learning curve common with feature-rich software.

Service stability and reliability are two chief focus areas. Puppet Enterprise's architects claim the tool can reduce change failure rates by 2.5 times. Automation management in this case centers on reducing the need for remediation, though Enterprise will show users what needs fixing. By committing more changes that work effectively, Puppet aims to reduce errors and free up IT staff for other tasks. To accomplish this, Puppet Enterprise sends configurations to servers within the managed environment. From there, it can push changes to other downstream machines. If a configuration changes, Puppet defers to the predetermined configuration on the host machine.

As does Chef, Puppet Enterprise uses infrastructure as code. The tool uses state enforcement akin to Ansible, which offloads any core oversight tasks to defined automations. Not only that, Puppet Enterprise allows admins to manage 2.3 times more resources than they would've previously, and manage them more seamlessly, according to the company. This ultimately yields meaningful costs savings.

Puppet Enterprise interface.
Example of Puppet Enterprise showing Nodes.

Puppet Enterprise can connect to any device locally or remotely. Those devices can also run almost any modern OS or distribution, via SSH or WinRM. To keep certain functions safeguarded, Puppet institutes role-based access controls.

Puppet supports the following automation languages: PowerShell, Bash, Python, Ruby and YAML.

Puppet's configurations are considered declarative, following the same state management mantra shared by other configuration managers. Users can also code automations using Puppet's proprietary domain-specific language.

SaltStack

SaltStack makes the case that its key value proposition is its ability to harness event-driven automation across an entire ecosystem. This is a benefit when scaling an environment, as additional complexity essentially necessitates reactive measures.

Automated scripting and state-driven actions help mitigate potential problems. Integrations, drift and preexisting policies can cause problems, and SaltStack adapts effectively to these variables. The manager effectively handles common, complex hurdles, such as:

  • multistep patching procedures;
  • restarts;
  • integrated workflows; and
  • IT service management, configuration management database and record updates.

SaltStack works with public clouds, private clouds, on-premises setups and even containers. This means that teams can deploy SaltStack atop nearly any leveraged technology. The configuration manager seeks to boost reliability and performance across any environment.

SaltStack's setup is somewhat unique. The configuration manager features two agent-based operative pathways -- using smart agents called minions, or proxy agents. Communication is achieved through an event bus. Those who prefer an agentless setup can opt for SSH/WinRM protocols which promote direct configuration. All automations and actions stem from the central machine.

Teams can manage SaltStack's configuration files through SaltStack Enterprise or their preferred code repository. Additionally, configurations integrate with existing CI/CD pipelines.

SaltStack supports a variety of major and minor operating systems, including:

  • Windows
  • Linux (Red Hat, Ubuntu, Debian, CentOS, SUSE)
  • Unix (AIX, Solaris, macOS)

The manager is Python-based, but also supports human-friendly YAML. SaltStack claims that switching from Ruby-based alternatives can reduce the amount of requisite coding by up to 10 times.

SaltStack supports both imperative ordering and declarative configuration execution. This combines a state-based approach with requisites.

Differences between Ansible vs. Puppet vs. Chef vs. SaltStack and how to choose

Choosing the right configuration manager doesn't mean an organization needs to seek out the best tool on the market. What is best for one company may be wrong for a different company.

Every configuration management tool, including Ansible, Chef, Puppet and SaltStack, caters to specific organizational goals and preferences.

Ansible and Puppet, for instance, are agentless; Chef is not. With SaltStack, users have choices about the use of agents.

If an organization has rigid OS requirements, that will dictate which tools to give a close look and which to cross off the list.

Some of the selection process is about comfort, not architectural fit. Consider programming languages. A team that's not skilled in Python, for example, might not be as comfortable with Ansible as one that knows that language well. If PowerShell is of high importance to your team, you will probably want to give a close look at Puppet Enterprise.

In the end, the strengths and competencies of a team will determine which configuration product will be most suitable.

Dig Deeper on Systems automation and orchestration

Software Quality
App Architecture
Cloud Computing
SearchAWS
TheServerSide.com
Data Center
Close