Table of contents
Ansible is a relatively simple IT automation technology. Configuration management, software deployment, cloud provisioning, ad-hoc challenge execution, community automation, and multi-node orchestration are all handled by this program. Ansible makes complex upgrades, such as zero-downtime rolling updates with load balancers, simple. The Ansible website has a lot more information.
Designed for multi-tier deployments from its start, Ansible models your IT infrastructure via way of means of describing how all your systems inter-relate, instead of simply dealing with one machine at a time. It makes use of no agents and no extra custom infrastructure, so it is smooth to deploy – and importantly, it makes use of a completely easy language (YAML, in the shape of Ansible Playbooks) that assist you to describe your automation jobs in a manner that approaches simple English.
Ansible works through connecting in your nodes and pushing out small applications, called “Ansible modules”. These apps are designed to be useful resource models of the machine’s preferred state. Ansible then executes those modules (over SSH by default), and gets rid of them while finished. Your library of modules can live on any machine, and there are no servers, daemons, or databases required. Typically you will use your favorite terminal program, an editor, and probably an SVN to keep track of adjustments in your content.
How Ansible Works?
There are two types of computers in Ansible: control nodes and managed nodes. The control node is an Ansible-running machine. There must be at least one control node, with the option of a backup control node. Any device that is handled by the control node is referred to as a managed node.
Ansible establishes a connection with network nodes (clients, servers, or whatever you’re configuring) and then transmits an Ansible module to that node. Ansible executes these modules through SSH and then deletes them once they’re finished. For this interaction to operate, only your Ansible control node needs login access to the managed nodes. Although SSH keys are the most common means of authentication, other options are available.
Modules are the fundamental components of Ansible playbooks. Although the term “module plugins” is not commonly used, a module is a form of plugin. See Modules and plugins: What is the Difference? for a developer-focused explanation of the distinctions between modules and other plugins.
A custom module can be enabled by dragging it to one of the following locations:
- any directory added to the
ANSIBLE_LIBRARYenvironment variable (
$ANSIBLE_LIBRARYtakes a colon-separated list like
For more information on using local custom modules, see Adding a module outside of a collection.
While modules give the means to complete a task, they are used in conjunction with an Ansible playbook. A playbook is a YAML configuration file that specifies what has to be done to bring a managed node to the desired state. Playbooks are supposed to be simple, readable by humans, and self-documenting. They’re also idempotent, which means that a playbook can be run on a system at any time without causing it harm. When a playbook is run on a system that is already configured and in the desired state, the system should stay in that state once the playbook is finished.
A playbook can be as simple as this one, which instals the Apache HTTP server as a privileged user on any node in the webservers group of an IT department:
- hosts: webservers user: root serial: 1
With conditionals and variables, playbooks can be quite complicated. Despite the fact that they may manage massive networks of controlled nodes, playbooks remain succinct, clear, and straightforward because Ansible modules handle the majority of the heavy lifting.