Why and How We Use Ansible
In the last couple of years we have done a great deal of work to simplify and automate OpenIO SDS deployment and configuration management. To do this, we have leveraged Ansible, which has been a real boon to our work.
What is Ansible?
Ansible automates and simplifies repetitive, complex, and tedious operations. Everybody likes it because it brings huge time savings when we install packages or configure large numbers of servers.
Its architecture is simple and effective. It works by connecting to your nodes and pushing small programs to them. These programs make the system comply with a desired state, and, when they have finished their tasks, they are deleted.
Ansible works over SSH and doesn’t require any daemons, special servers, or libraries to work. A text editor and a command line tool are usually enough to get your work done.
You simply describe your infrastructure in a text file (INI) and then all the information about the desired state of these machines are organized in playbooks. It is able to gather node information (such as IP addresses or Operating System details) into so-called “facts”, which help with the selective and automated provisioning of different configurations on the platform. All of this with a language that is very human readable without the need to write code or declaring explicit relationships.
In our experience there are at least three advantages that make Ansible our favorite automation tool.
- It is agentless. You do not need to install additional software on your server nodes. This helps keep the installation clean while ensuring that there are no conflicts with our software.
- Playbooks are easy to read and edit. They are mostly written in YAML, and this is a great advantage when compared to other solutions, such as Puppet.
- It is written in Python, a very popular programming language that is familiar to our engineers, making it easy to extend.
There is actually a fourth reason: it is open source. But this is a pretty common characteristic for this type of tool, so it is not a major differentiator.
When compared with similar tools, Ansible offers us another great benefit. It is declarative and not procedural. This means that you write a description of the final state of the machine, and it takes all the necessary steps to fulfill that description. By working this way, playbooks can be applied several times and only necessary steps are applied, with no side effects.
Ansible has been a huge investment for us. We come from other automation tools (Puppet was the most used for quite some time), but we needed a much more flexible solution, capable of matsching the flexibility of OpenIO SDS, which itself can be deployed in several ways and on the most heterogenous environments.
When I talk about ease of use, I really mean it. This is an Ansible playbook necessary to configure a three-node OpenIO cluster. It is easy to read and edit to reflect your cluster needs. With Ansible, we overcame all the limits imposed by other tools and it allowed us to build simple playbooks that can run for one as well as for hundreds of nodes, dramatically speeding up deployments while making sure that nobody tampered with single nodes.
Now Ansible is our standard tool not only to deploy the SDS core, but also our WebUI, OIO-FS and all upcoming options.
As you can find out on our documentation website, the installation process for OpenIO SDS is based on Ansible, and this is the same script we use when we work with our customers on their clusters. In fact, you’ll find all the playbooks we use, and support, in our GitHub repository.
OpenIO is about storage, but Ansible works with all infrastructure components and every major vendor provides some sort of support for it. If you are a sysadmin with large infrastructure to manage, I strongly suggest you check out Ansible. It’s easy to learn how to use, and it can save you a lot of time when you need to perform highly repetitive tasks on your infrastructure.