Let’s get this out of the way: I have no economic interest in any of these cos or projects. My mission today is not to teach you ansible or docker, but rather to force you to [re]think your decision to use chef or puppet.
I’ve been designing big systems for a long time. I’ve automated a metric shit-tonne of stuff. And I used to do some wild stuff on bikes, which qualifies me for pretty much everything else I’ve ever done.
when there’s this much chatter on one or two very specific pieces of technology, you owe it to yourself to research it + figure it out.
pre-07, nearly everyone was using one-off scripts to do everything. Few were documented, almost none were under source control and nearly none were actually well engineered. ’08 - ’11 saw chef + puppet emerge, but these tools quickly took on characteristics of the stuff we were trying to manage w/ them: large, bloated, hard to use
this speaks for itself. run some google trends queries to see for yourself.
This is extraordinary. There were zero measurable queries for ansible and docker together prior to last fall. Today, there are enough that the trend is statistically significant (rated 100) in the sample. That’s nearly a straight line up. Such line. Much straight. Wow.
a reminder: I have no - zero, zilch, nada - economic interest in ansible or docker. On the next few slides I’ll summarize key points why A+D are better. If you see factual errors (i.e. the current versions of x now do y etc), let me know. Like Solomon says, you can package your entire application w/ its dependencies.
Ansible can pull a dockerfile out of git or hg, build it + start it from a single playbook that is easy to read and understand by junior staff. This playbook can be applied to hundreds (or more) systems simultaneously w/ no pre-configuration on the docker hosts.
Here’s where ansible shows its strength: play books are near-english language descriptions of the work you want to do + depend only on a running ssh listener on the target system. You can use playbooks to do really, really useful things w/ docker. Look for ansible’s updates on this.
Say bye-bye to client-server, agent-based arrangements that have tricked you into managing *them*. With docker, you describe the entirety of what you want your system to look like once. It’s your completely self-contained application. Ansible can bootstrap dozens of new containered apps from a single playbook in under 20 lines of description.
Yep. The sys admins are grumbling.
yes, these are real quotes. No, I’m not gonna provide attribution. If you don’t believe these, well… whatever.
as I said earlier, this isn’t an ansible or docker training talk or a tutorial. There’s so much well-written stuff out there already, I wanted to focus today on what no one else was (yet) saying aloud: Chef + Puppet are rearview mirror technologies. There’s a better way.
are you on the edge of your seats yet…?
If I can’t get your product installed + running in under an hour, how in the world am I ever gonna to learn how to actually use it? Running multiple installers that may not even work with each other is a non-starter.
Again, this speaks for itself. Ansible has no client, so yeah.
Installing Ansible is as simple as cloning the repo + sourcing an env script that puts that folder onto your PATH. Then, create an inventory file with the name of at least one of your target systems and that’s it. You’re now ready to run ad-hoc commands that just work.
This isn’t surprising, but it’s worth pointing out: Chef + Puppet both have client-server design paradigms that are simply no longer necessary. If a target box has ssh, it can be orchestrated w/ ansible.
following on from the ssh piece, this means (obv) that ansible is agentless. There’s nothing to install or update on the target systems, ever. When you interact w/ an inventory, the work gets done and its over. Both chef + puppet leave a ton of stuff running everywhere.
Ansible uses state (i.e. installed, removed, running etc) to declare the end-state of the thing we’re touching. This ensures that stuff that doesn’t need to get touched, like an ngnix server that’s already installed, doesn’t get reinstalled. Chef encourages idempotence, but there’s no uniformly used state for recipes.
This is important to folks who don’t already know ruby. This includes, not coincidently, a very large portion of old-school sys admins. They know shell scripts, so that’s what was used. Being able to walk up to ansible + write a playbook w/ no prior lang skills is a big advantage. If you already know or want to learn Ruby, this is a no-op.
yes, yes, yes… what abt docker?
Figuring out what’s on a VM that has been out of your control since you last used it is a nightmare. This is a huge problem in process-lacking enterprises: a VM can + often does have different software on it the next time you use it. Even small changes cause huge ripples. Docker containers that are purpose-built obviate that issue.
Speed matters. If there’s any dispute to this, I’d love to hear the reasons.
I could go on + on + on… but you get the picture. Ansible + Docker represent a big change to how things used to be done. There will be people who refuse to accept this + don’t want you to accept it either. Just remember this…
These are a few of the posts I referenced while writing this talk. There are many more.
do not ask me about the motocross stuff. I hate talking abt that.
They’re easier to use and produce portable & immutable outcomes.
(ssh + LXC + cgroups)
With the advent & quick rise of Docker and
Ansible, engineers can now configure an
environment once, save it into a container
and rapidly reuse that container hundreds
(or thousands) of times without additional
When additional config is necessary, for example
for run-time changes that can't be preset, Ansible
can be used to accomplish this with lightweight
data description files requiring nothing more than
ssh. This can be done either to the container's
dockerfile before it is launched or can be done
inside the container post-launch.
The need for complex client-server-agent
arrangements like those in Chef or Puppet
goes away. Chef and Puppet were great
transition schemes that bridged the config
management gap, but that gap has been firmly
+ completely closed by Docker + Ansible.
But what makes Ansible + Docker’s emergence
an inflection point is what’s also occurring in the
Chef + Puppet user space - right now.
This talk could stop right here.
“I DIDN’T SIGNUP TO MANAGE
MY MANAGEMENT SYSTEM”
“WHY DO I HAVE TO KEEP
UPGRADING THE AGENTS?”
“SPINNING UP VMS TAKES A LOT
OF TIME & ADDS NO VALUE.”
“CAN’T THIS BE RUN ONCE & JUST
WORK EACH TIME I NEED IT?”
“I NEVER DID GET EITHER CHEF
OR PUPPET TO ACTUALLY WORK.”
what people are saying
show me the code
there are 38,000 tutorial results for ansible
and 394,000 tutorial results for docker
….and there are 6 talks here at Gluecon on either ansible or docker or both.
Seek out the data + make an informed decision.
EVERYTHING REQUIRED FOR A
CONTAINER IS IN ITS DOCKER
FILE, ENSURING A BASE STATE
CHEF DOES NOT PRESCRIBE A
BASE STATE. SYSTEMS CAN
DRIFT IF TARGET SYSTEMS ARE
EVEN SLIGHTLY DIFFERENT
DOCKER CONTAINERS SPIN
UP IN < 2 SECONDS. NEED A
CHANGE? BUILD A NEW
VMS TAKE MINUTES TO
If you remember nothing else, remember the next two slides
BLAH, BLAH, BLAH
ANSIBLE IS AGENTLESS
This is a huge, game-changing difference.
ARE IMMUTABLE & REUSABLE.
Build once, run anywhere. Really.
• Why Docker? Why Not Chef? - http://blog.relateiq.com/why-docker-why-not-
• The Walking Skeleton with Docker & Ansible -
• “After 4 years of heavy Chef usage, the infrastructure as code mentality
becomes really tedious.” - http://thechangelog.com/ansible-docker/
• “I've used Puppet for over a year, and prefer @ansible after one afternoon.”
• https://twitter.com/jbminn/favorites - login to twitter to see those