Configuration Management
Finding the tool to fit your needs
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
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)
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
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.”
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
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
Imperative vs Declarative
● Functional● Do this, then this
● Chef● Salt● Ansible
● Object Oriented● Do this and this, as
you see fit
● Puppet● Salt
Domain Specific Languages
● Designed for specific tasks● Not generally useful for other tasks
DSL● Chef● Puppet● Salt
No DSL● Salt● Ansible
Push vs Pull● Server calls client● Immediate remote
execution
● Salt● Ansible
● Client calls server● Non-immediate
remote execution
● Puppet● Chef● Salt
● Puppet● Chef● Salt● Ansible
● Salt● Ansible
Immediate Remote
Execution
ConfigManagement
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
Puppet Examplepackage: { “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”],
}
Chef Examplepackage “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
Salt Examplehttpd:
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
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
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?
