Ansible: Being the Glue So You Don't Have To

September 22, 2014 by Bill Nottingham


A modern IT infrastructure is a complex beast. In 1995 a website often consisted of a single physical server serving static content and a few CGI scripts. Today a standard web site can include any combination of reverse proxies, load balancers, application servers, middleware layers, databases, local and remote assets, all running spread across multiple geographically diverse data centers.  Some of the components in use may not even be hosted inside your infrastructure at all.  And that's just the production environment - you can have multiple environments for developing and staging configurations.

In the old days, if you wanted to change the site, you just edited the code on the server, or if you were really advanced, checked a new version out of CVS, and then tell the users to reload.  Now you take the frontend machine out of the load balancer, remove the app server from the application pool, stop the services, deploy new backend code, deploy new frontend code, restart the services, test the connections, and re-add them to the application pools and load-balancers, checking every step along the way.

Whereas before an administrator's procedure involved merely scripting a few linear steps on a single system, now any task can involve the administrator taking 5, 10, or 20 disparate systems with disparate interfaces and gluing them together into complex procedures. And no one wants to be turned into glue.

That's where Ansible comes in. Ansible's core strength is as a glue factor to connect and orchestrate disparate parts of your infrastructure. It tries to be agnostic as possible, and work with whatever you have in your infrastructure.

You've got some CentOS, some Red Hat, some Ubuntu, even some AIX? Doesn't matter - if you can access it via SSH (and even in some cases if you can't) Ansible can connect it all.  Whether your application utilizes a Drupal CMS, a full Java stack from Tomcat through JBoss and Cassandra, or an Elasticsearch cluster for analyzing your data, Ansible Galaxy has roles for deploying it. Got instances on bare metal, running in VMware, in Docker containers, and in Amazon?  Ansible's inventory support can pull your inventory from all of them.

And with this power, you can create complex tasks easily. Need to ensure all your systems are patched for a vulnerability? Ansible can do that. Need to deploy a virtual private cloud and deploy a multi-zone LAMP stack to it with rolling updates? Ansible can do that.

Once you've got your tasks Ansibilized, then you can move to Tower. Take the playbooks you’ve created to deploy your application, and delegate them to the operations or dev team without actually giving them the SSH keys.  Take the playbooks you’ve created to provision a customer or stage environment, and use Tower’s variable prompting to provision new ones with just a few clicks. Take the results of your build jobs, and use Tower’s REST API to automatically kick off tests and deployments when builds complete. And any time a task fails, you can go and see where, when, and why it failed, all without having to log onto the machine in question.

Don’t spend your days being infrastructure glue. Let Ansible and Tower be the glue holding your infrastructure together for you, leaving you to do what you’re actually supposed to be doing.

IT Automation, Infrastructure


Bill Nottingham

Bill Nottingham is the Director of Product at Ansible. He came to Ansible from Red Hat, where he spent 15+ years building and architecting Red Hat’s Linux products. His days are spent chatting with users and customers about Ansible and Tower. He can be found on twitter at @bill_nottingham, and occasionally doing a very poor impersonation of a soccer player.

rss-icon  RSS Feed

Ansible Tower by Red Hat
Ansible In-Depth Whitepaper
Ansible Tower by Red Hat
Learn About Ansible Tower