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 ; 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.