Understand Core Components of Ansible – Part 1

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.

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

Understand Core Components of Ansible

Ansible 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 Puppet, Chef, and Salt. However, Ansible 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 Ansible, it’s important that you get acquainted with some basic terminologies so that you don’t get lost or confused as we move forward.

Inventory

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:

10.200.50.50
10.200.50.51
10.200.50.52

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.

[webservers]
10.200.50.60
10.200.50.61

[databases]
10.200.50.70
10.200.50.71

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

Playbook

A 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

  tasks:
  - 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

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.

Plays

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.

Variables

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 Ansible, variables are first defined using the vars k, then followed by the variable name and the value.

The syntax is as shown:

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

Consider the code below.

- hosts: webservers
  vars: 
    - 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

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

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"

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

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.

Summary

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.