Puppet, Chef, Ansible, and SaltStack are four industry-leading Infrastructure-as-a-Service (IaaS) configuration management tools that offer different paths to achieve a common goal: managing large-scale server infrastructure efficiently, with minimal input from developers and sysadmins.
All four of these configuration management tools are designed to reduce the complexity of configuring distributed infrastructure resources, enabling speed, and ensuring reliability and compliance. This article explores the mechanisms, value propositions, and concerns pertaining to each configuration management solution.
If you use any of these tools (or other config management tools such as MS SCCM, Tivoli Provisioning Manager, or BladeLogic), you’ll also learn how JetPatch fills a big gap for all of them by managing server tool agents.
The Claim: “Manage and automate more infrastructure and complex workflows in a simple yet powerful way.”
Approach: Declarative (you specify the desired end state, and the tool determines how to achieve that state as efficiently as possible); requires Puppet Agent on each server you wish to configure; master server required by default (masterless configuration available).
Puppet is a pioneering configuration automation and deployment orchestration solution for distributed apps and infrastructure. The product was originally developed by Luke Kanies to automate tasks for sysadmins who had to spend ages configuring, provisioning, troubleshooting, and maintaining server operations.
This open-source configuration management solution is built with Ruby. It offers custom Domain Specific Language (DSL) and Embedded Ruby (ERB) templates to create custom Puppet language files, as well as a declarative paradigm programming approach. Puppet uses an agent/master architecture, meaning agents manage nodes and request relevant info from masters that control configuration info. The agent polls status reports and queries regarding its associated server machine from the master Puppet server, which then communicates its response and required commands using the XML-RPC protocol over HTTPS. This resource describes the architecture in detail. Users can also set up a masterless and decentralized Puppet setup, as described here.
Puppet Enterprise Capabilities:
- Automated provisioning
- Configuration automation
- Visualization and reporting
- Code management
- Node management
- Role-based access control
- Strong compliance automation and reporting tools
- Active community support around development tools and cookbooks
- Intuitive web UI to take care of many tasks, including reporting and real-time node management
- Robust, native capability to work with shell-level constructs
- Initial setup is smooth and supports a variety of OSes
- Particularly useful, stable, and mature solution for large enterprises with adequate DevOps resources to manage a heterogeneous infrastructure
- New users may have difficulty since they have to learn Puppet DSL or Ruby, as advanced tasks usually require input from a CLI.
- The installation process lacks adequate error-reporting capabilities.
- Not the best solution available to scale deployments. The DSL code can grow large and complicated at a higher scale.
- Using multiple masters complicates the management process; remote execution can become challenging.
- Support is more focused toward Puppet DSL over pure Ruby versions.
- Lacking a push system, there is no immediate action on changes; the pull process follows a specified schedule for tasks.
Puppet’s approach is designed to address the “persistent and stressful challenge” represented by IT security. The product supports this approach by aiding users in establishing a Standard Operating Environment (SOE) and meeting IT security standards, reporting on and controlling configuration drift, providing change remediation, supporting audit requirements and forensic analysis, and assisting to some extent with security patch management.
However, Puppet users may experience difficulty when scaling their security solutions. For instance, it has a problematic track record when it comes to UID/GID consistency, a problem that increases greatly at scale. Many other issues with Puppet relate to the general difficulties of scaling scripting-related solutions, which can compromise auditability and clarity on what is going on in the environment as a whole.
CentOS, Oracle Linux, Red Hat Enterprise Linux, Scientific Linux, SUSE Linux Enterprise Server, Ubuntu
Free open-source version; Puppet Enterprise, free up to 10 nodes, 11+ notes starts at $100 per node per year; details here.
The Claim: “When configuration is code, DevOps teams work more efficiently, enabling continuous automation across all IT processes.”
Approach: Procedural/Imperative (you create code to specify step-by-step how to achieve a desired end state); requires Chef Client agent on each server you wish to configure; master server required by default (masterless configuration available).
Chef started off as an internal end-to-end server deployment tool for Opscode before it was released as an open-source solution. Chef also uses a client-server architecture and offers configuration in a Ruby DSL using the imperative programming paradigm. Its flexible cloud-infrastructure automation framework allows users to install app
- Infrastructure automation
- Cloud automation
- Automation for DevOps workflow
- Compliance and security management
- Automated workflow for Continuous Delivery
- One of the most flexible solutions for OS and middleware management
- Designed for programmers
- Strong documentation, support, and contributions from an active community
- Very stable, reliable, and mature, especially for large-scale deployments in both public and private environments
- Chef offers hybrid and SaaS solutions for Chef server, analytics, and reporting
- Sequential execution order
- It requires a steep learning curve.
- The initial setup is complicated.
- Push is lacking, so there’s no immediate action on changes; the pull process follows a specified schedule.
- Documentation is spread out and can become difficult to review and follow.
Chef’s security approach promises “Secure and compliant infrastructure by design. Across your entire software delivery lifecycle.” Chef’s security centers around a shift-left mentality, where security and compliance are integrated proactively, earlier in the life cycle. It aims to combat a mindset where operations and InfoSec pros believe compliance policies slow down their respective areas. The product does indeed offer automation solutions to enhance speed and safety.
The primary drawback of Chef’s powerful configuration capabilities comes with the lack of push configuration, which many professionals consider essential when managing operations at scale. This means that if all goes well, updates will be pulled routinely from the server, but changes can take longer to roll out. There is also no web console UI for consistent monitoring and real-time update and management. Chef was created for hard-core coders; otherwise, its steep learning curve could create security gaps as your team gets up to speed.
Multiple, including AIX, FreeBSD, Microsoft Windows, OS X, RHEL/CentOS, Solaris, Ubuntu
Free open-source version; Enterprise Chef, free for up to 5 nodes, 6+ nodes: $120 per month for up to 20 nodes, $300 per month for up to 50 nodes. Prices vary by product; details here.
Ansible (Red Hat)
The Claim: “Simple IT automation that ends repetitive tasks and frees up DevOps teams for more strategic work.”
Approach: Procedural/Imperative (you create code to specify step-by-step how to achieve a desired end state); traditionally “agentless” deployment through SSH, which runs standard on most servers (agent model now available); “masterless” approach relies on pre-existing underlying infrastructure.
As a newer market entry compared to Puppet, Chef, and Salt and acquired in 2015 by Red Hat, Ansible was developed to simplify complex orchestration and configuration management tasks. The platform is written in Python and allows users to script commands in YAML as an imperative programming paradigm. Ansible offers multiple push models to send command modules to nodes via SSH that are executed sequentially. Ansible doesn’t require agents on every system, and modules can reside on any server. A centralized Ansible workstation is commonly used to tunnel commands through multiple Bastion host servers and access machines in a private network.
Ansible Tower Capabilities:
- Streamlined provisioning
- Configuration management
- App deployment
- Automated workflow for Continuous Delivery
- Security and Compliance policy integration into automated processes
- Simplified orchestration
- Easy remote execution and low barrier to entry
- Suitable for environments designed to scale rapidly
- Shares facts between multiple servers so they can query each other
- Powerful orchestration engine; strong focus on areas where others lack, such as zero- downtime rolling updates to multi-tier applications across the cloud
- Easy installation and initial setup
- Fairly easy for new users to learn syntax and workflow
- Sequential execution order
- Supports both push and pull models
- Failure points and performance issues eliminated due to lack of master; faster agentless deployment and communication vs. master-agent model
- High security with SSH
- Features increased focus on orchestration over configuration management.
- SSH communication slows down in scaled environments.
- It requires root SSH access and a Python interpreter installed on machines, although agents are not required.
- Syntax across scripting components such as playbooks and templates can vary.
- GUI is underdeveloped, with limited features.
- The platform is new and not entirely mature compared to Puppet and Chef.
Ansible views security and compliance as “not special, it’s just another thing to automate.” In other words, using standard Ansible Playbook syntax, you can set firewall rules, lock down users and groups, apply custom security policies, and automate other security functions. This is relatively easy to do, and there are lots of resources online to help you out.
However, as a primarily script-oriented tool, Ansible has limited ability to cope with situations where scripts finish, fail, or encounter an error. Scripting tools, in general, also have the potential to leave gaps in security since they are—by definition—great at following orders but not so great at giving you the bigger picture or identifying if something is missing in your security setup. According to this 2020 security report, “Ansible by design can’t protect itself from malicious nodes.”
Finally, any script-based tool such as Ansible may prove difficult to scale and for controlling the larger number of agents required in an enterprise setup. However, in a smaller organization, this solution may be all you need.
CentOS, Linux (Fedora, Scientific via Extra Packages for Enterprise Linux (EPEL)), others
Basic Tower (self-support) starts at $5,000 per year; Enterprise from $10,000 per year; Premium, $14,000+ per year for 100 nodes each; details here.
Free open-source; free full version up to 10 nodes, $100 to $250 per node per year, depending on support level.
The Claim: “Manage virtual, public, and private cloud VMs with powerful automation and orchestration.”
Approach: Declarative (you specify the desired end state and the tool determines how to achieve that state as efficiently as possible); requires Salt Minion agent on each server you wish to configure; master server required by default (masterless configuration available).
Salt was designed to enable low-latency and high-speed communication for data collection and remote execution in sysadmin environments. The platform is written in Python and uses the push model for executing commands via the SSH protocol. Salt allows parallel execution of multiple commands encrypted via AES and offers both vertical and horizontal scaling. A single master can manage multiple masters, and the peer interface allows users to control multiple agents (minions) directly. In addition to the usual queries from minions, downstream events can also trigger actions from the master. The platform supports both master-agent and decentralized, non-master models. Like Ansible, users can script using YAML templates based on imperative paradigm programming. The built-in remote execution system executes tasks sequentially.
SaltStack Enterprise Capabilities:
- Orchestration and automation for CloudOps
- Automation for ITOps
- Continuous code integration and deployment
- Application monitoring and auto-healing
- DevOps toolchain workflow automation with support for Puppet, Chef, Docker, Jenkins, Git, etc.
- Effective for high scalability and resilient environments
- Easy and straightforward usage, past initial installation and setup
- Strong introspection
- Active community and support
- Feature-rich and consistent YAML syntax across all scripting tasks, with Python providing a low learning curve for developers
- The installation process may not be smooth for new users.
- Documentation is not well managed and is challenging to review.
- Web UI offers limited capabilities and features.
- It is not the best option for OSes other than Linux.
- The platform is new and not entirely mature compared to Puppet and Chef.
SaltStack’s SecOps solutions promise to provide “full-service, closed-loop automation for IT operating system and infrastructure compliance and vulnerability remediation across their on-prem, cloud, or hybrid environments.” The tool promises to let you define custom policies centered around industry-standard compliance profiles like CIS and DISA STIGS, then run continuous detection and autonomous event-driven policy enforcement to flag issues that may arise.
The event-driven nature of SaltStack sets it apart from other solutions profiled here. However, this is also a potential vulnerability. With any event-driven architecture, it’s impossible to anticipate every possible eventuality, and when it comes to security, this means that there are inevitably weaknesses within the system—weaknesses that hackers are likely to discover, while your security team may not.
Linux (many versions), macOS, Unix, Windows
Free open-source; SaltStack Enterprise, $150 per machine per year.
Each platform covered above is aimed at a different user segment within the same target market. DevOps teams investing in configuration management solutions must consider the unique requirements around their workflows to maximize ROI and productivity. The four Infrastructure-as-a-Service tools examined here all offer excellent ways to take control of a large enterprise environment, saving your organization much effort and hassle and reducing days or even weeks of work down to minutes or hours.
However, none of these four are complete in and of themselves. The reality is that most organizations will find themselves using a suite of complementary products that work together. For example, they may use one tool for provisioning, such as Terraform, and one of the above four configuration management tools, along with additional tools like JetPatch, which can provide big-picture insights into critical areas such as patching, vulnerability management, and other mission-critical areas.
For instance, of the four tools surveyed in this post, only Ansible offers a native agentless model, whereas the other three all require background agents running on all managed nodes, a system that can be time-consuming and difficult to set up and maintain.
Also, whether they use a declarative or imperative model, these tools all rely on scripting. And although their manufacturers have tried hard to make the process as clear and intuitive as possible, a scripting approach always creates the potential for mishaps.
While this is possibly acceptable in other areas of configuration management, when it comes to security and compliance, there’s no room to let anything fall through the cracks.
JetPatch: Hand-in-Hand with Your Configuration Management
A modern tool like JetPatch offers a different approach. Designed from the ground up with security, compliance, and vulnerability management in mind, JetPatch is about more than just patching. Because JetPatch keeps an eye on your entire network and all of your endpoints, it serves as a watchtower over your whole organization.
Whenever a security vulnerability is identified, it can intelligently raise an alert and visually walk you through the steps to ensure that it’s remediated as quickly and safely as possible, with the minimum possible downtime.
Beyond this core functionality, JetPatch also keeps an eye on agents within your network to ensure that they don’t get out of control and begin demanding more memory and resources than they truly need. By monitoring endpoint resources, JetPatch can identify agent problems before they become an issue, giving you the power to throttle any process remotely so the agent won’t interfere with the endpoint’s functionality.
JetPatch gives you full control over the entire agent life cycle, from initial installation to final uninstallation, ensuring that no processes or files remain to clutter your endpoints.
Because JetPatch is policy-based, it complements the scripting approach of today’s major configuration management solutions, working hand-in-hand with them to monitor security-policy applications within your organization. Should a discrepancy arise, it will alert you to the exception so you can determine how it should be resolved. And JetPatch provides all this functionality from an easy-to-use single windowpane view that provides full insight and reporting into your entire network.
To select the right configuration management solution that fits your organization, consider its architecture and operational model, features, usability, and support, among other key technical and business aspects. Take a careful look at what pieces are missing from your core configuration management picture and then fill those gaps with modern alternatives like JetPatch to make sure you’re covered against all eventualities.
Image source: https://pixabay.com/en/computer-cloud-datacenter-server-161933/