Ansible as a gateway to DevOps in the cloud

5 readers like this.
Sky with clouds and grass

Flickr user: theaucitron (CC BY-SA 2.0)

I have a confession to make—although the word "cloud" is in my job title, there was a time when I used to think it was all buzzwords, hype, and vapor, with no substance. Eventually, Ansible became my gateway to the cloud. In this article, I'll provide an introduction to DevOps with Ansible.

Before Ansible came along, I was a sysadmin, happily deploying bare-metal servers and virtual machines, with each new project requiring its own bespoke infrastructure. Sure, the deployment of the initial operating system was automated with Kickstart, but then came the slew of manual steps to get the servers ready for the application owners. It was a slow process, but I knew when I was done with it, I was handing over a finely tuned system that would run like a champ for years.

I wrote bash scripts for everything, some of which even had proper error checking. I was confident in what I knew and what I did, and saw no reason to change. I was comfortable. Then I started hearing this word more and more from our various vendors: cloud. What did cloud mean? Ask a dozen people to define it, and you'd get a dozen different answers. Without a concrete notion of what it was, my team of sysadmins and I chalked it up as nonsense.

Gateway to the cloud

Then I started using Ansible. The connection might not seem obvious right away, but it worked out as a bit of a gateway to the cloud. When I first started using Ansible, to me it was a glorified bash+SSH wrapper, but in a good way. The playbook syntax was easy to understand and fun to write. Over time, I translated all those crusty old bash scripts into elegant, error-checking, idempotent Ansible playbooks.

Junk like this:

#!/bin/bash

user_exists=$(grep -c davidc /etc/passwd)
if [[ $user_exists -eq 0 ]]; then
useradd -m -s /bin/bash davidc
echo PASSWORD | passwd davidc --stdin
fi

Becomes a clean one-liner:

- user: name=davidc shell=/bin/bash password=$6$
rounds=656000$47cizb4beOY.uB9c$w
TlFCrP62g/M0.UNl0IHLOOw.fuWvJwCQLLS
8UeruI1T/tbAdKd8Wzhsy7SandrOtROwBn7F
BZHTaZcZciXMd

I no longer had to SCP (secure copy) a bunch of scripts around every time a new server was deployed. From one central spot, I could suddenly manage and automate thousands of servers. I scaled up! And without the typical eye twitching that comes every time a sysadmin is asked to install "Yet Another 3rd Party Agent."

The above is an example using the user module. Ansible has a ton of modules. I realized I had just scratched the surface by only using Ansible as a bash replacement. As I went deeper with Ansible, I found modules to deploy a virtual machine (VM) on libvirt, containers in Kubernetes, and Nova instances in OpenStack. The latter two particularly piqued my interest. Ansible made it incredibly easily to start treating my data center as code, and presented a friendly interface to orchestrate emerging technologies likes containers and cloud instances. All of which is made possible because these platforms expose their services via openly accessible API endpoints.

And that's when it dawned on me: The cloud isn't really that vaporized at all. When you get to the heart of it, a cloud is just a bunch of services, joining together to provide a platform to do work. It takes the Unix philosophy that I know and love to a much grander scale: Write programs that do one thing and do it well. Make a call to a network service to provision a software-defined port, another to the compute service to get a container or a virtual machine, pull some code from Git and out pops a running application. "Cloud" and "DevOps" was now demystified. Microservices? Wrap cat(5) in an API and you've written your first microservice. Through Ansible, I made sense of it all.

Building a personal DevOps test lab

I've always believed that to be a great sysadmin—to expand your knowledge and keep current—one should run some form of personal network. That network should have a purpose, to keep it interesting to the admin. In my case, I'm a big record collector. Since university, I've run some form of a LAMP stack with my homebrew records database. That project started out in PHP and MySQL. In the event of a rebuild, it was a day-long exercise to provision new VMs, pull the (hopefully) latest database and code backup, and cross my fingers that it wasn't too broken. With what I learned through Ansible, I decided to rebuild the whole thing. I'd do it over, with DevOps in mind, so when application owners started asking for it, I knew what I was talking about.

In the process I learned a lot. I accidentally stumbled upon what I dub the three pillars of DevOps:

  • Source control
  • Orchestration
  • The platform

If you can get these three things working together, you'll be a rockstar. The beauty of open source is that there are many different implementations of these pillars, and you're free to choose whichever stack works best for you.

For my experiment, I chose Git, Ansible, and Kubernetes. In one repository, the code for my application lives alongside the code for my infrastructure, with Ansible acting as the glue to keep it all together. There is a Docker file in there and all the configuration files for my Kubernetes environment (volumes, pods, routes, etc.). Through an Ansible playbook, the container image for the app is built and pushed to the registry. Further Ansible tasks take care of deploying the pods and supporting infrastructure onto a Kubernetes cluster.

When a Git commit is made to the repo, a Git post-commit hook triggers an Ansible play to take advantage of the ReplicationController object in Kubernetes. The play tears down the existing application pod, forcing a rebuild of the container with the latest code. A cut-rate continuous integration/continuous deployment platform! It may not be enterprise-ready, but it's great for a lab and learning about all this new technology.

And I'm not done yet. Now I get to learn all about Jenkins and automated testing. Ansible continues to evolve as well. The Ansible-container module was recently announced, and I'm eager to see how that can improve my workflow.

So to all the skeptical sysadmins out there that think the "cloud" is nothing but buzzwords and hype, I encourage you dive in and try it for yourself. Try out Ansible, and savor that moment of satisfaction when you deploy your first full stack from a single command line.

David Critch will go into more detail about DevOps with Ansible and Kubernetes in his ContainerCon talk on August 23rd in Toronto.

User profile image.
David cut his teeth as a system administrator at BlackBerry (nee RIM) before entering the exciting and dynamic world of consulting. As a senior cloud consultant with the "Cloud Infrastructure Practice" at Red Hat, David has designed and delivered cloud solutions for many Fortune 500 companies, based around Red Hat's emerging tech products such as Red Hat OpenStack and OpenShift.

3 Comments

I really enjoyed this article. What a great perspective on a journey to automated tooling out of utility and usefulness. I think IT staff sometimes adopt technology because it's trendy, not because it's particularly useful to them at that point in time.

You also illustrate the value of iteration in adoption: "Okay, now that I've done 'x' with this tool, what else can it do?". ie, Build a meaningful and manageable foundation, then iterate as concepts sink in and results start to metastasize.

One of my favourite things about Ansible is that it's very curmudgeon friendly. For sysadmins who've been using shells and SSH effectively for years, I've found Ansible a vastly easier transition than its competitors.

Thanks David. Very nicely presented. I learned lots of things.

so...ansible was your gateway 'drug' to the cloud, eh? :-) Great writeup!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.