Configuration Management Overview

What is configuration management?

• A way to manage configuration
• Tools: Puppet, Ansible, Saltstack, Chef


Example: Configure a web server

Stage 1 (beginner)

◇ install packages
◇ edit config files
◇ restart services
◇ fiddle around + troubleshoot
◇ document 90%
◇ one server takes X time, two servers take 2X time -- linear

Stage 2 (intermediate)

◇ keep track of shell history
◇ paste commands into a script
◇ do some basic conditional logic -- if this worked, then do this
◇ paste config files in

Stage 3 (dev ops)

◇ make image of perfect web server
◇ clone + run scripts to configure stuff at deployment
◇ hope that things stay cool
◇ more scripts to manage stuff when it goes wrong
◇ when stuff changes, create a new base image, slowly push out to servers in batches
◇ pray, swear, troubleshoot, fix, repeat

Stage 4 (state of the art)

◇ config management! Configure STATE, instead of PROCESS
◇ 1 or 100 servers...all the same
◇ which servers are still running the old version of package xyz?
◇ on which servers has this config file been changed?
◇ did the hacker add evil stuff in the web server config? In the crontab?
◇ you are not flying blind after deployment anymore


Why Configuration Management?

1. Automation
◇ repeat tasks

2. Documentation
◇ forced to be fairly simple
◇ how does something work? Let's check!
◇ easy-to-explore abstraction of a process

3. Enforcement
◇ see what's changed, enforce compliance
◇ no more 'stragglers' -- huge problem in large deployments


What problems does this solve?

• system imaging is fine for a while, but then MANAGING those systems is tough
• automation
• variance in large deployments -- some old, some new, some vulnerable, some configured differently (auditing)
• no way to quickly see what state everyone is in
• idempotence -- most aim to be safer than scripts
• 'infrastructure as code' -- makes versioning, testing, and deployment easier


For the 'small' Sysadmin?

• documentation shuffle, docs get stale
• you forget how you did stuff, since you're not deploying 10-15 servers/containers a day
• one abstraction level above shell scripts -- STATE, not PROCESS
• automate stuff (the 'large deployment' features are less important here)
• document stuff (no more awkward notes -- the Lisp ideal of "the code IS the documentation" is achieved)