Tuning Ansible

Ansible Configuration Management

Article from ADMIN 45/2018

By Chris Binnie

A number of widely adopted configuration management tools have risen and fallen in popularity since the DevOps craze first appeared. In this article, we look at a few tweaks that can help you configure Ansible for the best performance.

Special Thanks: This article was made possible by support from Linux Professional Institute

Among configuration management tools, the most well known are Puppet, Chef, and Ansible, the latter of which was acquired by Linux powerhouse Red Hat at the end of 2015. Years ago I worked with Puppet on a large server estate and embraced its ability to automate away much of the daily sweat and grind associated with running hundreds of servers. At times, however (and this applies to all configuration management software to one degree or another), hitting the big, red execute button induced a level of stress because the configuration did not always behave as expected. With lots of testing and a healthy amount of experience, however, it is possible to build up enough trust to run these tools on your production estates.

My tool of choice these days is without question Ansible. Be warned, though, that it is a contentious topic, mainly because engineers (never mind businesses) have invested heavily in one particular tool and tend to extol its virtues vociferously over others. The company behind the mighty Puppet, for example, has been around since 2005, and that is enough time to invest in a massive number of manifests (Puppet scripts) that might be so tightly integrated with your production environment that the mere thought of extricating them is painful. In this article, I am going to explore getting the best of Ansible, in terms of performance and maintaining your sanity. To achieve this, I will be using a couple of simple plugins that are bundled with Ansible; if you then plan on using Ansible for idempotency (more later

...

Use Express-Checkout link below to read the full article (PDF).