Empowering Windows Deployment Pipelines with Ansible Tower

April 12, 2016 by Cody Rucks

We love stories about how Ansible Tower has solved problems and made work easier. When we heard that CareerBuilder was using Tower in a Windows environment, we had to know more. Special thanks to Cody Rucks from CareerBuilder for sharing his story about Ansible Tower.


At CareerBuilder we are focused on building out a full stack solution that will allow developers to continuously deploy their applications. Not only do we want them to be able to deploy quickly, but we want consistency and automation throughout the entire process. Ansible Tower has become a huge part of our final end solution. In this post we will discuss how we are using Ansible Tower to connect our various products and steps and truly be able to deploy applications in the cloud utilizing DevOps methodologies.

Why Ansible Tower?

In November 2015, our team set out to find the best solution for our needs. We tested several different products and vendors ranging from the most buzz-worthy to the most obscure and ended up selecting Ansible Tower at the end. Ansible Tower seemed to provide all the things that we needed it to do. They key takeaways we had that made us select Ansible Tower were:

  • Friendly and easy-to-use web interface

  • Able to tie into LDAP and manage access

  • A rich API

  • Active community

  • Provisioning callbacks

  • Agentless approach

Whatever product we chose, we needed to ensure would be easy to use for not only developers, but also operations. We needed to ensure that we could control access to the various teams projects and inventories, but also be able to adjust as time goes on. An API for connecting to other tools was needed greatly; Ansible Tower delivers as the entire web interface is API driven. Finally, we didn’t want a product where we couldn’t research on our own – Ansible has great support, but having an active community empowers users on both development and operations teams to drive forward with innovation and use.

Connecting the Dots

At CareerBuilder, we are already leveraging the cloud and working on a new application architecture. With that in mind, we needed to be able to connect the various pieces and have a entire process that made sense and was also modular; this is where Ansible Tower comes into play. As many know, there are lots of tools that “work” with Windows without actually fully working. Ansible thankfully supports Windows well.

We were already utilizing three key technologies; TeamCity for code testing, GitHub for code repository, and Amazon Web Services for the instances themselves. There was always an issue with actually gluing these technologies together. Ansible Tower allows us to solve that by becoming the glue – or the worker, if you will – of our entire process. With that out of the way, let’s dive right into how we are accomplishing this.

How it Works

Currently, for each of our applications, we have a Project, Inventory and then five key Job Templates designated within Tower. What are these for? I’m glad you are asked!

Projects: The Projects are how you connect your SCM to Tower in order to allow the execution of your playbooks. Each application has it’s own Project so that we can have some segregation in playbooks for our own sanity at the moment.

Inventories: Inventories are… inventories! This is where we connect in Tower to AWS; each application has its own inventory so we know that when Job Templates are run, we can be certain the right one ran on the right inventory.

Job Templates: As mentioned above, these run against the inventory. The key here is that we have segregated these out into 5 distinct functions: three staging Job Templates (Deploy Code Parallel, Deploy Code Serially and Full Configuration – Create AMI) and then two production Job Templates (Deploy Code Parallel and Deploy Code Serially).

This all sounds great, but what are we actually doing to make it work? Well, as mentioned earlier, the API was very important to us and is really the key to allowing this to happen. So, let’s go over what happens as a developer checks in their code.

  1. A developer creates a new feature within a feature branch and merges it back into the Develop branch. This pull request calls TeamCity using a git webhook to start its workflow.

  2. TeamCity kicks off its workflow of testing; This includes building out a single instance in AWS for live application testing. During this process, the AWS instance is instructed (via the User-Data script) to connect back to Ansible Tower using the provisioning callback URL.

  3. Ansible Tower performs its job – it executes all the playbooks needed to bring up a fully built instance so that TeamCity can perform tests on the application directly. All of this is possible thanks to the API that Tower provides.

  4. TeamCity passes or fails unit tests on the code, and other testing on the application running on the server. If it passes, we go ahead and build out a new AMI that will be used later (This accounts for security patching.). If less than 30 days, TeamCity destroys the test instance and calls Ansible Tower via the Job Template API. This  Job Template pushes updated application code directly to each instance within the targeted ASG using a 50% rolling deployment method.

Ansible Tower is what is allowing us to not only build Auto-Scaling Groups and their needed configurations, but also deploy the code and get instances up and running. All of this works because of Tower’s rich API-- Inventories and Job Templates can all have actions performed via API. This is what empowers us to be able to fully automate the process.

What’s the Full Process Look Like?

Below is our high level mapped out process. There are a lot of in-depth discussions that could be had around this, but overall the process is as described above. Any time an instance is created, we connect back to Ansible Tower for all of our configurations. On average, our code pushes are taking 45 seconds and a full deployment that includes testing and touching every step takes around 12 minutes – all of this obviously varies on the code.


What’s Next?

As we continue to improve, we are looking into making our playbooks even more agnostic and potentially being able to have a core set of Job Templates and Projects across multiple applications. There are also other products in AWS that we are looking to integrate as well and with Tower being so open and extensible, we see this as being pretty straightforward.


Windows, Ansible Tower


Cody Rucks

Cody Rucks has worked for CareerBuilder for 10 years and is currently a DevOps Engineer. Along with his counterparts, he's helping push DevOps for the internal Development and Operations teams through the utilization of tools such as Ansible Tower, Slack, AWS, and more. He has worked with a varying amount of products and tools (as well as languages). Some of the most prominent tools and languages: Ansible Tower, CloudStack, VMware, vCommander, LogicMonitor, Slack, AWS, PowerShell, Python, Java, and C#.

rss-icon  RSS Feed

Ansible Tower by Red Hat
Learn About Ansible Tower