17
Configuration Management Finding the tool to fit your needs

Configuration Management - Finding the tool to fit your needs

Embed Size (px)

DESCRIPTION

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.

Citation preview

Page 1: Configuration Management - Finding the tool to fit your needs

Configuration Management

Finding the tool to fit your needs

Page 2: 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

Page 3: Configuration Management - Finding the tool to fit your needs

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)

Page 4: Configuration Management - Finding the tool to fit your needs

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

Page 5: Configuration Management - Finding the tool to fit your needs

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.”

Page 6: Configuration Management - Finding the tool to fit your needs

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

Page 7: Configuration Management - Finding the tool to fit your needs

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

Page 8: Configuration Management - Finding the tool to fit your needs

Imperative vs Declarative

● Functional● Do this, then this

● Chef● Salt● Ansible

● Object Oriented● Do this and this, as

you see fit

● Puppet● Salt

Page 9: Configuration Management - Finding the tool to fit your needs

Domain Specific Languages

● Designed for specific tasks● Not generally useful for other tasks

DSL● Chef● Puppet● Salt

No DSL● Salt● Ansible

Page 10: Configuration Management - Finding the tool to fit your needs

Push vs Pull● Server calls client● Immediate remote

execution

● Salt● Ansible

● Client calls server● Non-immediate

remote execution

● Puppet● Chef● Salt

Page 11: Configuration Management - Finding the tool to fit your needs

● Puppet● Chef● Salt● Ansible

● Salt● Ansible

Immediate Remote

Execution

ConfigManagement

Page 12: Configuration Management - Finding the tool to fit your needs

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

Page 13: Configuration Management - Finding the tool to fit your needs

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”],

}

Page 14: Configuration Management - Finding the tool to fit your needs

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

Page 15: Configuration Management - Finding the tool to fit your needs

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

Page 16: Configuration Management - Finding the tool to fit your needs

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

Page 17: Configuration Management - Finding the tool to fit your needs

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?