Red Hat’s Ansible 2.0 brings new power to DevOps
13 January 2016 | 0
Ansible, the Python-powered IT automation and configuration framework that recently became a Red Hat property, officially released its 2.0 version today. Its new features satisfy two needs that are sometimes deeply contradictory: make the product more powerful and useful, but do not break compatibility with the already large and growing culture of Ansible scripts and modules.
The Ansible scripts known as Playbooks have long lacked a mechanism to group together tasks in logical units or elegantly perform error handling. Version 2.0 can do so thanks to blocks. Actions described within a block only take place if a given set of conditions are met.
Blocks also provide a way to perform exception handling, so that if something goes wrong during the course of a block, it can be handled. Existing scrips that do not use blocks will run as-is, but legacy scripts could only implement the same kind of functionality by way of a lot of boilerplate code.
A new addition called strategies controls how playbooks execute, with the default for existing scripts being a “linear” strategy — e.g., all hosts have to finish one task before any of them can begin the next one. A “serial” strategy, meanwhile, ensures one group of hosts finishes its work before another group can begin, and another strategy named “free” allows all hosts to run independently of each other. Strategies are not hard-wired into Ansible, either; they can be defined by plug-ins.
Ansible 2.0 also gains almost 100 new add-ons, called modules. Most of them cover long-standing data centre stalwarts (Amazon EC2 or VMware, for instance), but newly minted ones are for newer technologies like OpenStack and Docker. Modules for 2.0 also now cover managing Microsoft Windows systems, including subsystems like Internet Information Server.
This is the biggest release of Ansible since its acquisition by Red Hat, but so far Red Hat has had little direct influence on Ansible’s evolution — another way to ensure its existing culture of scripts and modules remains useful. If Red Hat deepens its integration with Ansible, it’ll most likely be by releasing its own modules for such integration, as it already has modules for managing Red Hat software channels and Red Hat Network registration. (Ansible Tower, an enterprise management system for Ansible, has already received a point release under Red Hat’s brand, although again Red Hat’s influence there seems to have been minimal.)
When James Cammarata, Ansible’s director of core engineering, outlined Ansible 2.0’s feature set last year — albeit before Red Hat’s acquisition was announced — he noted how one of the big missions after 2.0’s release will be “taking the beta sticker” off Microsoft Windows support.
Serdar Yegulalp, IDG News Service