Using Ansible, we’ve been able to cut down certain processes from 17 hours to 3 minutes. -BRANDEN FAULLS

Image for post
Image for post

Ansible is an open-source software provisioning, configuration management, and application-deployment tool enabling infrastructure as code. It runs on many Unix-like systems and can configure both Unix-like systems as well as Microsoft Windows. It includes its own declarative language to describe system configuration. Ansible was written by Michael DeHaan and acquired by Red Hat in 2015. Ansible is agentless, temporarily connecting remotely via SSH or Windows Remote Management (allowing remote PowerShell execution) to do its tasks.

Unlike most configuration-management software, Ansible does not require a single controlling machine where orchestration begins. Ansible works against multiple systems in your infrastructure by selecting portions of Ansible’s inventory, stored as edit-able, version-able ASCII text files. Not only is this inventory configurable, but you can also use multiple inventory files at the same time and pull inventory from dynamic or cloud sources or different formats (YAML, INI, etc.). Any machine with Ansible utilities installed can leverage a set of files/directories to orchestrate other nodes. The absence of a central-server requirement greatly simplifies disaster-recovery planning. Nodes are managed by this controlling machine — typically over SSH. The controlling machine describes the location of nodes through its inventory. Sensitive data can be stored in encrypted files using Ansible Vault since 2014. In contrast with other popular configuration-management software — such as Chef, Puppet, and CFEngine — Ansible uses an agentless architecture, with Ansible software not normally running or even installed on the controlled node. Instead, Ansible orchestrates a node by installing and running modules on the node temporarily via SSH. For the duration of an orchestration task, a process running the module communicates with the controlling machine with a JSON-based protocol via its standard input and output. When Ansible is not managing a node, it does not consume resources on the node because no daemons are executing or software installed.

Image for post
Image for post

The design goals of Ansible include:

  • Minimal in nature. Management systems should not impose additional dependencies on the environment.
  • Consistent. With Ansible one should be able to create consistent environments.
  • Secure. Ansible does not deploy agents to nodes. Only OpenSSH and Python are required on the managed nodes.
  • Highly reliable. When carefully written, an Ansible playbook can be idempotent, to prevent unexpected side-effects on the managed systems. It is entirely possible to have a poorly written playbook that is not idempotent.
  • Minimal learning required. Playbooks use an easy and descriptive language based on YAML and Jinja templates.

Modules are mostly standalone and can be written in a standard scripting language (such as Python, Perl, Ruby, Bash, etc.). One of the guiding properties of modules is idempotency, which means that even if an operation is repeated multiple times (e.g., upon recovery from an outage), it will always place the system into the same state.

The Inventory is a description of the nodes that can be accessed by Ansible. By default, the Inventory is described by a configuration file, in INI or YAML format, whose default location is in /etc/ansible/hosts. The configuration file lists either the IP address or hostname of each node that is accessible by Ansible. In addition, nodes can be assigned to groups.

An example inventory:[webservers]

This configuration file specifies three nodes: the first node is specified by an IP address and the latter two nodes are specified by hostnames. Additionally, the latter two nodes are grouped under the webservers group.

Ansible can also use a custom Dynamic Inventory script, which can dynamically pull data from a different system, and supports groups of groups.

Playbooks are YAML files that express configurations, deployment, and orchestration in Ansible, and allow Ansible to perform operations on managed nodes. Each Playbook maps a group of hosts to a set of roles. Each role is represented by calls to Ansible tasks.

Image for post
Image for post

Ansible seamlessly unites workflow orchestration with configuration management, provisioning, and application deployment in one easy-to-use and deploy platform.

Regardless of where you start with Ansible, you’ll find our simple, powerful, and agentless automation platform has the capabilities to solve your most challenging problems.

There are many other IT automation tools available, including more mature ones like Puppet and Chef, so why would you choose Ansible? The main reason is simplicity. Michael DeHaan, the creator of Ansible, already had a lot of experience with other configuration management tools when he decided to develop a new one. He said that he wanted “a tool that you could not use for six months, come back to, and still remember.”

DeHaan accomplished this by using YAML, a simple configuration language. Puppet and Chef, on the other hand, use Ruby, which is more difficult to learn. This makes Ansible especially appealing to system administrators.

DeHaan also simplified Ansible deployment by making it agentless. That is, instead of having to install an agent on every system you want to manage (as you have to do with Puppet and Chef), Ansible just requires that systems have Python (on Linux servers) or PowerShell (on Windows servers) and SSH.

Ansible can automate IT environments whether they are hosted on traditional bare metal servers, virtualization platforms, or in the cloud. It can also automate the configuration of a wide range of systems and devices such as databases, storage devices, networks, firewalls, and many others.

The best part is that you don’t even need to know the commands used to accomplish a particular task. You just need to specify what state you want the system to be in and Ansible will take care of it. For example, to ensure that your web servers are running the latest version of Apache, you could use a playbook and Ansible would handle the details.

Image for post
Image for post

The ongoing digital transformation coupled with the growing popularity of cloud means companies are now more dependent on dynamic, all-in-one tools that can solve multiple problems across a host of platforms.

Further, today’s organizations are looking for ways to ease into automation while also striving toward higher levels of customer satisfaction. For many organizations, the open source platform Ansible is the answer to these modern-day challenges. Here are a few examples of companies successfully implementing an Ansible migration.


Hootsuite is a social media management system used by businesses and organizations. It allows the execution of social media campaigns on a variety of networks from a secure dashboard. Hootsuite is popular among Fortune 1000 companies.

The main challenge facing Hootsuite was the lack of repeatability. This made automating Hootsuite’s infrastructure a challenge, and Hootsuite were also facing difficulties in application deployment.

To resolve this, Hootsuite introduced Ansible core. This allowed Hootsuite to build servers from scratch and enabled repeatability. In the future, Hootsuite plans to implement an Ansible migration of its app deployment and possibly in ad hoc production server management.

Since performing their Ansible migration, Hootsuite says ops and devs ‘feel safer’. Additionally, Ansible allows developers to repeatedly test server builds on a local level until the team can be sure they work.

Hootsuite intends to use Ansible in many other ways, and as Beier Cai, Director of Technology, Hootsuite Media Inc., explains, “In the beginning, I didn’t realize Ansible is good for orchestration as well but found it out quickly and I really loved it as it beats competitors right there.”


Amelco is a UK-based company that develops software solutions for the betting industry and financial betting markets. The business was looking for a way to deploy its applications efficiently across its hundreds of different environments, and it also sought to limit downtime. To do this, Amelco performed an Ansible migration to an agentless automation framework. This reduced the complexities it faced with the deployment, operations and the upgrade of applications over a range of contrasting locations, while also using one simplified language.

In addition, by introducing the Ansible and Ansible Tower, Amelco has successfully automated its application deployments. Other benefits include reduced complexity and continuous delivery, along with speed solution delivery.

Further benefits include:

  • “Faster time to deployment for its bespoke and modular client solutions, resulting in speedier time to market and higher customer satisfaction”.
  • “A simplified and repeatable deployment process, leveraging true multi-tier, multi-step orchestration that minimized the complex dependencies of heterogeneous environments,”.


Based in Stockholm, Lifesum is a digital health platform that encourages users to lead a healthier, more balanced lifestyle. Lifesum has proved hugely successful throughout Europe, reaching over 6 million downloads so far.

Lifesum’s platform uses a host of applications, in addition to a joint back end API, and it bases its infrastructure on AWS. Lifesum was looking for a simplified yet robust tool to allow configuration management, application deployment, and server provisioning.

Prior to introducing Ansible, Lifesum had used another tool but found provisioning and managing different environments a challenge.

Lifesum started their Ansible migration in 2014. It started implementing Ansible straight away and has used it in several major areas. First, Lifesum used Ansible playbooks “to automatically spin up virtual development machines with Vagrant”.

In the case study, Michal Gasek, SYSOPS Engineer/DBA at Lifesum also notes that Lifesum’s goal, “[is] to ensure that everyone had exactly the same working environment as we deploy our applications regularly. Three months later all our environments, from developer’s laptops to production instances on Amazon, [are] fully Ansible managed.”

Gasek continues, “We use AWS Auto Scaling and pre-bake Amazon AMI images with Ansible provisioning playbooks. When EC2 instances are launched by Auto Scaling, Ansible, triggered by cloud-init, runs provisioning playbooks, once again ensuring up-to-date configuration changes are applied, and pulling the latest application versions from repositories. Ansible has helped us to automate, significantly simplify, and speed up the process of dynamic resources scaling”.

Gasek adds that Ansible stood out because of its ‘power and simplicity’. Gasek also highlights how Ansible has enabled developers to concentrate on building ‘great product features’, rather than solving common problems like inconsistencies and misconfiguration.

With today’s demand for automation, consistency, and the move towards the cloud, companies from all sectors are adopting easy-to-use tools that enable them to achieve these goals and overcome complexities. These three success stories show how an Ansible migration is the ideal solution for automating organizations’ modern technology challenges, while also performing an essential role in app deployment and improving responsiveness.

Thank You for reading!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store