Ansible -- Part One

In the following series, the basics of the automation tool ansible will be explained. Part one deals with the installation and basic setup of ansible.

What is Ansible?

ansible is a simple open-source IT automation tool that can be used to automate configuration management, application deployment, orchestration etc. In comparison to other automation tools ansible does not require a separate service running on the remote machine, instead all commands will be simply executed via SSH. The ansible configuration is based on YAML, a configuration file format that is readable for humans as well as machines. A large set of different modules is provided that provide various pre-defined functionalities.

Installation

On the client machine, i.e. where you write your ansible scripts, you need to install ansible. On Debian you can simply installed from its repositories:

sudo apt install ansible

Inventory File

The inventory file specifies on which remote hosts the ansible scripts will be running. The hosts can be defined in the global /etc/ansible/hosts file or specified separately in a inventory.ini file that can be passed when starting the ansible script. In most cases the latter option is recommended because as a result for different projects different inventory.ini files can be created. The servers can be grouped by names in square brackets.

For instance:

mail.example.com

[webservers]
foo.example.com
bar.example.com

[dbservers]
one.example.com
two.example.com

Ad-Hoc Commands

The simplest way to use ansible is to utilize Ad-Hoc Commands. An ad-hoc command is normally used for one-time actions, for instance, a quick one-liner to reboot all webservers:

ansible webservers -i inventory.ini -a "/sbin/reboot"

There are several additional parameters that can be applied, for example, -K for privilege escalation to become root. However, due to the fact that the real ansible magic lies in playbooks, see the docs for more details.

Playbooks

Playbooks are a [more sophisticated way to use ansible by declaring more complex actions via configuration files.

Tasks

A playbook can contain multiple tasks, i.e., single steps that should be executed. Each task is based on one of the built-in modules or a raw command that should be executed. For example, a task to install the latest apache2 version looks as follows:

- name: This is a task
  apt: pkg=apache2 state=latest

The name part is optional, but recommended since it will output a useful notification on task execution. The used module here is apt with the corresponding arguments pkg and state. There are several included modules that can be used to solve different tasks.

The Playbook Format

Playbooks are defined as YAML configuration file. It contains the hosts where the tasks should be executed, further configuration settings as well as the list of tasks that should be executed on the remote host.

A simple playbook (install_apache2.yaml) is shown in the following example:

---
- hosts: webservers
  become: true
  tasks:
     - name: Update apt-cache
       apt: update_cache=yes

     - name: Install Apache2
       apt: name=apache2 state=latest

The playbook will update the apt repository of all webservers and install apache2 on them. The become indicates that root permissions are required to execute the playbook.

The playbook can be execute using the ansible-playbook command:

ansible-playbook -i inventory.ini install_apache2.yaml -K

The -K will ask for the root password when starting the playbook. When multiple groups are defined in the inventory.ini file, the -l argument can be applied to limit the selection, e.g. -l "webservers".