The document discusses various configuration management tools, including CFEngine, Puppet, Chef, Salt, and Ansible, highlighting their development timelines and unique features. It compares different paradigms such as imperative vs. declarative approaches, domain-specific languages, and push vs. pull execution models. Ultimately, it emphasizes that choosing the right tool depends on specific user needs and existing infrastructure.

1. Configuration
Management
Finding the tool to fit your needs

2. Disclosures and Caveats
● I’m biased (I work for SaltStack)
● Many of my views do not reflect SaltStack’s
views
● I have only used Puppet and Salt
● All of the projects discussed are excellent,
with talented teams behind them

3. Timeline: CFEngine
● Mark Burgess, 1993
● Designed for automated configuration and
management of large-scale computer
systems
● Configuration and usage seen by many to be
arcane
● Currently in third iteration (CFEngine 3)

4. Timeline: Puppet
● Luke Kanies, 2005
● Unhappy with CFEngine 2, Luke built Puppet
as a next-generation config management
tool
● Designed to be easier to configure and use
than CFEngine
● Uses a Ruby-like DSL

5. Timeline: Chef
● Adam Jacobs, 2009
● Adam was unhappy with Puppet’s non-
deterministic (by default) ordering
● Uses a very Ruby-like DSL
● Designed to mix ops with development
● “Infrastructure as code.”

6. Timeline: Salt
● Thomas Hatch, 2011
● Originally designed for remote execution
● Config management added later
● Designed for speed, flexibility, ease of use,
scale
● Based on data, not DSLs

7. Timeline: Ansible
● Michael DeHaan, 2012
● Requires no agents on the remote machine,
except for sshd
● Designed for ad hoc task execution and
config managment
● Designed with simplicity in mind

8. Imperative vs Declarative
● Functional
● Do this, then this
● Chef
● Salt
● Ansible
● Object Oriented
● Do this and this, as
you see fit
● Puppet
● Salt

9. Domain Specific Languages
● Designed for specific tasks
● Not generally useful for other tasks
DSL
● Chef
● Puppet
● Salt
No DSL
● Salt
● Ansible

10. Push vs Pull
● Server calls client
● Immediate remote
execution
● Salt
● Ansible
● Client calls server
● Non-immediate
remote execution
● Puppet
● Chef
● Salt

11. ● Puppet
● Chef
● Salt
● Ansible
● Salt
● Ansible
Immediate
Remote
Execution
Config
Management

12. Remote Execution
● Use one machine to execute commands on
another machine
● Config management is already a type of
remote execution
● SSH (alone) is non-automated
● Queueing mechanisms are often used for
remote execution

13. Puppet Example
package: { “httpd”:
ensure => “installed”,
}
service: { “httpd”:
ensure => “running”,
enable => true,
require => Package[“httpd”],
subscribe => File[“httpd”],
}
file: { “httpd”:
path => “/etc/httpd/conf/httpd.conf”,
content => template(“httpd/httpd.conf.erb”), #/etc/puppetlabs/puppet/modules/httpd/templates/httpd.conf.erb,
require => Package[“httpd”],
}

14. Chef Example
package “httpd”
template “httpd” do
source “httpd.conf.erb” # stored in /templates/ in the current cookbook
path “/etc/httpd/conf/httpd.conf”
action :create
end
service “apache2” do
action [:start, :enable]
end

15. Salt Example
httpd:
pkg:
- install
service:
- running
- enable: True
- requires:
- file: httpd
file:
- managed
- name: /etc/httpd/conf/httpd.conf
- source: salt://httpd/httpd.conf # stored in /srv/salt/httpd/httpd.conf
- requires:
- pkg: httpd

16. Ansible Example
- hosts: all
tasks:
- name: 1. Install Apache
yum: name=httpd state=present
- name: 2. Copy Apache Config
template: src=httpd.conf.j2 dest=/etc/httpd/conf/httpd.conf
- name: 3. Start Apache Service
service: name=httpd state=running enabled=yes
# httpd.conf is stored in the /templates/ directory for that role

17. Which one is for me?
● It depends
○ Do you have legacy CM code?
○ Do you need immediate remote execution?
○ Are you planning to use this layer programmatically?
○ Is a hybrid solution more appropriate for you?
○ Which one feels right?