Ansible vs Puppet: Configuration Management Compared

Ansible vs Puppet at a Glance

Ansible: Push-Based, Agentless

Ansible connects to hosts via SSH, runs tasks, and disconnects. No software to install on managed nodes.

# Ansible playbook
---
- name: Configure web server
  hosts: webservers
  become: true
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: Start nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Pros:

• Zero agent installation or maintenance
• Easy to start — pip install and go
• YAML is readable by anyone
• Great for ad-hoc tasks and orchestration

Cons:

• No continuous enforcement (runs only when triggered)
• Push model requires network access to all hosts
• Performance can degrade at very large scale without AWX

Puppet: Pull-Based, Agent-Driven

Puppet agents run on every managed node, checking in with Puppet Server every 30 minutes to enforce desired state.

# Puppet manifest
class webserver {
  package { 'nginx':
    ensure => installed,
  }

  service { 'nginx':
    ensure => running,
    enable => true,
    require => Package['nginx'],
  }
}

node 'web1.example.com' {
  include webserver
}

Pros:

• Continuous enforcement — drift is auto-corrected every 30 min
• Excellent reporting and compliance dashboards
• Scales to tens of thousands of nodes
• Strong type system prevents errors

Cons:

• Agent required on every node
• Puppet Server infrastructure to maintain
• Puppet DSL learning curve
• Less suitable for one-off orchestration

Key Differences

Getting Started

Ansible — install, create inventory, write YAML, run:

pip install ansible
ansible-playbook playbook.yml

Puppet — install Puppet Server, install agents on all nodes, write manifests, wait for agent check-in:

# On server
puppetserver install
# On each node
puppet agent install
puppet agent -t  # First run

Language

Ansible uses YAML (everyone knows it):

- name: Create user
  ansible.builtin.user:
    name: deploy
    groups: sudo
    shell: /bin/bash

Puppet uses its own DSL:

user { 'deploy':
  ensure => present,
  groups => ['sudo'],
  shell  => '/bin/bash',
}

Drift Management

Puppet automatically corrects drift — if someone manually changes a config, Puppet reverts it on the next agent run (every 30 min).

Ansible only enforces state when you run a playbook. To match Puppet's behavior, you'd schedule regular ansible-playbook runs via cron or AWX.

When to Choose Ansible

• Small to medium infrastructure (< 5,000 nodes)
• Mixed environments (Linux, Windows, network devices, cloud)
• Teams that prefer YAML over learning a DSL
• Need ad-hoc task execution
• Multi-step orchestration workflows
• You want to start automating quickly

When to Choose Puppet

• Large, homogeneous infrastructure (> 5,000 nodes)
• Strict compliance requirements (continuous enforcement)
• Need built-in reporting and audit trails
• Dedicated infrastructure team to manage Puppet Server
• Long-running infrastructure (years of consistent state)

Can You Use Both?

Yes. Some organizations use:

• Puppet for baseline OS configuration (continuous enforcement)
• Ansible for application deployment and orchestration (on-demand)

Related Articles

• Ansible Tutorial for Beginners — Complete getting started guide
• How to Install Ansible — Installation on all platforms
• Ansible Training — Courses and certifications
• Ansible Dry Run — Test playbooks safely
• Ansible Facts — Gather system info
• Ansible Vault — Encrypt secrets
• Ansible Error Handling — Handle failures

Explore 800+ Ansible tutorials with practical examples on AnsibleByExample.