Ansible

In today's fast-paced IT environment, efficiency is essential. Repetitive tasks can drain valuable time and resources from the IT team, offering no added value.

It's one of my favorite tools lately, as a person managing several Linux servers. It helps with provisioning and daily tasks, system updates, and upgrades.

Ansible® Originally written by Michael DeHaan in 2012, and acquired by Red Hat in 2015

Here is where Ansible comes in. A powerful automation tool, Ansible is something every server administrator or IT enthusiast should have under their belt. It can help with numerous tasks, from simple ones like configuring system settings or deploying applications to more advanced and even complex tasks such as provisioning new servers and orchestrating required workflows.

Ansible is built and designed to follow the principles,

Agent-less architecture eliminates the need to install software agents on remote devices. This simplifies deployment and reduces configuration overhead

Straightforward written format for writing playbooks. This allows you to easily define automation tasks for your SSH-connected managed nodes.

Scales easily and flexibly to manage a large number of machines across various operating systems.

A constant operation that has a predictable outcome and does not change the result, regardless of how many times it's applied.

From Ansible community documentation, initially, there are three key components for Ansible Control to be defined below:

Control node: A system on which Ansible is installed. It's like the Master node where you run Ansible commands such as ansible or ansible-inventory on a control node.

Inventory: A list of managed nodes that are logically organized. You create an inventory on the control node to describe host deployments to Ansible. Here we can create groups of hosts that we want to manage and control with Ansible.

Managed node: A remote system, or host, that Ansible controls and uses.

1. Installation

We are going to install and set Ansible on AlmaLinux 9 / Rocky Linux / Red Hat Enterprise Linux-based distributions using the EPEL repository way.

Update the System first to take the last packages with the command:

sudo yum update -y

Then, enable the Extra Packages for Enterprise Linux (EPEL) repository with the command:

sudo yum install epel-release -y

To install your Ansible now with the package manager:

sudo yum install ansible -y

Verify it's installed and check its version:

ansible --version

Now we have installed and made sure that Ansible is working in our control node, will continue with setting up and following the configuration required to start with a Playbook example.

2. Configuration

After successful installation you will find the Ansible config file located in /etc/ansible/ansible.cfg and for the Hosts file in the same directory /etc/ansible/hosts

So first setup is to add our servers and machines in the host file so Ansible can identify and start communicating.

The examples below show how the host file is structured, for the server without collections or groups should be listed before then the collections and group-define.

# Ex 1: Ungrouped hosts, specify before any group headers:

prd.example.com
192.168.100.10

# Ex 2: A collection of hosts to follow the tamplate below:
[collection_name]
your_server_fqdn or
your_server_ip

So a collection of hosts belonging to 'yum-server' group will be like:
[yum-servers]
192.168.20.5
192.168.20.6

3. Basic Ansible Playbook

An Ansible Playbook is a way to easily deploy complex commands and configurations that can be run repeatedly. Playbooks are written in YAML, a human-readable data format. This allows you to define and create tasks to be executed on your servers.

We'll now create a simple Ansible Playbook that automates updating installed packages on your servers. Depending on the underlying operating system (Red Hat-based or Debian-based), we can create a separate playbook for each.

# Playbook to update Red Hat Enterprise Linux, Oracle Linux
---
- hosts: "*"
  become: true
  become_method: sudo
  tasks:
  # Update and Upgrade Packages all in one play
  - name: Update all installed packages using the YUM module
    yum:
      name: '*'
      state: latest
      update_cache: yes
      update_only: yes
    register: yum_update_status

  # Remove Packages
  - name: Remove packages not needed anymore
    yum:
      autoremove: yes
    become: true

# Playbook to update Debian distribution systems
---
- hosts: "*"
  become: true
  become_method: sudo
  tasks:
  # Update and Upgrade Packages all in one play
  - name: Update all installed packages using APT module
    apt:
      name: '*'
      state: latest
      update_cache: yes
      only_upgrade: yes
    register: apt_update_status
    become: true

  # Remove Packages
  - name: Remove packages not needed anymore
    apt:
      autoremove: yes
    become: true

And here is a breakdown of the Playbook.

• The file starts with three dashes like below:

---

• Define the host's group or collection hosts:

hosts: "*" # All hosts all (or *) , One group dev-server

• Enables privilege escalation for all tasks in the host:

become: true

• Set the method for privilege escalation as sudo to execute tasks:

become_method: sudo

• Here we declare the plays and tasks to perform on the machine under this block:

tasks:

• The action and task it self defined below using the Apt Ansible Module:

- name: Update all installed packages using APT module
    apt:
      name: '*'
      state: latest
      update_cache: yes
      only_upgrade: yes
    register: apt_update_status
    become: true

• Another action we can perform, as previously described, is to remove old, unneeded packages:

- name: Remove packages not needed anymore
    apt:
      autoremove: yes
    become: true

4. Run Ansible Playbook

No to easily deploy the tasks that we defined in the playbook to be executed on selected servers. First, we need to validate that the playbook has no errors in syntax with the following

• run the ansible-playbook syntax check command to validate the file format.

ansible-playbook apt-update.yml --syntax-check

• It should output no error if everything is okay:

playbook: apt-update.yml

• Now we're ready to run the playbook to update our servers.

Additionally, there are optional flags for connection options that can be used in the playbook to override settings like the host group, which is currently set to 'all' or for asking sudo password you need the "--ask-become-pass" flag.

ansible-playbook yum-update.yml --user REMOTE_USER l yum-servers 

• Here's a look at a sample playbook run:

PLAY [*] *************************************************************************

TASK [Gathering Facts] *************************************************************************
ok: [192.168.20.6]
ok: [192.168.20.5]

TASK [Update all installed packages using YUM module] *************************************************************************
ok: [192.168.20.6]
changed: [192.168.20.5]

TASK [Remove packates not needed anymore] *************************************************************************
changed: [192.168.20.5]
changed: [192.168.20.6]

PLAY RECAP *************************************************************************
192.168.20.5: ok=3 changed=2 unreachable=0 failed=0 skipped=0 rescued=0   
192.168.20.6: ok=3 changed=1 unreachable=0 failed=0 skipped=0 rescued=0

Conclusion

Ansible is a valuable tool that can simplify deploying tasks at scale, particularly in enterprise environments with numerous servers deployed across the network that require daily management, updates, and monitoring.

Learning and practicing Ansible automation is highly recommended due to its vast capabilities and potential for system administration.

Sources and References:

• Ansible community documentation

• Enable Sysadmin, How I used Ansible to automate updates at home
  March 11, 2021 | | by Jörg Kastning

• digitalocean.com, Tutorials Creating and Running your First Ansible Playbook
  April 15, 2021 || By Erika Heidi