Understand Core Components of Ansible – Part 1

Posted by

The Red Hat Certified Specialist in Ansible Automation exam (EX407) is a new certification program by Red Hat that tests your skills to use Ansible to automate the configuration of systems and applications.

The series will be titled “The Red Hat Certified Specialist in Ansible Automation exam (EX407)” and covers the following exam objectives based on Red Hat Enterprise Linux 7.5 and Ansible 2.7, which we will going to cover in this Ansible series:

To view fees and register for an exam in your country, check the Ansible Automation exam page.

Part 1Understand Core Components of Ansible

Part 2Install and Configure an Ansible Control Node

Part 3How to Configure Ansible Managed Nodes and Run ad-hoc Commands

Part 4How to Create Static and Dynamic Inventories to Define Groups of Hosts

Part 5How to Create Ansible Plays and Playbooks

Part 6How to Use Ansible Modules for System Administration Tasks

Part 7How to Create and Use Templates to Create Customized Configuration Files

Part 8How to Work with Ansible Variables and Facts

Part 9How to Create and Download Roles an Ansible Galaxy and Use Them

Part 10How to Use Ansible Vault in Playbooks to Protect Sensitive Data

In this Part 1 of the Ansible series, we will discuss some basic overview of core components in it.

Understand Core Components of Ansible

It is a free and opensource automation platform by RedHat that enables you to manage and control multiple servers from one central location. It’s especially ideal when you have multiple and repetitive tasks that need to be performed. So instead of logging into each of these remote nodes and carrying out your tasks, you can comfortably do so from a central location and comfortably manage your servers.

This is beneficial when you want to maintain consistency in application deployment, reduce human error and automating repetitive and somewhat mundane tasks.

Of course, there are other alternatives to Ansible such as PuppetChef, and Salt. However, It is mostly preferred because it is easy to use and simple to learn.

Why is it simple to learn you might ask? This is because Ansible uses YAML (Yet Another Markup Language) in its configuration and automation jobs which are human-readable and quite easy to follow. YAML uses SSH protocol to communicate with remote servers, unlike other automation platforms that require to you install an agent on remote nodes to communicate with them.

Before we get started with it, it’s important that you get acquainted with some basic terminologies so that you don’t get lost or confused as we move forward.


An inventory is a text file that contains a list of servers or nodes that you are managing and configuring. Usually, the servers are listed based on their hostnames or IP addresses.

An inventory file can contain remote systems defined by their IP addresses as shown:

Alternatively, they can be listed according to groups. In the example below, we have servers placed under 2 groups – web servers and databases. This way they can be referenced according to their group names and not their IP addresses. This further simplifies operation processes.



You can have multiple groups with multiple servers if you are in a large production environment.


playbook is a set of configuration management scripts that define how tasks are to be executed on remote hosts or a group of host machines. The scripts or instructions are written in YAML format.

For instance, you can have a playbook file to install the Apache webserver on CentOS 7 and call it httpd.yml.

To create the playbook run the command.

$ touch playbook_name.yml

For example to create a playbook called httpd, run the command.

$ touch httpd.yml

A YAML file begins with 3 hyphens as shown. Inside the file, add the following instructions.

- name: This installs and starts Apache webserver
  hosts: webservers

  - name: Install Apache Webserver 
    yum:   name=httpd  state=latest

 - name: check httpd status
    service:   name=httpd  state=started

The above playbook installs Apache web server on remote systems defined as webservers in the inventory file. After the installation of the webserver, Ansible later checks if the Apache web server is started and running.


Modules are discrete units of code used in playbooks for executing commands on remote hosts or servers. Each module is followed by an argument.

The basic format of a module is key: value.

- name: Install apache packages 
    yum:   name=httpd  state=present

In the above YAML code snippet, -name and yum are modules.


An ansible play is a script or an instruction that defines the task to be carried out on a server. A collection of plays constitute a playbook. In other words, a playbook is a collection of multiple plays, each of which clearly stipulates the task to be carried out on a server. Plays exist in YAML format.


If you have a background in programming, then most likely you have used variables. Basically, a variable represents a value. A variable can include letters, numerals, and underscores but MUST always begin with letters.

Variables are used when instructions vary from one system to another. This is especially true during the configuration or various services and features.

There are 3 main types of variables:

  • Playbook variables
  • Inventory variables
  • Special variables

In this, variables are first defined using the vars k, then followed by the variable name and the value.

The syntax is as shown:

Var name1: ‘My first variable’
	Var name2:  ‘My second variable’

Consider the code below.

- hosts: webservers
    - web_directory:/var/www/html/

In the example above, the variable here is web_directory and it instructs ansible to create a directory in the /var/www/html/ path.


Facts are system properties gathered by Ansible when it executes a playbook on a host system. The properties include hostname, OS family, CPU type, and CPU cores to mention a few.

To have a glimpse of the number of facts available for use issue the command.

$ ansible localhost -m setup
List Available Ansible Facts

As you can see, a huge number of facts have been displayed by default. You can further narrow down the results using the filter parameter as shown.

$ ansible localhost -m setup -a "filter=*ipv4"
List IPv4 Ansible Facts

Configuration Files

In Ansible, a configuration file is a file that contains different parameter settings that determine how Ansible runs. The default configuration file is the ansible.cfg file located in /etc/ansible/ directory.

You can view the configuration file by running:

$ cat /etc/ansible/ansible.cfg
Ansible Configuration File

As you can observe, several parameters are included such as inventory and library file paths, sudo user, plugin filters, modules, etc. These parameters can be adjusted simply by commenting them out and modifying the values therein.

Additionally, you can have multiple configurations files working with Ansible apart from your default config file.


Having looked at the core components in Ansible, we hope you are in a position to keep them at your fingertips and pick them out as we move forward. Join us on your next topic.

Leave a Reply

Your email address will not be published. Required fields are marked *