Ansible has exploded in popularity thanks to rapid adoption and widespread community contributions, resulting in projects such as Ransack, a custom Ansible application developed by Rackspace.
At AnsibleFest NYC, Rackspace DevOps Engineer Paul Durivage explained why Rackspace is transitioning away from shell scripts and to Ansible through its Ransack server configuration tool. It was only the second public presentation on Ransack.
“We all started with shell scripts, and it was really messy, so we moved onto that configuration management software known as… Let’s call it ‘Cook,’” he said during his talk.
(Related: Ansible unveils Ansible Tower 2.0 at AnsibleFest NYC)
The steep learning curve and complexity of Chef became a major obstacle for Rackspace before turning to Ansible, which the company then refitted into Ransack to better automate its hybrid cloud platform.
“We had some tools that offered the ability to log into servers and run scripts, but we didn’t like that methodology because it scales really poorly,” Durivage told SD Times. “Shell scripts are all so different. I saw the need once we discovered Ansible to use that tool chain to do highly parallel work with Python modules that force consistency. It allows us to scale to an incredible number of servers to manage at any one time, meaning that one guy can do a massive amount of work with the least amount of effort possible.”
Rackspace’s Paul Durivage demonstrates Ransack
Ransack, which has been in development for about six months, pairs custom dynamic inventory scripts with internal Rackspace APIs, executing at runtime to pull down information about machines. Using a self-documenting command-line interface optimized for Rackspace cloud workflows, Ransack communicates with external APIs to gather Ansible-specific data and serialize it back to JSON.
Ransack is considered production-ready at version 1.0, though at the moment only internal Rackspace engineers have access as they train to use the application. Durivage and his DevOps team are currently working on developing Ransack-as-a-service to automate deployments without installation.
“The next step a little down the road is the evolution of modules, so adding more Ansible core modules to Ransack, then we’re going to start looking toward developing an API layer as middleware,” he said. “The Ransack-as-a-service offering is very near, though. It’s really the future of the whole project.”
Ansible and Docker
A prevalent theme throughout the conference was the relationship between Ansible and another open-source project that’s gone viral in the past six months: Docker.
Ransack uses virtual machines inside Docker to solve its issues with Python packaging. During initial installation, Ransack assumptions about packaging led to a 300-line batch script installing across all machines, but distributing the application through Docker VMs and appliances solved that problem.
“Docker was a natural fit,” Durivage said. “Once we realized appliances were the right way to distribute the application, the natural evolution of that is to go to lightweight containers. People are totally uninterested in installing a virtual machine. Not only are they installing a hypervisor, which is heavy, but they’re installing a virtual machine that’s heavy. Containers are the evolution of that. Once you realize you can deploy it with containers, you can deploy it anywhere.”
(Related: Docker grows to harbor innovation)
Ansible and Docker’s relationship extends far beyond Ransack. Patrick Galbraith of the HP Advanced Technology Group gave a presentation at AnsibleFest called “Ansible and Docker: Container management made easy,” in which he described combining Ansible and Docker in the HP Moonshot software-defined server.
“We’re looking for something that’s two steps ahead of the current technology,” he told SD Times. “Both Ansible and Docker seem to fit that bill. Ansible is a really clean way of provisioning systems and having control over what you have deployed out there. Docker has done so much work for virtual machines, and virtual machines are really slow for testing and packing software.”
Galbraith demonstrated how Docker’s dynamic inventory plug-in gives the ability to manage elastic resources in Ansible and provide a JSON output that serves as an inventory list. Using the Docker images and facts modules, he explained how Ansible can avoid “dependency hell” to deploy write-once-run-anywhere applications, using the dynamic inventory plug-in as the “awesomesauce” of Ansible in Docker.
“I’ve worked on Chef, I’ve worked on Salt (which is similar to Ansible in how it uses XAML and Python files for configuration), but Ansible takes that a step further,” Galbraith said. “You’re dealing with something that doesn’t require a server to run, where you don’t need to set up minions. All of them are good systems and each has its place, but for this particular technology, extending Ansible to the Docker fact module is a really great tool.”
A jumping-off point for automating configuration
Rackspace isn’t the only company taking Ansible and making it their own. In only a year, Ansible has become the most popular IT automation project and the fifth most popular overall project on GitHub, and AnsibleFest included presentations from ThoughtWorks, Twitter and others introducing new concepts and projects inspired by Ansible.
A presentation from Itamar Hassin, project manager at ThoughtWorks, explored the idea of using Ansible for monitor-driven infrastructure development. His presentation was founded on the premise of testing and coding Ansible scripts the same way we treat application code, because Ansible’s automated process assures scalability and consistent testing.
Using Ansible, Hassin believed that test-driven development can combine specification, implementation and verification into one process that unifies delivery into behavior-driven development.
Another interesting presentation came from Steve Salevan, a site-reliability engineer at Twitter. Salevan explained how Twitter has used Ansible to develop Pants, a build system written in Ansible’s native Python that compiles and assembles code and dependencies into a single deployable binary.
“Ansible provided means by which you could specify tasks,” said Salevan. “It provided idioms you could follow. As we know about cloud infrastructure, there are a lot of don’t’s that Ansible does. [Pants] assembles virtual code into a Python Executable or PEX file, which is portable between hosts and makes it quick and easy for developers and users to start using Ansible.”
The best part about Pants is the tagline, though: “For covering your deployable parts.”
