Why Use Ansible?

Understand what Ansible is and what makes it one of the most popular configuration management tools.

We'll cover the following

Overview

Ansible gives us flexibility where managing the configuration of our network’s nodes is concerned. We can understand this better with a simple scenario.

Let’s say we have been tasked to install a particular version of a snapThis is a package manager for the Linux operating system.. When we run the playbook to install the package, Ansible checks to see if we have the specified version and then proceeds to update or downgrade the version as necessary. After successfully configuring a node, we can configure hundreds of nodes using this same playbook.

Why Ansible?

Here’s a list of reasons why Ansible is popular as a configuration management tool:

  • The software is completely free.
  • The learning curve is not steep, meaning that it’s easy to learn in a short time.
  • Ansible uses idempotency, and it’s efficient where making changes to the configuration is concerned.
  • We can use Ansible for various purposes, including orchestration, configuration management, application deployment, and more.
  • With the collaborative power that version control offers, Ansible playbooks can be stored safely in repositories and help to determine the state of configuration of our infrastructure.

Architecture

The illustration given below shows the significant components of Ansible, which include:

  • Playbooks
  • Inventory
  • Modules
  • Plugins
Components of Ansible
Components of Ansible

In the following code, we’ll do a deep dive into the major components that make up Ansible’s automation engine.

Playbooks

A playbook is a collection of tasks to run against a managed node, with syntax as follows:

Press + to interact
---
hosts: <hosts_to_target>
vars:
    <variable_name>: <value>
tasks:
    ...

Note that we have the hosts keyword, which takes the value of the hosts we want to target. We similarly have the vars keyword, which allows us to specify the required variables, and the tasks definition.

Playbook execution
Playbook execution

After we prepare a playbook, we can use ansible-lint <name_of_playbook> to verify if our syntax is correct. We have an example playbook below to install httpd on a group of hosts called webservers. The playbook has only a single task, Install apache, which uses the apt module to install the latest httpd package.

Press + to interact
--- 
 - hosts: webservers
   connection: local
   tasks:
    - name: Install apache
      apt:
        name: 
          - httpd
        state: latest
        update_cache: true

Let’s verify the syntax of the install_apache.yml file using the following command:

ansible-lint install_apache.yml

Playground

Terminal 1
Terminal
Loading...

Running the ansible-lint command will generate the necessary recommendation for the playbook we’re checking.

As we can see, the install_apache.yml playbook has the following issues:

  • It contains some unnecessary whitespaces.

  • We try to install the latest version of Apache instead of a specific version like 2.2.

Inventory

An inventory is simply the list of hosts contained in our infrastructure setup. Let’s say we have ten servers grouped into five web servers and five load balancers. Then, we can have a grouping similar to the one below:

Press + to interact
[webservers]
<node_1_IP_address>
<node_2_IP_address>
<node_3_IP_address>
<node_4_IP_address>
<node_5_IP_address>
[loadbalancers]
<node_6_IP_address>
<node_7_IP_address>
<node_8_IP_address>
<node_9_IP_address>
<node_10_IP_address>

The default inventory for Ansible is contained in the /etc/ansible/hosts path.

Plugins

We can use plugins to make the functionality of Ansible more robust. Here are some examples:

  • Callback plugin: This allows Ansible to react to events and print output on the screen.
  • Cliconf plugin: This helps secure connection between the Ansible controller node and the managed hosts.
  • Action plugin: This acts as a layer between the different modules and the Ansible core execution engine.
  • Become plugin: This is used to ensure that Ansible can perform privilege escalations as required. For example, these plugins allow Ansible to switch to a power user while running tasks against target machines.
  • Cache plugin: This is used to ensure that facts/information about the target hosts is cached.

The three major plugins are the connection, action, and callback plugins because they’re used for executing the tasks defined in playbooks.

Modules

A module is essentially a type of plugin that makes up a playbook. Commands are executed on managed nodes using modules. There’s an exclusive list of modules, but some examples are listed below:

  • Package management module: This is used to perform the function of local package managers like apt and rpm on target hosts.
  • The file module: This is used to create, delete, and manipulate files.
  • The template module: This is similar to the copy module and is used to template files from the controller to the managed nodes.
  • The archive module: This is used for file compression and creating files with extensions of .tar, .gzip, .bz2, .zip, and so on.
  • The command/shell modules: These are used to run shell scripts or commands on target nodes.