Ansible as a gateway to DevOps in the cloud

This article was originally published on opensource.com.

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.


Connect with Red Hat Consulting, Training, Certification

Learn more about Red Hat Consulting
Learn more about Red Hat Training
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Training on Twitter
Like Red Hat Training on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn
Creative Commons License

Build your next cloud-based PaaS in under an hour

This post was originally published on the Red Hat Developers Blog.

The charter of Open Innovation Labs is to help our customers accelerate application development and realize the latest advancements in software delivery, by providing skills, mentoring, and tools. Some of the challenges I frequently hear from customers are those around Platform as a Service (PaaS) environment provisioning and configuration. This article is first in the series of articles that guide you through installation configuration and usage of the Red Hat Open Container Project (OCP) on Amazon Web Services (AWS).

Training As An Investment

In an effort to save expenses, enterprises think they can avoid training their teams. How does skimping on training truly impact the performance of the individual and the health of the overall organization? For IT leaders, these are critical questions that they must consider. What is the cost of a team without expertise?

Automating the provisioning and configuration of Red Hat Mobile Application Platform

In the second part of this two-part series that is focused on applying contemporary application development practices like continuous delivery and DevOps to mobile application development, I will demonstrate how to use Ansible to fully automate the deployment of a Mobile Application Platform, running on OpenShift Enterprise Container Platform. I will then walk through a tutorial of how to use Jenkins to create a continuous delivery pipeline for doing mobile app development.

A step-by-step tutorial for continuous integration with Jenkins on a Red Hat Mobile Native Android application: Part 2

In part one of our series, we established the process around creating an Android application using Red Hat’s Mobile Application Platform and adding unit tests. Now, we’ll walk through how to use Jenkins for continuous integration on this app.

A step-by-step tutorial for continuous integration with Jenkins for a Red Hat Mobile Native Android application: Part 1

The dramatic influx of mobile application development has driven many new innovations that make it easier than ever to create compelling, flexible, and secure  applications. This two-part series details my work done at Red Hat’s Open Innovation Labs to capture these mobile innovations in a useful, repeatable way. In part one of this two-part series, I break down the steps to create and unit test a native android application using Red Hat’s Mobile Application Platform. In part two, I show how Jenkins can be used to automate  continuous integration and unit testing of that Mobile app.

Applying Continuous Delivery and DevOps Automation to Mobile Application Development

Red Hat Open Innovation Labs is a new offering committed to helping our customers accelerate innovation, and create the solutions that meet their business challenges. As mobile application development becomes an increasingly important function within companies, customers have been asking us for advice on how to best apply the principles of continuous delivery and DevOps to their mobile application development.This was particularly exciting to me. Red Hat already has great technology to support enterprise mobile. And at Labs, we have a fantastic platform for accelerating application delivery. Together, we had a great opportunity to combine our efforts and build a phenomenal, turnkey solution.