Ansible for Smarter and Efficient Automation

This is my first attempt in writing a tech article based on a project I had worked on. This article explores in detail Ansible, a configuration management tool and how it is powerful for devOps. The article aims to explore Ansible, its use cases and includes my analysis of using it to solv


  Ansible is amongst the latest buzzwords in devops and automation. It has gained popularity in a short term owing to its simplicity as a tool and being user friendly. Before we dive into detail about Ansible, it is worthwhile to understand the background and necessity for the emergence of tools like Ansible. Alongside Ansible, are other popular options like Chef, Puppet, Salt etc. For the purpose of this article, only ansible will be explored in detail. As with any configuration management tools, the key feature they provide is to enable faster and efficient automation. Pausing for a moment, back in the days when these tools were not yet developed, it was quite a painstaking effort to update the configurations of servers. Especially in the domain of IT administrators or system admins, it posed challenges when they had to upgrade the servers to any new configurations or revert configurations as part of maintenances. As in other domains, whenever the cycle of app releases was happening at a fast paced rate, it was difficult to keep up with the deployments in the same manner. When these tools were developed, they dominated the domains proving to be an efficient solution. Before we talk about Ansible in detail, understanding a few key features will lay a good foundation. 

Advantages Features of Ansible

  • Agentless 
    • Ansible is only required to be installed in the controller machine from where one would access remote nodes. This solves the problem of having to install in a wide fleet of servers/nodes.
  • Handles application deployments, and updating configurations for systems on the fly.
  • Used in multi-node orchestrations, powerful to manage multiple nodes in parallel
  • Helps in simple to complex ad-hoc execution of tasks
  • Easy integration 
    • Support with major tools and platforms such as; Docker, Kubernetes, SQL DB etc


Design Architecture

   To understand what the architecture comprises and different aspects let's understand the architecture briefly.


  • Controller Node 
    • This is the machine form which you will access nodes remotely. For this purpose, it is sufficient if ansible is only installed in the controller node. Target nodes need not have ansible installed in them. 
  • Inventory
    • This is the file which will have all access related information, methods and credentials stored
  • Tasks
    • These denote the procedure of various tasks that needs to be executed
  • Playbooks
    • Hosts a bunch of tasks in the order they need to be executed on the remote nodes
  • Modules
    • Helps with automation; provides of about 400 + modules which are packages to accomplish a task
    • For example: there are modules that help with copying files over, connection to databases etc.
  • Tower
    • UI Dashboard with REST API


Analysis - Case Study

 For the analysis, I will be elaborating in detail how I used Ansible to solve a problem at work. Being part of a team which is involved in system testing and automation, there are often times when we need to analyze failures in a timely manner. This may be crucial while trying to identify software bugs or system/environment related issues. For a long time we have been posed with the challenge of performing these tasks in a timely and efficient manner. Often, we spend so many tedious hours grabbing specific process logs and blackboxes which help us identify the problems. This could seem like a simple task, but when we have many numbers of such systems to look into, it becomes a bit daunting and a draining experience for someone on call to trace and debug the issue further. 


 Another such commonly faced problem was lending systems like modems or networking components to various other developers or internal teams. The nature of borrowing resources, at times, results in having to maintain all of them every week when the resources are returned. Many a times, developers patch test softwares with certain builds, or change configurations for temporary testing and return without the changes being reverted. This has posed a serious concern for the team, to get our hands dirty in fixing and restoring the lab for future uses.


 We had to come up with a solution which will reduce the hours spent every sprint cycle in mundane and monotonous and repetitive work. Also, a tool which is user friendly such that even developers or integrators borrowing the tool can fix some issues by themselves and which will not pose a learning curve in order for the team to use it.

Ansible as a solution

 After a solid research and understanding of Ansible, its architecture and design principles, we decided to develop a tool that would be based of Ansible. Owing to the key features discussed above, it was indeed an efficient solution for the team. A few of the reasons for the design choice were:

  • Agentless - Being agentless the team did not have to worry about convincing other teams since it did not involve any installation on remote servers our team was not managing.
  • Minimal Learning Curve - The playbooks are written in YAML, and being a markup language it was easy to comprehend and alter the playbooks as needed.
  • Support for Modules - Almost any automation task can be performed with the help of standard modules provided by Ansible. There are wide possible options to choose from.
  • Easy integration with UI - Ansible provides interface with Tower which is UI and coupled with REST API

Learnings Future work

The exposure in learning to use Ansible, has paved more interest in experimenting solutions along the same line for more of our problems. As a team, we have transitioned from spending more hours manually,  to debugging those in a shorter time span but also efficiently automating this testcase which will be used across by many teams. Ansible has definitely proven to be a worthwhile toolkit to have in any developer’s toolbelt. As an extension, we are currently working on implementing the Tower integration for much easier scheduling of tasks and execution. This way the tool will be able to interact with other tools currently in pipeline, making it much more dynamic and versatile. 



  1. Image (Header)
  2. Architecture