Lesson 17: Configuration Management

Homepage

Content

Slides

Video

Warning

This lesson is under construction. Learn from it at your own risk. If you have any feedback, please fill out our General Feedback Survey.

Configuration Management

“Configuration management is the process of standardizing resource configurations and enforcing their state across IT infrastructure in an automated yet agile manner.”

• Puppet Labs

user { 'audience':
    ensure  => present,
}

Short History of CM

Concept: Infrastructure as Code

Infrastructure as code is the act of describing what you want your servers to look like once, and using that to provision many machines to look the same.

It turns pets into cattle. (more on this difference later)

• CM enables System Operation to define their infrastructure in code.
• Install packages, configure software, start/stop services.
• Ensure/guarantee a specific state of a machine.
• Provide history of changes for a system.
• Repeatable way of rebuilding a system.
• Orchestrate a cluster of services together.

Pull vs Push Models

Pull Model

• When the server being provisioned (node) runs an agent (daemon) that asks a central authority (master) if/when it has any updates that it should run.
• Requires a daemon to be installed on all machines and a central authority to be setup.
• Scales well, difficult to manage.

Push Model

• A central server contacts the nodes and sends updates as they are needed.
• When a change is made to the infrastructure (code) each node is alerted of this and they run the changes.
• Simple to manage and setup (usually uses prevalent SSH protocol), not scalable.

Tools

Puppet

• Uses custom CM Language.
• Primary Push Model.
• Widely Adopted.
• Very stable.
• Difficult to get setup.

[ Puppet Site ]

Chef

• Primarily Push Model.
• Code files are Ruby.
• Widely Adopted.
• Difficult to setup.

[ Chef Site ]

CFEngine

• Fast at execution, slow at adaptation.
• Very old.
• Stable.

[ CFEngine Site ]

Ansible

• Easy to use.
• Easy to setup.
• Does not scale well.

[ Ansible Site ]

SaltStack

• Easy to use.
• Hard to get started.

[ SaltStack Site ]

Delcaration Configuration

packages [nginx, python, vim]
    state installed
    update true

service nginx
    state enabled
    alert service myapp_daemon

Chef Example

• Install apache and start the service
• Configuration is called a ‘recipe’
• Written as pure Ruby code

package "apache" do
  package_name "httpd"
  action :install
end

service "apache" do
  action [:enable, :start]
end

Note

Since chef uses Ruby you can do loops and other cool Ruby-isms in your configuration management. This can be a gift and a curse.

Puppet Example

• Install apache and start the service
• Configuration is called a ‘manifest’
• Puppet DSL based on Ruby

package { "apache":
  name    => "httpd",
  ensure  => present,
}

service { "apache":
  name    => "apache",
  ensure  => running,
  enable  => true,
  require => Package["apache"],
}

Note

Since Puppet designed it’s own language for Configuration managent you are more limited in what you can express with Puppet, but this isn’t always a bad thing. It’s feature rich and can do pretty much anything Chef can.

Ansible Example

• Install apache and start the service
• Configuration is called a ‘playbook’
• Uses YAML file format for configuration

- hosts: all
  tasks:

    - name: Install Apache
      yum:
        name: httpd
        state: present

    - name: Start Apache Service
      service:
        name: httpd
        state: running
        enabled: yes

Note

Ansible’s langauge is Yaml, which is basically JSON but easier to read and write. This is similar to Puppet in it limits the possible functionality, but again: these tools all achieve the same result, they just get there in different ways.

TODO: Use Ansible to Provision localhost

$ pip install ansible

Further Reading