Docker ansible-make-chef-puppet-unnecessary-minnihan

Editor's Notes

• #2: 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.
• #3: 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.
• #4: 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.
• #5: 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
• #6: this speaks for itself. run some google trends queries to see for yourself.
• #7: 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.
• #10: 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.
• #11: 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.
• #12: 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.
• #13: 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.
• #14: Yep. The sys admins are grumbling.
• #15: yes, these are real quotes. No, I’m not gonna provide attribution. If you don’t believe these, well… whatever.
• #16: 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.
• #17: are you on the edge of your seats yet…?
• #18: 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.
• #19: Again, this speaks for itself. Ansible has no client, so yeah.
• #20: 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.
• #21: 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.
• #22: 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.
• #23: 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.
• #24: 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.
• #25: yes, yes, yes… what abt docker?
• #26: 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.
• #27: Speed matters. If there’s any dispute to this, I’d love to hear the reasons.
• #28: 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…
• #29: Point #1
• #30: Point #2
• #31: These are a few of the posts I referenced while writing this talk. There are many more.
• #32: do not ask me about the motocross stuff. I hate talking abt that.