If you're in IT, you're probably hearing more and more about Ansible. CIOs are calling it the "darling" of DevOps for automating software tasks.
StackShare lists over 1,700 companies using Ansible, including Revolut, Zalando and public agencies such as NASA. So, what is Ansible, and why has it become so popular so quickly?
What is Ansible?
Ansible is an automation platform supported by Red Hat. It lets you configure systems, deploy software and orchestrate more advanced IT tasks, such as continuous deployments or permanent updates without downtime. It can also provision virtual machines, containers and networks, as well as complete cloud computing infrastructures.
Ansible is therefore open to all types of users, from developers and system administrators to data engineers and IT managers. It also integrates with Docker, Kubernetes, Microsoft Azure, Google Compute Engine, Datadog and many other tools.
The practical result is thus a major contribution to the “infrastructure as code” movement in IT: the idea that server and client infrastructure maintenance can and should be treated in the same way as software development, with repositories of self-documented, proven and executable solutions capable of running an organization regardless of changes in personnel.
How does Ansible work?
There are two categories of computer in Ansible: the control node and managed nodes. The control node is the computer running Ansible. There must be at least one control node, although a backup control node can also exist. A managed node represents any device managed by the control node.
Ansible works by connecting to nodes (clients, servers, or other nodes) on a network, then sending a small program called an Ansible module to that node. Ansible executes these modules via SSH and deletes them once they have been completed. The only requirement for this interaction is that your Ansible control node has login access to the managed nodes. SSH keys are the most common way of providing access, but other forms of authentication are also supported.
How to use Ansible
Using Ansible may seem complex at first glance, but this complexity is managed by Ansible, not by the user.
An Ansible module is written to represent a desired state of a system, which means that each module defines what should be true on a given managed node.
For example, if a system administrator decides that all workstations in an organization should have the latest version of a software installed, then it’s up to the Ansible module to determine whether each node has this version of the software on it.
If Ansible finds a managed node with the software installed, it detects the operating system and runs the necessary routine to implement the updates. In this way, every workstation in an organization can be automatically updated with these Ansible modules from a simple dashboard.
If you need to automate a task on several computers, the Ansible module library will enable you to find the one that handles the task you want to perform. If you’re a programmer, you can also write your own custom modules to perform specialized tasks, and if your module is generally useful, you can also submit it to the Ansible project, an Open Source project that today has over 3,500 contributors so that others can benefit from your work.
How do I implement Ansible modules?
While modules provide the means to accomplish a task, the way you use them is through an Ansible Playbook.
An Ansible Playbook is a configuration file written in YAML, a simple programming language, that provides instructions on what needs to be done to bring a managed node into the desired state. Ansible playbooks are really at the heart of what makes Ansible so popular, as they describe tasks to be performed quickly without the user needing to know any particular syntax.
Not only can Ansible Playbooks declare configurations, they can orchestrate the steps of any manually-ordered task, and can run tasks at the same time or at different times.
Ansible Playbooks are designed to be simple, human-readable and self-documenting. An Ansible Playbook can be run on a system at any time without adversely affecting it. If an Ansible playbook is run on a system that is already correctly configured and in the desired state, that system should still be correctly configured after the playbook has been run.
