LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
This presentation was originally given by Joseph Hall, SaltStack senior engineer, at the combined Montreal Python and DevOps Montreal meet up on April 14, 2014. Here is the talk abstract: In ye olde days of web, a company might manage a handful of servers, each manually and frequently tuned and re-tuned to the company's needs. Those days are gone. Server farms now dominate, and it is no longer reasonable to manage individual servers by hand. Various configuration management tools have stepped in to help the modern engineer, but which to choose? It is not an easy question, and canned pitches from sales people are unlikely to take into account all of your variables. This talk will attempt to discuss The Big Four objectively, and from what angles they approach the task at hand.
Configuration Management - Finding the tool to fit your needs
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
● I have only used Puppet and Salt
● All of the projects discussed are excellent,
with talented teams behind them
● Mark Burgess, 1993
● Designed for automated configuration and
management of large-scale computer
● Configuration and usage seen by many to be
● Currently in third iteration (CFEngine 3)
● Luke Kanies, 2005
● Unhappy with CFEngine 2, Luke built Puppet
as a next-generation config management
● Designed to be easier to configure and use
● Uses a Ruby-like DSL
● 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.”
● Thomas Hatch, 2011
● Originally designed for remote execution
● Config management added later
● Designed for speed, flexibility, ease of use,
● Based on data, not DSLs
● Michael DeHaan, 2012
● Requires no agents on the remote machine,
except for sshd
● Designed for ad hoc task execution and
● Designed with simplicity in mind
Imperative vs Declarative
● Do this, then this
● Object Oriented
● Do this and this, as
you see fit
Domain Specific Languages
● Designed for specific tasks
● Not generally useful for other tasks
Push vs Pull
● Server calls client
● Immediate remote
● Client calls server
● Use one machine to execute commands on
● Config management is already a type of
● SSH (alone) is non-automated
● Queueing mechanisms are often used for
template “httpd” do
source “httpd.conf.erb” # stored in /templates/ in the current cookbook
service “apache2” do
action [:start, :enable]
- hosts: all
- 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?