Tags are basically metadata that are attached to the tasks, roles, plays, etc. Using tags has a big advantage in saving time on and simplifying the running and debugging jobs of playbooks. It also makes the playbook more organized and robust.
Here at LinuxAPT, we shall look into how to use the tags with Ansible playbooks running Ubuntu.
The Ansible control node is the machine we’ll use to connect to and control the Ansible hosts over SSH. Your Ansible control node can either be your local machine or a server dedicated to running Ansible.
To install Ansible, follow the steps below:
1. First, refresh your system's package index with:
$ sudo apt update
2. Following this update, you can install the Ansible software with:
$ sudo apt install ansible
Press Y when prompted to confirm installation. if you are prompted to restart any services, press ENTER to accept the defaults and continue.
If you are just starting to learn Ansible, we suggest that you first learn Vagrant and how to set up a basic local testing environment using Vagrant. Once you set up a basic lab consisting of one controller node and two target nodes, you are all set to perform these examples.
In many cases, you may want to run a specific part of a playbook instead of executing the entire playbook. This is very handy in cases where the playbook is very large. In such cases, tags are used to run or skip a task in a playbook. This is done in a two-step approach:
A tag can be defined for a task, block, role, or for an entire play. The "tags" keyword is used for defining a tag as we will soon see in the subsequent examples.
In its most basic form, a single task can have one or more tags. Similarly, a common tag can be linked to more than one task. For example, consider the following playbook:
- hosts: all
- name: Update the system repository information (‘apt-get update’)
- name: Run the equivalent of ‘apt-get dist-upgrade’ to upgrade the system as a separate step
tags: [ ubuntu, distup ]
- name: Install the apache web server and ntp program
- name: Restart apache
There are four tasks in the given playbook:
Using a tag for multiple tasks (tag reuse) executes all the tasks linked with that tag. For this, the "—tags" flag is specified at the command line.
Suppose we have already run the previous playbook once and when we want to only restart the apache service and do nothing with the other tasks.
In this case, we have to run the playbook (our my-playbook.yml) in the following manner:
$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --tags RestartApache
In cases where you want to skip a task from execution, Ansible provides you with the "–skip-tags" parameter. The rest of the playbook normally runs. In the previous example, let us ignore the task of upgrading the system (task:2).
For this, the "ansible-playbook" command is modified as:
$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --skip-tags distup
Ansible has two reserved tags for two specific purposes. These are the 'never' and 'always' tags. The purpose of the ‘always’ tag is to always run the task it is linked with. The 'never' tag is opposite of the 'always' tag which skips the task it is linked with.
The following example demonstrates this:
- hosts: all
- name: The Ansible 'always' tag example
msg: "I will be always shown here"
- name: The Ansible 'never' tag example
msg: "I will never shown up until you specifically allow me"
In the previous playbook, the first task is set to always run while the second is set to never run.
In case we want to skip the task tagged with "always", we have to explicitly specify this behavior on the command line as "–skip-tags always".
In the previous playbook, we can skip the first task as:
$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --skip-tags always
Similarly, a task with the "never" tag will never run unless it is tagged as "–tags never". The second task can be executed as:
$ ansible-playbook myplaybook.yml -i /path/to/inventory/file --tags never
This article covers how to Use Tags in Ansible Playbook. In fact, you might want to run specific tasks instead of running an entire playbook file. This helps to reduce the total playbook execution time, especially when dealing with a large playbook file.