Quick Ansible Overview — Remediate Host Configuration Drift (Infrastructure-as-Code)

This introductory article is about Infrastructure-as-Code (IaC) and a major player of which, Ansible, its concepts — control node, managed host, inventory, playbook and modules — along with a quick example using an ansible command to remediate configuration drift of managed computers, so that a specified service on them is running in its desired state.

Infrastructure-as-Code

DevOps is not a Goal, but a never-ending process of continual improvement. — Jez Humble

It is the era of DevOps, where development (Dev) and operation (Ops) are converged and streamlined for the benefit of the business. On the infrastructure side, it is also desired that managing hosts (mostly servers and workstations) be done in a modern way to fit in the DevOps mindset where everything is defined as code to allow for agility which enables continual improvement.

Comes Infrastructure-as-Code automation engines, available as command-line tools which can be leveraged for infrastructure compliance remediation. Such things might sound difficult to be done in the past, but thanks to the advance in technology, the complexity is hidden by automation engines such as Ansible.

Ansible

Automation is good, so long as you know exactly where to put the machine. — Eliyahu Goldratt

Ansible is an open-source agentless configuration management tool from Red Hat which treats infrastructure as code. It can prevent configuration drift by maintaining the desired state, e.g. ensuring operating system firewall is running, by remediating security and compliance issues according to Ansible playbooks of rules specified against an Ansible inventory file of computers.

How to Get Ansible to Work

Operating Ansible commonly involves developing Ansible playbooks in YAML format, as well as writing inventory files in INI format. They are simpler than other syntax file formats such as JSON (which is also supported by Ansible), and are (arguably) more friendly to the less technically-inclined. These will be used in our quick example.

Some Ansible Terminology

• Inventory — an INI file (e.g. inventory.ini) where a list of managed hosts (also known as managed nodes) are defined. These may be computers a system administrator would like to manage
• Playbook — a YAML file (or JSON) where rules are defined, e.g. rule-book.yml

A computer with Ansible installed, the control node, can then execute the ansible-playbook command, specifying the inventory and playbook via its parameters, e.g. ansible-playbook -i inventory.ini rule-book.yml to check or remediate any compliance drift found in the managed hosts.

Ansible Host Inventory — inventory.ini

This is an example of an inventory which shows two Linux servers.

Specify two Linux servers named LNXSVR01 and LNXSVR02 (which are used below as an example of managed hosts) in inventory.ini:

LNXSVR01
LNXSVR02

Ansible Playbook — rule-book.yml

This is an example of a playbook which shows firewall must be started.

Perform compliance checking to ensure firewall service is running on all hosts defined in the inventory by creating the playbook, e.g. rule-book.yml as below:

---
- hosts: all # Apply to all hosts in the inventory file
  remote_user: root
  tasks:
    - name: ensure firewall service is running
      service:
        name: '{{ item }}'
        state: started
        enabled: yes
      with_items:
        - firewalld # Add more services to this list as required

Although the above example merely shows checking or remediating a single item, when rules like this are combined together according to system hardening guides such as the ones published by Center for Internet Security (CIS), they ensure computers are compliant with industry standards.

Ansible Command

Putting it together, run Ansible playbook rule-book.yml against computer inventory inventory.ini with superuser privilege via --sudo (or --become) parameter:

$ ansible-playbook -i inventory.ini rule-book.yml --sudo

The command can be fired up manually or via a scheduled cron job.

Ansible Checking and Remediation Results

LNXSVR01, whose firewall was not running, becomes compliant after the Ansible playbook execution. On the other hand, LNXSVR02, whose firewall was already running, was idempotent*:

PLAY [all] ***************************************************
TASK [Gathering Facts] ***************************************
ok: [LNXSVR02]
ok: [LNXSVR01]
TASK [Ensure firewall service is running] ***
ok: [LNXSVR02] => (item=firewalld)
changed: [LNXSVR01] => (item=firewalld)

PLAY RECAP ***************************************************
LNXSVR01      : ok=4    changed=1    unreachable=0    failed=0
LNXSVR02      : ok=4    changed=0    unreachable=0    failed=0

*Idempotent in this context means only execute when configuration has drifted; otherwise, no action would be performed no matter how many times the command has been run.

Extending Capability with Community Modules

Ansible, being the most popular configuration management project on GitHub and being in the top-10 chart there for many years, has an active community developing modules to extend capabilities of it.

For example, due to Windows previously lacking a native software package manager (e.g. yum on Red Hat or apt-get on Ubuntu Linux), Chocolatey, the most popular third-party Windows package manager, was born and can be used via win_chocolatey module in Ansible, which is one of the modules maintained by the community.

Taking AeroZoom as an example of Windows software on Chocolatey, which is a keyboard-free screen magnifier freeware application created and submitted by me to the Chocolatey community repository. Below, AeroZoom acts as a required item for compliance checking.

A playbook which performs compliance checking to ensure AeroZoom is installed would be like this:

---
  tasks:
    - name: ensure AeroZoom Windows application is installed
      win_chocolatey:
        name: AeroZoom
        state: present

Further from Here

Ansible is truly a powerful configuration management tool used by DevOps engineers. Being a simple command-line tool, it does not come with a graphical user interface. For those who need it, a separate web-based application, Red Hat Ansible Towers (or AWX, the open-source upstream variant of which), can be deployed.

Ansible can manage both Linux and Windows machines. However, the control node of Ansible is so far only available on Unix-esque platforms such as Linux, which is less approachable to IT professionals who may be more used to the Windows platform. Some time ago, Microsoft has included Windows Subsystem for Linux (WSL) in Windows 10 which can install and run Ansible. There are limitations last time I checked (such as not supporting cron which many people use to trigger Ansible), but once it matures, who knows? It could someday totally replace the need for a separate virtual machine or docker instance merely to run Ansible on Windows.

All in all, Ansible has high potential being a great lightweight (agentless) tool which is handy e.g. for sysadmins to ensure system compliance, DevOps engineers to configure operating systems after they are provisioned, and so much more!

---

If this article helps you get started with Ansible, feel free to let me know. In future, I may explore more aspects of Ansible where I find useful or interesting. Stay tuned! 😊

Tweet