beawolf - Fotolia
Ansible is getting serious about scalability and cloud deployments with version 2.0. The open source Ansible project grew rapidly in early days, with a slew of projects by different contributors. The first major release of Ansible since Red Hat acquired the configuration management and automation tool company required a back-end re-engineering to make all these contributions scale, and includes new features and capabilities.
The release of Ansible 2.0 took about a year to develop and to make as backward-compatible as possible, given the complete core restructuring, according to Tim Cramer, senior director of engineering for Red Hat.
It's natural to assume that Red Hat, which acquired Ansible in October 2015, didn't play a large role in this restructuring effort, said Andrew Smith, analyst at Technology Business Research (TBR) in Hampton, N.H. He expects the open source giant will give Ansible a degree of freedom in its product roadmap in the future as well.
Scale, integration factors in restructuring
Re-engineering was a necessary step, but there's more to be done to open up Ansible and develop the task automation tool roadmap with the community, according to Serge van Ginderachter, owner of Ginsys, an independent services company working on the ops side of IT in Belgium. He has contributed to Ansible for more than three years.
Ansible Tower, the dashboard monitoring component, is currently closed-source. It provides a layer of control on top of Ansible configuration management for roles-based access, auditability with change history tracking and other features. However, Ansible's core developers too closely control the product's roadmap, argued van Ginderachter. Ansible could convert to Red Hat's open source and paid model, wherein the tool is freely available and users can purchase the enterprise-tailored, supported package.
Indeed, bringing such things open source is "the Red Hat way," according to Cramer.
Ansible 2.0 includes more than 150 new modules from the community and the product's core engineers for users to work with VMware vSphere and ESXi, and cloud architectures in Amazon Web Services, OpenStack, Microsoft Azure, Google Cloud Platform and Microsoft Windows Server.
The Red Hat acquisition gives Ansible inroads into the Windows architecture, Cramer noted, adding that "everyone has trouble automating Windows stuff."
Microsoft Azure integration should be the next frontier for competitive open source configuration management tools, suggested TBR's Smith.
While Ansible works on data center servers, hosted servers and cloud instances, the 2.0 release highlights cloud tie-ins to meet IT roadmaps of private, hybrid and multicloud deployments, Cramer said.
Other improvements in Ansible 2.0 include task blocks for playbooks, better error discovery and reporting to pinpoint problem causes, new execution modes that enable nonsequential updates across a server farm, plug-ins to communicate Playbook information, and improved portability across infrastructure setups.
Ansible in the toolchain
Ansible's appeal is in its simplicity. Systems administrators that write shell scripts can automate tasks equally as well as developers who know sophisticated programming languages.
The push-based model is "great for deploying applications," said Stein Inge Morisbak, manager at Bekk Consulting AS, which works with large private and public sector enterprises in Norway. Learning was simple, and the agentless nature means he can use Ansible without root access to the infrastructure. Morisbak uses the latest version, 188.8.131.52, for most Ansible tasks, though he rolled back to a 1.9x version due to complications with deep directories in a playbook on the new release.
"Ansible was my introduction to a more formally automated approach of system operations," van Ginderachter said.
The difficulty isn't with an administrator creating a script to repeat a task, he said, but conceptually modeling tasks and managing complex IT systems. He said he wants better ways to perform lifecycle management of the deploy code in automation tools such as Ansible.
Since the user doesn't need to learn a specific language for Ansible, the tool can be shared across an IT organization. Similar to competitive DevOps tools Chef and Puppet, Ansible integrates with the continuous integration tool Jenkins, enabling a continuous integration or continuous deployment flow, although it can be used alone. Large enterprises typically integrate Ansible with business process management tools, such as those from ServiceNow, HEAT or BMC Remedy. Ansible already integrates well with Red Hat because of close ties with OpenStack, TBR's Smith said.
"When I am using cloud-based platforms, I find Ansible very useful for configuring servers, mostly [HashiCorp] Packer images for immutability," Morisbak said. He uses Ansible with HashiCorp's Terraform for configuring infrastructure, but is open to just Ansible if it could complete the tasks.
For van Ginderachter, it's easy to use Ansible without other tools.
"It was easy to start simply and quickly, whilst it still allows [the automation] to grow to more large setups," he said. He mainly uses Ansible 1.9 for stability, occasionally testing version 2.0. Van Ginderachter said he plans to wait for version 2.0.1 or 2.0.2 before adopting the new version more broadly.
The Ansible 2.0 release coincides with an update to the Ansible Galaxy user interface. Ansible Galaxy, launched in 2014, allows users to share content. To date, Ansible reports 4,000 community-contributed roles available in Galaxy, with close to 1,200 authors listed on the site. The Chef Supermarket, a similar community repository for competitive configuration automation tool Chef, includes just over 2,700 cookbooks, with more than 66,000 contributors.
To augment systems management and provisioning tools on the ops side, most large enterprises will choose one configuration management tool -- typically Chef, Puppet, Salt or Ansible, Smith said. Smith noted that Chef and Puppet both market an enterprise-ready platform, in addition to the community-controlled open source tool set. And these competitors are also pursuing Microsoft Azure cloud management capabilities.
What the future holds
As part of Red Hat, Ansible could develop strong ties into Satellite in future releases for change orchestration and accurate inventory assessment, and into CloudForms for cloud management.
However, Smith doesn't expect Red Hat to subsume Ansible into an existing product, such as CloudForms.
"That configuration management layer is a core value proposition for Red Hat moving forward, so it might leave Ansible with a good amount of freedom to pursue its roadmap," he said. With Satellite and Ansible, Red Hat can incubate new ideas and pick innovations that resonate with customers most.
Van Ginderachter's wish list for future releases includes a smarter inventory, as well as ways to manage versions of roles and playbooks, with consideration of variables for specific roles, or hosts in one environment in an intuitive and scalable way. Red Hat did not comment on specifics of existing portfolio tie-ins with Ansible on the roadmap.
Morisbak said he expects to see even more modules for managing cloud infrastructure in Ansible's future releases and looks forward to the volume of modules in Ansible 2.0. Topping his wish list is an easier way to automate configuration of RESTful services. He said he prefers now to provision servers while they are not running, except when deploying new versions of applications. In the future, he said he plans to build images totally offline or use Docker for immutability also for applications.
Meredith Courtemanche is the senior site editor for SearchDataCenter and has covered semiconductor and IT topics since 2006. You can reach her on Twitter: @DataCenterTT.
Red Hat OpenShift adds isolation on public clouds
Bring back system programmers for cloud, automation
Strengthen each link in your DevOps toolchain