You have probably heard about Ansible, at least if you are interested in DevOps and software automation. Back in May 2017, CIO wrote that Ansible has become the Devops darling. We used to talk a lot about Puppet, Chef, Salt and even CFEngine. Now, the automation talk is all about Ansible.
What is Ansible?
The Ansible we use in our day to day use, came from an Open Source company founded in 2013.
Red Hat acquired the company two years later, in 2015. Before that Ansible had partnered up with HP, RackSpace, CSC, Cisco and the open source community to help make deploying and managing OpenStack clouds easier. When Red Hat acquired Ansible the press release stated that by adding Ansible to the portfolio Red Hat would be able to help customers to
- Deploy and manage applications across private and public clouds
- Speed service delivery through DevOps initiatives
- Streamline OpenStack installations and upgrades
- Accelerate container adoption by simplifying orchestration and configuration
Why did Ansible become so popular so fast?
The reason for its success is not only that Ansible got acquired by a big open source company like Red Hat, although that definitely helped. It gave Ansible a VIP ticket to Enterprise IT.
Ansible is known for removing the barrier with the technicalities of deploying code. You can describe almost everything in “English”. It doesn’t require any special coding skills, making therefore automation accessible for everyone. If you want to implement Puppet, you need to have a deeper understanding of how the product works. Ansible doesn't require an agent, it communicates with the nodes it controls i.e. by SSH or WinRM.
Specific tasks are encapsulated by modules that define the state of a resource on the node. These modules are used to alter the state of the system and remotely executed on the node. Unlike Puppet and Chef, which are using agents running locally and execute changes on the node.
The Ansible module then reports back the result of that module to the local instance. All the execution logs are available at the node running Ansible and do not have to be collected otherwise.
In the early days of Ansible, many of our customers used a combination of Ansible and Chef/Puppet. Nowadays, more and more are moving away from their Puppet code.
Because of the agent-less approach, it’s easy to not only controlling servers, but also network infrastructure using Ansible. Most DevOps Engineers are familiar with Python and that makes it easier to use Ansible than Puppet and Chef which are written in Ruby.
Hello, automation!
Say hello to the world of automation with automating your DevOps tasks, your deployments, your health checks, your entire continuous integration process. It’s extremely easy to use, convert your old bash scripts, and find joy in Ansible playbooks instead.
