Configuration Management - Finding the tool to fit your needs

download Configuration Management - Finding the tool to fit your needs

of 17

  • date post

  • Category


  • view

  • download


Embed Size (px)


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.

Transcript of Configuration Management - Finding the tool to fit your needs

  • Configuration Management Finding the tool to fit your needs
  • Disclosures and Caveats Im biased (I work for SaltStack) Many of my views do not reflect SaltStacks 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 Puppets 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 Config Management
  • 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 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], }
  • 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
  • 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
  • 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?