A talk given at ICCC about getting started with Configuration Management, in a vendor-agnostic voice.

1. Getting Started
with
Configuration Management
gabriel m schuyler | @gabe_sky
Gabe
I'm Gabe. I'm a Professional Services Puppet.
Enough rope to hang yourself -- "get started"
Sysadmin -- or at least understand the work.
Hands: Have CM? Have R/W? Actually written to it? Nope.

2. Sven
The perfect cup of coffee.
We've all accidentally made one, but could we answer "how'd you
do that?"
He has concise and specific instructions.
Allows for variants. e.g. strong, smooth, chocolatey.
It has measurable results. How does it taste?
Systems
How do you make "one more like this?"
It starts with basic resources like packages, files, services, users and
groups.
Specialized resources like mount points, zfs volumes, IIS application
pools.
The different way they're set up per machine, environment, location.
So, how do we manage this?
Well, people ask me, "how does Puppet compare to the competition"
...

3. .sh
.ps1
.bak
.gabe-pre-ntp-move20141027
w2k-dev-golden.template
The actual competition:
Your terrible, uncommented scripts with a bus number of one. (or
even zero.)
Copying a backup of the file you're about to hand edit.
Golden images at point-in-time, but which don't maintain a desired
state.
Chad
They pair me with a junior, so they can learn the desired states.
I need more "front-end web servers." (Role)
So that's "base security, common tools and mounts, web
stuff." (Profile)
And "base security" means ssh, motd, xinetd, &c (Components)
Spelunking
The answers to his questions are all over the place.
Spread across wikis, scripts, post-its.
Can you just copy what a similar machine has?
Tribal knowledge and ad-hoc procedures don't transfer well.
It needs to be repeatable, and give me confidence that I truly have
"one more like that one."

4. Connecting
Plus how do these pieces work together?
Understanding the dependencies make us senior.
Happily, automated CM, illuminates those dependencies, by
specifying it in code.
Chad can see the connections through what's sometimes called
"executable documentation."
Hammering
Tooling, used wrong, says "when all I have is a hammer, every
problem is a nail."
The flip side is "hammers work on all kinds of nails." (Or, you know,
try to use a shoe/stapler.)
Automated CM gets us all using the same language to describe the
infrastructure.
It's easier to hire more "Puppet people," than to hire more "sven's io
tuning script written in Go because he wanted to try it people."
Hammers
Pick any tool.
Use "learning" pages, and virtual machines, to decide.
It's the practice that counts, not the hammer.

5. Build
Now we're getting on the road to repeatable infrastructure.
"make one more" doesn't require experts.
Autoscaling, system rebuilds, OS upgrades.
The seniors can concentrate on real stuff, not just fires.
Okay, so let's talk about the practices that are going to make you
happy.
Truth
To keep your sanity, it's useful to have a "single source of truth."
Need to look something up .. you know were. (Not wiki, scripts,
Sven's head, repeat.)
Change it in one spot, it propagates.

6. History
("You know Elphaba, where I come from, we believe all sorts of things
that aren't true. We call it 'history.'")
Any automated CM tool will require source control by its own nature.
Borrow what your developers use, or whatever those learning pages/
systems were using.
"What changed?" Now you'll know who, when, and what have
changed. Just like developers' code.
Futures
Different environments can be applying the desired state from
different points in (source code) time.
Production uses particular package versions, config files, &c.
Dev uses xyz. And production will use xyz on Tuesday.
Now
All automated CM has some function for discovery and
orchestration.
Heartbleed, shellshock .. what version of bash do my production
front-end web servers have right now?
Upgrade all non-production machines xyz right now.
Now, be careful. The temptation with these tools is to just run
scripts, ad-hoc, like ssh in a for loop.
Instead, have the discipline to update your CM, and then kick off

7. These are the biggest benefits of using automated CM.
I have a clear idea of how to replicate any type of system, here.
And because we're speaking a common language, Chad can see
how.
When things break, I can easily answer "what changed?" Just like
the developers do.
So where do I start?
Ready
Start to scribble down the simplest, most common, boring
configuration things that annoy you now.
Dig up your host-naming scheme. This will help identify the different
"types" of systems you have.
Identify the tribal, wiki pages, script repositories.
Set
Set up source code control and "social coding" tools. (Think: code
review before PR merging.)
Set permissions and "ownership" of systems to start, but aim to
later remove these at cumbaya time.
Agree on a style guide. Involve all departments.
Add your chosen CM tool to provisioning and start-up scripts. (noop
is always a possibility, if you're timid.)

8. Toddle
Set up your logging/reporting for maximum visibility. (Visibility, not
verbosity)
Don't try to learn two things at once. Learn your CM system first,
then configure wacky things.
Start by picking one small, well-known component to automate.
Search for pre-existing code on the forge/kitchen/hades.
Repeat -- relax, you can always run in noop mode.
Cheer
Everyone loves metrics, especially managers. (Remember ITIL? Ick.)
Be prepared with metrics and stories. "This used to waste X hours
per week of my time." "This used to need Sven's help to get done."
"Now we can reproduce production issues from any point in time,
and show diffs!" "Now, the developers are testing their code, on
systems that look exactly like production."
Reflect
To sum up. Make a great cup of coffee.
Care about the quality of the final product.
Write concise and measurable instructions, in a common language.
Any type of system is easy to reproduce without magic, or experts.
Version history of our uniform language, says what changed when.
And in order to succeed, we're going to need to have measurable
results.

9. Q
"Ask me your questions, bridge-keeper, I'm not afraid!"
Possible demos: `puppet resource` of package and service .. then
add to site.pp for a node.
`puppet module search ntp` then add to a node and run agent, then
change servers =>, run agent again.
Getting Started
with
Configuration Management
gabriel m schuyler | @gabe_sky